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

• S’applique à:

  Microsoft 365

Résumé

Utilisation du commutateur SupportMultipleDomain lors de la gestion de l’authentification unique vers Microsoft 365 à l’aide d’AD FS

Lorsqu’une authentification unique est activée pour Microsoft 365 via AD FS, vous devez voir l’approbation de partie de confiance créée pour Microsoft 365.

Commandes qui créeraient l’approbation rp pour Microsoft 365

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

Remarque

Les modules PowerShell Azure AD et MSOnline sont déconseillés à compter du 30 mars 2024. Pour en savoir plus, lisez la mise à jour déconseillée. Après cette date, la prise en charge de ces modules est limitée à l’assistance à la migration vers le Kit de développement logiciel (SDK) Microsoft Graph PowerShell et aux correctifs de sécurité. Les modules déconseillés continueront de fonctionner jusqu’au 30 mars 2025.

Nous vous recommandons de migrer vers Microsoft Graph PowerShell pour interagir avec Microsoft Entra ID (anciennement Azure AD). Pour les questions courantes sur la migration, reportez-vous au FAQ sur la migration. Note: Les versions 1.0.x de MSOnline peuvent être interrompues après le 30 juin 2024.

L’approbation rp créée était accompagnée de deux règles de revendication

Get-MsolFederationProperty -DomainName <domain> sur les domaines fédérés montre que « FederationServiceIdentifier » était identique pour AD FS source et Microsoft 365, qui est http://stsname/adfs/Services/trust.

Avant les mises à jour des correctifs cumulatifs 1 et 2 d’AD FS, les clients Microsoft 365 qui utilisent l’authentification unique via AD FS 2.0 et qui ont plusieurs domaines de niveau supérieur pour les suffixes UPN des utilisateurs au sein de leur organization (par exemple, @contoso.com ou @fabrikam.com) qui doivent déployer un instance distinct du service de fédération AD FS 2.0 pour chaque suffixe. Il existe désormais un correctif cumulatif pour AD FS 2.0 (https://support.microsoft.com/kb/2607496) qui fonctionne avec le commutateur « SupportMultipleDomain » pour permettre au serveur AD FS de prendre en charge ce scénario sans nécessiter d’autres serveurs AD FS 2.0.

Avec la mise à jour cumulative 1 d’AD FS, nous avons ajouté les fonctionnalités suivantes

Prise en charge de plusieurs émetteurs

Auparavant, les clients Microsoft 365 qui ont besoin de l’authentification unique à l’aide d’AD FS 2.0 et qui utilisent plusieurs domaines de niveau supérieur pour les suffixes UPN des utilisateurs au sein de leur organization (par exemple, @contoso.us ou @contoso.de) sont tenus de déployer un instance distinct du service de fédération AD FS 2.0 pour chaque suffixe. Après avoir installé ce correctif cumulatif sur tous les serveurs de fédération AD FS 2.0 de la batterie et suivi les instructions d’utilisation de cette fonctionnalité avec Microsoft 365, les nouvelles règles de revendication sont définies pour générer dynamiquement des ID d’émetteur de jeton en fonction des suffixes UPN des utilisateurs de Microsoft 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 Microsoft 365.

Prise en charge de plusieurs domaines Top-Level

« Actuellement, les clients Microsoft 365 qui utilisent l’authentification unique (SSO) via AD FS 2.0 et qui ont plusieurs domaines de niveau supérieur pour les suffixes DE nom d’utilisateur principal (UPN) des utilisateurs au sein de leur organization (par exemple, @contoso.com ou @fabrikam.com) doivent déployer un instance distinct du service de fédération AD FS 2.0 pour chaque suffixe. Il existe désormais un correctif cumulatif pour AD FS 2.0 (https://support.microsoft.com/kb/2607496) qui fonctionne avec le commutateur « SupportMultipleDomain » pour permettre au serveur AD FS de prendre en charge ce scénario sans nécessiter d’autres serveurs AD FS 2.0.

Commandes qui créeraient l’approbation rp pour Microsoft 365

New-MsolFederatedDomain -DomainName<domain>-SupportMultiDomain

Update-MSOLFederatedDomain -DomainName <domain>-SupportMultipleDomain

Convert-MsolDomainToFederated -DomainName <domain>-supportMultipleDomain

Get-MsolFederationProperty -DomainName <domain> sur les domaines fédérés montre maintenant que « FederationServiceIdentifier » est différent pour AD FS et Microsoft 365. Chaque domaine fédéré a le « FederationServiceIdentifier » en tant que http://<domainname>/adfs/services/trust/, tandis que la configuration AD FS a http://STSname/adfs/Services/trusttoujours .

En raison de cette incompatibilité dans la configuration, nous devons nous assurer que lorsqu’un jeton est envoyé à Microsoft 365, l’émetteur mentionné dans celui-ci est identique à celui configuré pour le domaine dans Microsoft 365. Sinon, vous obtenez l’erreur.

Par conséquent, lorsque vous ajoutez ou mettez à jour l’approbation rp avec le commutateur SupportMultipleDomain, une troisième règle de revendication est automatiquement ajoutée à l’approbation rp pour Microsoft 365.

Troisième règle par défaut :

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/)) ;

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

