Compartir a través de

Conmutador SupportMultipleDomain al administrar el inicio de sesión único en Microsoft 365

  • Se aplica a: Microsoft 365

Resumen

Uso del conmutador SupportMultipleDomain al administrar el inicio de sesión único en Microsoft 365 mediante AD FS

Cuando se habilita un inicio de sesión único para Microsoft 365 a través de AD FS, debería ver la relación de terceros de confianza (RP) creada para Microsoft 365.

Captura de pantalla que muestra la confianza de la entidad de confianza creada para Microsoft 365.

Comandos que crearían la confianza de RP para Microsoft 365

New-MsolFederatedDomain -DomainName<domain>
Update-MSOLFederatedDomain -DomainName <domain>
Convert-MsolDomainToFederated -DomainName <domain>

Nota:

Los módulos de PowerShell de Azure AD y MSOnline están en desuso a partir del 30 de marzo de 2024. Para obtener más información, lea la notificación de obsolescencia. Desde esta fecha, el soporte de estos módulos se limita a la asistencia de migración al SDK de PowerShell de Microsoft Graph y a las correcciones de seguridad. Los módulos obsoletos seguirán funcionando hasta el 30 de marzo de 2025.

Se recomienda migrar a Microsoft Graph PowerShell para interactuar con el identificador de Entra de Microsoft (anteriormente Azure AD). Para preguntas comunes sobre la migración, consulta las Preguntas más frecuentes sobre migración. Nota: Las versiones 1.0.x de MSOnline podrían experimentar interrupciones después del 30 de junio de 2024.

El fideicomiso de RP creado llegó con dos reglas de reclamaciones.

Get-MsolFederationProperty -DomainName <domain> en los dominios federados se muestra que el "FederationServiceIdentifier" era el mismo para el origen de AD FS y de Microsoft 365, que es http://stsname/adfs/Services/trust.

