Eu tenho AD local e AD no Azure e tenho configuração de servidor proxy ADFS e ADFS para autenticar usuários no AD local. Segui todas as etapas no site da Microsoft para configurar a confiança entre o Azure AD e o AD local. No entanto, diz que o Dir Sync é necessário para obter SSO para usuários no AD local e na nuvem. Não quero usar o Dir Sync e quero que meu ADFS seja capaz de autenticar usuários do meu AD local e do Azure AD também.
Alguém pode me informar os passos para alcançá-lo.
Responder1
Supondo que seja para O365 ou Intune – DirSync é um componente necessário. DirSync permitirámesmologin, o que significa que as senhas são as mesmas em ambos os ambientes. Adicionar ADFS permitirásolteirologin, o que significa que os usuários se autenticarão perfeitamente sem serem solicitadas credenciais. DirSync é um componente fundamental para logon único e logon único.
Não é possível fazer logon único em um locatário do Azure AD apenas com o ADFS.
Responder2
Eu tive a mesma pergunta e o comentário demaweerasme colocar no caminho certo. Fiz uma pequena pesquisa, fiz funcionar e aqui está o que funcionou para mim.
Não tenho certeza se esta é a solução "suportada", porque eles realmente parecem gostar do DirSync. No entanto, faz sentido que seja compatível pelo motivomaweerasmencionado - ou seja, permitir que a infraestrutura que não seja do Active Directory ainda tenha SSO no Office 365.
Aqui está o que você precisa fazer:
O SSO habilita o domínio no lado do Office 365, executando os miniaplicativos do PowerShell Convert-MsolDomainToFederated. Você provavelmente já fez isso.
Crie as contas de usuário que deseja ativar o SSO no Office 365 manualmente ou pelo PowerShell.
Depois de criá-los, você precisa usar o ObjectGUID emseuO objeto da conta AD como seu ID imutável no lado do Azure.
Usei-os como referência, mas incluirei as informações caso esses URLs desapareçam no futuro:
Você precisa codificar em base64 o ObjectGUID para seu usuário e defini-lo. O GUID que você codifica não deve incluir colchetes:
O script aqui faz a conversão para você: http://gallery.technet.microsoft.com/office/Covert-DirSyncMS-Online-5f3563b1
GUID do objeto AD (em "formato de registro") 748b2d72-706b-42f8-8b25-82fd8733860f
Codificado: ci2LdGtw+EKLJYL9hzOGDw==
Você define isso na conta do Azure via PowerShell:
Set-MsolUser -UserPrincipalName[e-mail protegido]-ImmutávelId "ci2LdGtw+EKLJYL9hzOGDw=="
Certifique-se de que o UPN na sua conta de usuário (no domínio do AD) corresponda ao[e-mail protegido]UPN que o Office 365 tem ao seu lado, ou você receberá um erro estranho no lado do Azure. Acho que o código de erro é 8004786C
Se você não tiver o sufixo UPN disponível para definir em seu usuário em seu ambiente AD, deverá adicionar esse sufixo por meio de "Domínios e relações de confiança do Active Directory". Ou, se você quiser ser inteligente, defina outro atributo em sua conta do AD e faça com que o ADFS envie esse atributo como o ID imutável. Se você não sabe o que quero dizer, basta definir o UPN. :)
O Microsoft Office 365 não aparecerá como uma opção em um menu suspenso iniciado pelo ADFS IDP em seu servidor. Parece que o SP foi iniciado e você deve acionar a dança SAML acessando primeiro o portal deles:https://portal.microsoftonline.com
Você pode usar algo como o Fiddler para capturar a conversa SSL e analisar algumas informaçõeshttp://community.office365.com/en-us/wikis/sso/using-smart-links-or-idp-initiated-authentication-with-office-365.aspxpara ter uma sensação mais iniciada pelo IDP, onde o usuário clica no seu link e faz um login tranquilo e agradável no Office 365 sem inserir nada.
Responder3
Isso ajuda em alguma coisa?http://technet.microsoft.com/en-us/library/dn296436.aspx
Já faz um tempo que não faço o que você está pedindo, mas isso estava em minhas anotações.