À l’aide de Fiddler, nous pouvons suivre le jeton passé à login.microsoftonline.com/login.srf. Après avoir copié le jeton passé dans wresult, collez le contenu dans le Bloc-notes et enregistrez ce fichier en tant que .xml. Plus tard, vous pouvez ouvrir le jeton enregistré en tant que fichier .xml à l’aide d’Internet Explorer et voir son contenu.

Il est intéressant de noter que la règle émet la revendication « Issuerid », nous ne voyons pas cette revendication dans le jeton de réponse, en fait nous voyons l’attribut « Issuer » modifié pour la valeur nouvellement 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">

REMARQUE

• SupportMultipleDomain est utilisé sans le correctif cumulatif AD FS 1 ou 2 installé. Vous verrez que le jeton de réponse généré par AD FS a à la fois issuer="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 nécessaire lorsque vous avez un seul domaine de niveau supérieur et plusieurs sous-domaines. Par exemple, si les domaines utilisés pour les suffixes UPN sont @sales.contoso.com, @marketing.contoso.comet @contoso.com, et que le domaine de niveau supérieur (contoso.com dans ce cas) a été ajouté en premier et fédéré, vous n’avez pas besoin d’utiliser le commutateur « SupportMultipleDomain ». Ces sous-domaines sont gérés efficacement dans l’étendue du parent, et un seul serveur AD FS peut être utilisé pour gérer ce scénario.

Toutefois, si vous avez plusieurs domaines de niveau supérieur (@contoso.com et @fabrikam.com), et que ces domaines ont é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 fonctionne-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érons 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 du parent, c’est-à-dire https://contoso.com/adfs/services/trust/.

• Mais la troisième règle de revendication, qui finit par récupérer le suffixe UPN pour que l’utilisateur compose la valeur Issuer se retrouve avec https://Child1.contoso.com/adfs/services/trust/, ce qui provoque une incompatibilité et par conséquent l’erreur « Votre organization n’a pas pu vous connecter à ce service ».

  Pour résoudre ce problème, modifiez la troisième règle de sorte qu’elle finisse par générer une valeur d’émetteur qui correspond à « FederationServiceIdentifier » pour le domaine à la fin de Microsoft 365. Vous trouverez ci-dessous deux règles différentes qui peuvent fonctionner dans ce scénario. Cette règle récupère simplement le domaine racine à partir du suffixe UPN pour composer la valeur Issuer. Pour un suffixe UPN child1.contoso.com, il génère toujours une valeur Issuer de https://contoso.com/adfs/services/trust/ au lieu de (avec la https://Child1.contoso.com/adfs/services/trust/ règle par défaut)

Troisième règle 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/)"));

REMARQUE

Ces règles peuvent ne pas s’appliquer à tous les scénarios, mais peuvent être personnalisées pour garantir que la valeur « Issuerid » correspond à « FederationServiceIdentifier » pour le domaine ajouté/fédéré à la fin de Microsoft 365.

L’incompatibilité de federationServiceIdentifier entre AD FS et Microsoft 365 pour un domaine peut également être corrigée en modifiant « federationServiceIdentifier » pour le domaine à la fin de Microsoft 365, afin qu’il corresponde à « federationServiceIdentifier » pour AD FS. Toutefois, federationServiceIdentifier ne peut être configuré que pour UN domaine fédéré et pas pour tous.

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

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

• Rôle du langage de règle de revendication
• Expressions régulières