Eu tenho AD e AD locais no azure e tenho a configuração do servidor proxy ADFS e ADFS para autenticar os usuários no AD local. Eu segui todas as etapas no site da Microsoft para configurar a confiança entre o Azure AD e o AD local. No entanto, ele diz que o Dir Sync é necessário para obter o SSO para os usuários no AD local e na nuvem. Não quero usar a sincronização de diretório e quero que meu ADFS também possa autenticar usuários do meu AD local e do Azure AD.
Alguém pode me informar os passos para alcançá-lo.
Supondo que isso seja para o O365 ou Intune - o DirSync é um componente necessário. O DirSync permitirá o login same , significando que as senhas são as mesmas nos dois ambientes. Adicionar o ADFS permitirá o login de único , o que significa que os usuários serão autenticados sem serem solicitados credenciais. DirSync é um componente fundamental para o mesmo logon e logon único.
Você não pode fazer logon único em um locatário do Azure AD com o ADFS sozinho.
Eu tive a mesma pergunta e o comentário de maweeras me colocou no caminho certo. Eu pesquisei um pouco, trabalhei e aqui está o que funcionou para mim.
Não tenho certeza se essa é a solução "suportada", porque eles realmente parecem gostar do DirSync. No entanto, faz sentido que ele seja aceito pelo motivo mencionado por maweeras , ou seja, permitir que a infraestrutura não do Active Directory ainda tenha o SSO no Office 365.
Veja o que você precisa fazer:
O SSO ativa o domínio no lado do Office 365, executando os applets powershell Convert-MsolDomainToFederated. Você provavelmente já fez isso.
Crie as contas de usuário que você deseja habilitar o SSO no lado do Office 365 à mão ou no powershell.
Depois de criá-los, você precisa usar o ObjectGUID no objeto da sua conta AD como sua ID Imutável no lado do Azure.
Eu usei isso como referência, mas incluirei as informações caso essas URLs desapareçam no futuro:
Você precisa codificar em base64 o ObjectGUID para o seu usuário e definir isso. O GUID que você codifica não deve incluir os colchetes:
O script aqui faz a conversão para você: link
GUID do Objeto AD (em "Formato do Registro") 748b2d72-706b-42f8-8b25-82fd8733860f
codificado: ci2LdGtw + EKLJYL9hzOGDw ==
Você define isso na conta do Azure via powershell:
Set-MsolUser -UserPrincipalName [email protected] -ImmutableId "ci2LdGtw + EKLJYL9hzOGDw =="
Verifique se o UPN na sua conta de usuário (no lado do domínio do AD) corresponde à UPN [email protected] que o Office 365 tem do lado deles, ou você receberá um erro estranho no lado do Azure. Eu acho que o código de erro é 8004786C
Se você não tiver o sufixo UPN disponível para ser definido em seu usuário em seu ambiente do AD, adicione 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 - então basta definir o UPN. :)
O Microsoft Office 365 não será exibido como uma opção em um menu suspenso de IDP iniciado pelo AD FS em seu servidor. Parece que o SP foi iniciado e você deve acionar a dança SAML acessando primeiro o portal: link
Você pode usar algo como o Fiddler para capturar a conversa SSL e, em seguida, analisar algumas informações link para ter mais de um IDP iniciado sentir, onde o usuário clica em seu link e encaminha todo o caminho em um bom logon suave para o Office 365 sem digitar nada.
Isso ajuda em tudo? link
Já passou algum tempo desde que fiz o que você está pedindo, mas isso foi em minhas anotações.
Tags active-directory adfs