Antes de las actualizaciones Rollup 1 y Rollup 2 de AD FS, los clientes de Microsoft 365 que utilizan SSO a través de AD FS 2.0 y tienen varios dominios de nivel superior para los sufijos UPN de los usuarios dentro de su organización (por ejemplo, @contoso.com o @fabrikam.com)) están obligados a implementar una instancia independiente del servicio de federación de AD FS 2.0 para cada sufijo. Ahora hay un paquete acumulativo para AD FS 2.0 (https://support.microsoft.com/kb/2607496) que funciona con el interruptor "SupportMultipleDomain" para permitir que el servidor de AD FS soporte este escenario sin necesidad de más servidores de AD FS 2.0.

Con la actualización acumulativa 1 de AD FS, hemos incorporado la siguiente funcionalidad.

Soporte para múltiples emisores

Anteriormente, los clientes de Microsoft 365 que requieren SSO mediante AD FS 2.0 y usan varios dominios de nivel superior para los sufijos UPN de los usuarios dentro de su organización (por ejemplo, @contoso.us o @contoso.de) son necesarios para implementar una instancia independiente del servicio de federación de AD FS 2.0 para cada sufijo. Después de instalar este paquete acumulativo de actualizaciones en todos los servidores de federación AD FS 2.0 del grupo de servidores y seguir las instrucciones para usar esta característica con Microsoft 365, las nuevas reglas de declaración se establecerán para generar dinámicamente identificadores de emisores de tokens basados en los sufijos UPN de los usuarios de Microsoft 365. Como resultado, no es necesario configurar varias instancias del servidor de federación de AD FS 2.0 para admitir el inicio de sesión único para varios dominios de nivel superior en Microsoft 365.

Compatibilidad con varios dominios de Top-Level

"Actualmente, los clientes de Microsoft 365 que usan el inicio de sesión único (SSO) a través de AD FS 2.0 y tienen varios dominios de nivel superior para los sufijos de nombre principal de usuario (UPN) de los usuarios dentro de su organización (por ejemplo, @contoso.com o @fabrikam.com) son necesarios para implementar una instancia independiente del servicio de federación de AD FS 2.0 para cada sufijo. Ahora hay una actualización acumulativa para AD FS 2.0 (https://support.microsoft.com/kb/2607496) que funciona con el modificador "SupportMultipleDomain" para permitir que el servidor AD FS soporte este escenario sin necesidad de más servidores AD FS 2.0.

Comandos que crearían la confianza de RP para Microsoft 365

New-MsolFederatedDomain -DomainName<domain>-SupportMultiDomain

Update-MSOLFederatedDomain -DomainName <domain>-SupportMultipleDomain

Convert-MsolDomainToFederated -DomainName <domain>-supportMultipleDomain

Get-MsolFederationProperty -DomainName <domain> en los dominios federados ahora muestra que "FederationServiceIdentifier" es diferente para AD FS y Microsoft 365. Cada dominio federado tiene "FederationServiceIdentifier" como http://<domainname>/adfs/services/trust/, mientras que la configuración de AD FS todavía tiene http://STSname/adfs/Services/trust.

Debido a esta falta de coincidencia en la configuración, es necesario asegurarnos de que, cuando se envía un token a Microsoft 365, el emisor mencionado en ella es el mismo que el configurado para el dominio en Microsoft 365. De lo contrario, obtendrá un error.

Por lo tanto, al agregar o actualizar la confianza de RP con el modificador SupportMultipleDomain, se agrega automáticamente una tercera regla de reclamaciones a la confianza de RP para Microsoft 365.

Tercera regla predeterminada:

c:[Type == "http://schemas.xmlsoap.org/claims/UPN](http://schemas.xmlsoap.org/claims/UPN"] => issue(Type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, .+@(?<domain>.+), http://${domain}/adfs/services/trust/));

Esta regla usa el valor de sufijo del UPN del usuario y lo usa para generar una nueva notificación denominada "Issuerid". Por ejemplo: http://contoso.com/adfs/services/trust/.

Con fiddler, podemos realizar un seguimiento del token que se pasa a login.microsoftonline.com/login.srf. Después de copiar el token pasado en wresult, pegue el contenido en el Bloc de notas y guarde ese archivo como .xml. Más adelante puede abrir el token guardado como archivo .xml mediante IE y ver su contenido.

Captura de pantalla para copiar el token de seguridad pasado en wresult.

Es interesante tener en cuenta que la regla emite la afirmación "Issuerid"; no vemos esta afirmación en el token de respuesta; en realidad, vemos el atributo "Emisor" modificado al valor recientemente compuesto.

<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_2546eb2e-a3a6-4cf3-9006-c9f20560097f"Issuer="[http://contoso.com/adfs/services/trust/](http://contoso.com/adfs/services/trust/)" IssueInstant="2012-12-23T04:07:30.874Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

NOTA:

  • SupportMultipleDomain se utiliza sin tener instalado el paquete de actualizaciones acumulativas de AD FS 1 o 2. Verá que el token de respuesta generado por AD FS tiene tanto el Emisor="http://STSname/adfs/Services/trust" como la declaración "Issuerid" con el valor compuesto según la tercera regla de declaración.

    <saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_2546eb2e-a3a6-4cf3-9006-c9f20560097f"Issuer=`http://STS.contoso.com/adfs/services/trust/` IssueInstant="2012-12-23T04:07:30.874Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

…

<saml:Attribute AttributeName="issuerid" AttributeNamespace="[http://schemas.microsoft.com/ws/2008/06/identity/claims](http://schemas.microsoft.com/ws/2008/06/identity/claims)"><saml:AttributeValue>[http://contoso.com/adfs/services/trust/</saml:AttributeValue](http://contoso.com/adfs/services/trust/%3c/saml:AttributeValue)></saml:Attribute>
- This will again lead to error "Your organization could not sign you in to this service"

Compatibilidad con subdominios

Es importante tener en cuenta que el comando "SupportMultipleDomain" no es necesario cuando se tiene un único dominio de nivel superior y varios subdominios. Por ejemplo, si los dominios usados para los sufijos UPN son @sales.contoso.com, @marketing.contoso.com y @contoso.com, y el dominio de nivel superior (contoso.com en este caso) se agregó primero y se federó, entonces no es necesario usar el conmutador "SupportMultipleDomain". Estos subdominios se administran eficazmente dentro del ámbito del elemento primario y se puede usar un único servidor de AD FS para controlar este escenario.

Si, sin embargo, tiene varios dominios de nivel superior (@contoso.com y @fabrikam.com)), y ya que estos dominios también tienen subdominios (@sales.contoso.com y @sales.fabrikam.com)), el modificador "SupportMultipleDomain" no funcionará para los subdominios y estos usuarios no podrán iniciar sesión.

¿Por qué este cambio no funcionará, en el escenario anterior?

Respuesta:

  • Para los dominios hijo que comparten el mismo espacio de nombres, no los federamos por separado. El dominio raíz federado también incluye al dominio secundario, lo que significa que el valor federationServiceIdentifier del dominio secundario será el mismo que el del dominio primario, es decir, https://contoso.com/adfs/services/trust/.

  • Pero la tercera regla de afirmación, que acaba seleccionando el sufijo UPN para que el usuario redacte el valor del emisor, termina con https://Child1.contoso.com/adfs/services/trust/, lo que provoca un error de coincidencia de nuevo y, por tanto, el error "Su organización no pudo iniciar sesión en este servicio".

    Para resolver este problema, modifique la tercera regla de modo que termine generando un valor del emisor que coincida con "FederationServiceIdentifier" para el dominio al final de Microsoft 365. A continuación se muestran dos reglas diferentes que pueden funcionar en este escenario. Esta regla simplemente recoge el dominio raíz del sufijo UPN para componer el valor del emisor. Para un sufijo UPN, child1.contoso.com, seguirá generando un valor de Emisor de https://contoso.com/adfs/services/trust/ en lugar de https://Child1.contoso.com/adfs/services/trust/ (con la regla predeterminada)

Captura de pantalla de la selección de la opción Editar regla para modificar la tercera regla.

Tercera regla personalizada

Regla 1:

c:[Type == `http://schemas.xmlsoap.org/claims/UPN`]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, "^((.*)([.|@]))?(?<domain>[^.]*[.].*)$", "http://${domain}/adfs/services/trust/"));

Regla 2:

c:[Type == `http://schemas.xmlsoap.org/claims/UPN`]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value =regexreplace(c.Value, "^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$", "[http://${domain}/adfs/services/trust/](http://$%7bdomain%7d/adfs/services/trust/)"));

NOTA:

Es posible que estas reglas no se apliquen a todos los escenarios, pero se pueden personalizar para asegurarse de que el valor "Issuerid" coincide con "FederationServiceIdentifier" para el dominio agregado o federado al final de Microsoft 365.

La discordancia de "federationServiceIdentifier" entre AD FS y Microsoft 365 para un dominio también se puede corregir modificando "federationServiceIdentifier" para el dominio en el extremo de Microsoft 365, para que coincida con "federationServiceIdentifier" para AD FS. Pero federationServiceIdentifier solo se puede configurar para un dominio federado y no para todos.

Set-MSOLDomainFederationSettings -domain nombre Contoso.com –issueruri http://STS.contoso.com/adfs/services/trust/

Más información que puede ayudarle a escribir sus propias reglas de reclamación.