Tengo AD y AD locales en Azure y tengo configurados un servidor proxy ADFS y ADFS para autenticar usuarios en AD local. Seguí todos los pasos en el sitio de Microsoft para configurar la confianza entre Azure AD y AD local. Sin embargo, dice que Dir Sync es necesario para lograr SSO para los usuarios en AD local y en la nube. No quiero usar Dir Sync y quiero que mi ADFS pueda autenticar usuarios desde mi AD local y también desde Azure AD.
¿Alguien puede decirme los pasos para lograrlo?
Respuesta1
Suponiendo que esto sea para O365 o Intune, DirSync es un componente requerido. DirSync permitirámismoiniciar sesión, lo que significa que las contraseñas son las mismas en ambos entornos. Agregar ADFS permitirásolteroiniciar sesión, lo que significa que los usuarios se autenticarán sin problemas sin que se les soliciten credenciales. DirSync es un componente fundamental tanto para el mismo inicio de sesión como para el inicio de sesión único.
No puede realizar un inicio de sesión único en un inquilino de Azure AD solo con ADFS.
Respuesta2
Tenía la misma pregunta y el comentario demaweerasponme en el camino correcto. Investigué un poco, lo hice funcionar y esto es lo que funcionó para mí.
No estoy seguro de que esta sea la solución "compatible", porque parece que realmente les gusta su DirSync. Sin embargo, tiene sentido que sea compatible por el motivomaweerasmencionado, es decir, permitir que la infraestructura que no es Active Directory siga teniendo SSO en Office 365.
Esto es lo que debes hacer:
SSO habilite el dominio en el lado de Office 365 ejecutando los subprogramas de PowerShell Convert-MsolDomainToFederated. Probablemente hayas hecho esto.
Cree las cuentas de usuario que desea habilitar SSO en Office 365 manualmente o mediante powershell.
Una vez que los haya creado, deberá utilizar el ObjectGUID ensuEl objeto de la cuenta AD como su ID inmutable en el lado de Azure.
Los usé como referencia, pero incluiré la información en caso de que estas URL desaparezcan en el futuro:
Necesita codificar en base64 el ObjectGUID para su usuario y configurarlo. El GUID que codifique no debe incluir los corchetes:
El script aquí hace la conversión por usted: http://gallery.technet.microsoft.com/office/Covert-DirSyncMS-Online-5f3563b1
GUID del objeto AD (en "Formato de registro") 748b2d72-706b-42f8-8b25-82fd8733860f
Codificado: ci2LdGtw+EKLJYL9hzOGDw==
Lo configura en la cuenta en Azure a través de PowerShell:
Set-MsolUser -UserPrincipalName[correo electrónico protegido]-ImmutableId "ci2LdGtw+EKLJYL9hzOGDw=="
Asegúrese de que el UPN en su cuenta de usuario (en el lado de su dominio AD) coincida con el[correo electrónico protegido]UPN que Office 365 tiene de su lado, o obtendrá un error extraño en el lado de Azure. Creo que el código de error es 8004786C.
Si no tiene el sufijo UPN disponible para configurar en su usuario en su entorno AD, debe agregar ese sufijo a través de "Dominios y confianzas de Active Directory". O si quiere ser inteligente, establezca otro atributo en su cuenta de AD y haga que ADFS envíe ese atributo como ID inmutable. Si no sabe a qué me refiero, simplemente configure el UPN. :)
Microsoft Office 365 no aparecerá como una opción en un menú desplegable iniciado por ADFS IDP en su servidor. Parece que fue iniciado por SP y debes activar el baile SAML yendo primero a su portal:https://portal.microsoftonline.com
Puedes usar algo como Fiddler para capturar la conversación SSL y luego analizar cierta información.http://community.office365.com/en-us/wikis/sso/using-smart-links-or-idp-initiated-authentication-with-office-365.aspxpara tener una sensación más iniciada por IDP, donde el usuario hace clic en su enlace y accede a un inicio de sesión agradable y fluido en Office 365 sin ingresar nada.
Respuesta3
¿Esto ayuda en algo?http://technet.microsoft.com/en-us/library/dn296436.aspx
Ha pasado un tiempo desde que hice lo que me pides, pero eso estaba en mis notas.