Commutateur SupportMultipleDomain lors de la gestion de l’authentification unique vers Office 365

Notes

Office 365 ProPlus est renommé Applications Microsoft 365 pour les entreprises. Pour plus d’informations sur ce changement, lisez ce billet de blog.

Résumé

Utilisation du commutateur SupportMultipleDomain lors de la gestion de l’authentification unique vers Office 365 à l’aide d’ADFS

Lorsqu’une authentification unique est activée pour O365 via ADFS, vous devez voir l’approbation de la partie de confiance (RP) créée pour O365.

Capture d’écran des services ADFS (Active Directory Federation Services), avec une approbation de partie de confiance (RP) créée pour O365

Les commandes qui créeraient la relation de confiance RP pour O365 sont les suivantes :

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

L’approbation RP créée ci-dessus a été fournie avec 2 règles de revendication

Get-MsolFederationProperty-DomainName sur les domaines fédérés indique que le « FederationServiceIdentifier » était le même pour source ADFS et O365, c.-à-d. lehttp://stsname/adfs/Services/trust

Avant la mise à jour des services ADFS Rollup 1 et Rollup 2 , les clients Microsoft Office 365 qui utilisent l’authentification unique (SSO) via AD FS 2,0 ont plusieurs domaines de niveau supérieur pour les suffixes UPN (nom d’utilisateur principal) de leur organisation (par exemple, @contoso.com ou @fabrikam.com ) sont requis pour déployer une instance distincte du service de fédération AD FS 2,0 pour chaque suffixe.Il existe maintenant un correctif cumulatif pour AD FS 2,0 ( https://support.microsoft.com/kb/2607496 ) qui fonctionne en association avec le commutateur « SupportMultipleDomain » pour permettre au serveur AD FS de prendre en charge ce scénario sans avoir besoin de serveurs AD fs 2,0 supplémentaires.

Avec la mise à jour cumulative ADFS 1, nous avons ajouté les fonctionnalités suivantes :

Plusieurs émetteurs pris en charge

«Auparavant, les clients Microsoft Office 365 qui nécessitent l’authentification unique (SSO) à l’aide d’AD FS 2,0 et utilisent plusieurs domaines de niveau supérieur pour les suffixes UPN (nom d’utilisateur principal) de leur organisation (par exemple, @contoso.us ou @contoso.de ) sont requis pour déployer une instance distincte du service de fédération AD FS 2,0 pour chaque suffixe. Une fois que vous avez installé ce correctif cumulatif sur tous les serveurs de fédération AD FS 2,0 dans la batterie de serveurs et suivez les instructions d’utilisation de cette fonctionnalité avec Office 365, de nouvelles règles de revendication seront définies pour générer dynamiquement les ID d’émetteur de jeton en fonction des suffixes UPN des utilisateurs d’Office 365. Par conséquent, vous n’avez pas besoin de configurer plusieurs instances du serveur de fédération AD FS 2,0 pour prendre en charge l’authentification unique pour plusieurs domaines de niveau supérieur dans Office 365. "

Prise en charge de plusieurs domaines de niveau supérieur

«Actuellement, les clients Microsoft Office 365 qui utilisent l’authentification unique (SSO) via AD FS 2,0 et ont plusieurs domaines de niveau supérieur pour les suffixes UPN (nom d’utilisateur principal) de leur organisation (par exemple, @contoso.com ou @fabrikam.com ) sont requis pour déployer une instance distincte du service de fédération AD FS 2,0 pour chaque suffixe.Il existe maintenant un correctif cumulatif pour AD FS 2,0 ( https://support.microsoft.com/kb/2607496 ) qui fonctionne en association avec le commutateur « SupportMultipleDomain » pour permettre au serveur AD FS de prendre en charge ce scénario sans avoir besoin de serveurs AD fs 2,0 supplémentaires.

Les commandes qui créeraient la relation de confiance RP pour O365 sont les suivantes :

New-MsolFederatedDomain -DomainName<domain>-SupportMultiDomain

Update-MSOLFederatedDomain -DomainName <domain>-SupportMultipleDomain

Convert-MsolDomainToFederated -DomainName <domain>-supportMultipleDomain

Get-MsolFederationProperty-DomainName sur les domaines fédérés indique désormais que le « FederationServiceIdentifier » est différent pour ADFS et O365. Chaque domaine fédéré aura le « FederationServiceIdentifier » comme http:// <domainname> /ADFS/Services/Trust/tandis que la configuration ADFS a toujourshttp://STSname/adfs/Services/trust

En raison d’une incompatibilité incorrecte dans la configuration, nous devons vous assurer que lorsqu’un jeton est envoyé à O365, l’émetteur mentionné dans celui-ci est le même que celui configuré pour le domaine dans O365. Si ce n’est pas le cas, vous obtiendrez l’erreur suivante :

Par conséquent, lors de l’ajout ou de la mise à jour de l’approbation RP avec le commutateur SupportMultipleDomain, une troisième règle de revendication est automatiquement ajoutée à la relation d’approbation RP pour O365.

Règle de la troisième règle par défaut :

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

Cette règle utilise la valeur de suffixe UPN de l’utilisateur et l’utilise pour générer une nouvelle revendication appelée « Issuerid ». Exemple http://contoso.com/adfs/services/trust/.

À l’aide de Fiddler, nous pouvons suivre le jeton transmis à login.microsoftonline.com/login.srf. Après avoir copié le jeton transmis dans wresult, collez le contenu dans le bloc-notes et enregistrez ce fichier au format. Xml. Par la suite, vous pouvez ouvrir le jeton enregistré sous forme de fichier. XML à l’aide d’Internet Explorer et afficher son contenu.

Capture d’écran de Fidder

Il est intéressant de noter que la règle émet une revendication « Issuerid », mais que cette revendication n’apparaît pas dans le jeton de réponse, l’attribut « Issuer » est alors modifié et remplacé par la nouvelle valeur composée.

<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">

NOTE

  • SupportMultipleDomain est utilisé sans le correctif ADFS 1 ou 2 installé. Vous verrez que le jeton de réponse généré par ADFS a à la fois l’émetteur = « http://STSname/adfs/Services/trust » et la revendication « Issuerid » avec la valeur composée, conformément à la troisième règle de revendication.

    <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"
    

Prise en charge des sous-domaines

« Il est important de noter que le commutateur «SupportMultipleDomain » n’est pas obligatoire lorsque vous disposez d’un seul domaine de niveau supérieur et de plusieurs sous-domaines.Par exemple, si les domaines utilisés pour les suffixes UPN sont @sales.contoso.com @marketing.contoso.com et @contoso.com et que le domaine de niveau supérieur (contoso.com dans ce cas) a été ajouté en premier, puis fédéré, vous n’avez pas besoin d’utiliser le commutateur « SupportMultipleDomain ».Cela est dû au fait que ces sous-domaines sont gérés efficacement dans l’étendue du parent et qu’un seul serveur AD FS peut être utilisé pour le gérer. "

Toutefois, si vous avez plusieurs domaines de niveau supérieur ( @contoso.com et @fabrikam.com ) et que ces domaines possèdent également des sous-domaines ( @sales.contoso.com et @sales.fabrikam.com ), le commutateur « SupportMultipleDomain » ne fonctionnera pas pour les sous-domaines et ces utilisateurs ne pourront pas se connecter.

Pourquoi ce commutateur ne fonctionnera-t-il pas dans le scénario ci-dessus ?

Réponse :

  • Pour le domaine enfant partageant le même espace de noms, nous ne les fédérer pas séparément. Le domaine racine fédéré couvre également l’enfant, ce qui signifie que la valeur federationServiceIdentifier pour le domaine enfant sera également identique à celle de parent, c.-à-d. https://contoso.com/adfs/services/trust/ .

  • Toutefois, la troisième règle de revendication, qui finit par sélectionner le suffixe UPN de l’utilisateur pour la composition de la valeur de l’émetteur https://Child1.contoso.com/adfs/services/trust/ , provoque de nouveau une incompatibilité et, par conséquent, l’erreur suivante : « votre organisation n’a pas pu vous connecter à ce service ».

    Pour résoudre ce problème, nous pouvons modifier la troisième règle de manière à ce qu’elle termine la génération d’une valeur Issuer correspondant à « FederationServiceIdentifier » pour le domaine à la fin de O365. 2 les différentes règles qui peuvent fonctionner dans ce scénario sont les suivantes. Cette règle sélectionne simplement le domaine racine à partir du suffixe UPN pour composer la valeur de l’émetteur. Pour un suffixe UPN child1.contoso.com, il génère toujours une valeur d’émetteur https://contoso.com/adfs/services/trust/ au lieu de https://Child1.contoso.com/adfs/services/trust/ (avec la règle par défaut).

Capture d’écran de la règle de revendication

Règle tierce personnalisée

Règle 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/"));

Règle 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/)"));

NOTE

Les règles ci-dessus peuvent ne pas s’appliquer à tous les scénarios, mais peuvent être personnalisées pour s’assurer que la valeur « Issuerid » correspond à « FederationServiceIdentifier » pour le domaine ajouté/fédéré à la fin de O365.

L’incompatibilité des federationServiceIdentifier entre ADFS et O365 pour un domaine peut également être corrigée en modifiant le « federationServiceIdentifier » pour le domaine à la fin de la page O365, de sorte qu’il corresponde à « federationServiceIdentifier » pour ADFS. Toutefois, le federationServiceIdentifier peut uniquement être configuré pour un domaine fédéré et pas pour tous.

Set-MSOLDomainFederationSettings-nom de domaine Contoso.com – issuerurihttp://STS.contoso.com/adfs/services/trust/

Plus d’informations pour vous aider à écrire vos propres règles de revendication. * *