SupportMultipleDomain-växel vid hantering av enkel inloggning till Microsoft 365

• Gäller för:

  Microsoft 365

Sammanfattning

Användning av SupportMultipleDomain-växel när du hanterar enkel inloggning till Microsoft 365 med AD FS

När en enkel inloggning är aktiverad för Microsoft 365 via AD FS bör du se det förlitande partsförtroendet (RP) som skapats för Microsoft 365.

Kommandon som skulle skapa RP-förtroendet för Microsoft 365

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

Obs!

Azure AD- och MSOnline PowerShell-modulerna är inaktuella från och med den 30 mars 2024. Mer information finns i utfasningsuppdateringen. Efter det här datumet är stödet för dessa moduler begränsat till migreringshjälp till Microsoft Graph PowerShell SDK och säkerhetskorrigeringar. De inaktuella modulerna fortsätter att fungera till och med den 30 mars 2025.

Vi rekommenderar att du migrerar till Microsoft Graph PowerShell för att interagera med Microsoft Entra ID (tidigare Azure AD). Vanliga migreringsfrågor finns i Vanliga frågor och svar om migrering. Observera: Version 1.0.x av MSOnline kan uppleva störningar efter den 30 juni 2024.

Det skapade RP-förtroendet kom med två anspråksregler

Get-MsolFederationProperty -DomainName <domain> på de federerade domänerna visar att "FederationServiceIdentifier" var samma för källan AD FS och Microsoft 365, som är http://stsname/adfs/Services/trust.

Tidigare före uppdateringarna för AD FS Sammanslagning 1 och Sammanslagning 2 har Microsoft 365-kunder som använder enkel inloggning via AD FS 2.0 och har flera toppnivådomäner för användarnas UPN-suffix i organisationen (till exempel @contoso.com eller @fabrikam.com) måste distribuera en separat instans av AD FS 2.0 Federation Service för varje suffix. Det finns nu en sammanslagning för AD FS 2.0 (https://support.microsoft.com/kb/2607496) som fungerar med växeln "SupportMultipleDomain" för att göra det möjligt för AD FS-servern att stödja det här scenariot utan att kräva fler AD FS 2.0-servrar.

Med ad FS-uppdateringen för sammanslagning 1 har vi lagt till följande funktioner

Flera utfärdare stöder

Tidigare har Microsoft 365-kunder som behöver enkel inloggning med hjälp av AD FS 2.0 och använder flera toppnivådomäner för användarnas UPN-suffix i organisationen (till exempel @contoso.us eller @contoso.de) krävs för att distribuera en separat instans av AD FS 2.0 Federation Service för varje suffix. När du har installerat den här samlade uppdateringen på alla AD FS 2.0-federationsservrar i servergruppen och följer anvisningarna för att använda den här funktionen med Microsoft 365, kommer nya anspråksregler att ställas in för att dynamiskt generera token utfärdar-ID:n baserat på UPN-suffixen för Microsoft 365-användarna. Därför behöver du inte konfigurera flera instanser av AD FS 2.0-federationsservern för att stödja enkel inloggning för flera toppnivådomäner i Microsoft 365.

Stöd för flera Top-Level domäner

"För närvarande har Microsoft 365-kunder som använder enkel inloggning (SSO) via AD FS 2.0 och har flera toppnivådomäner för användarnas UPN-suffix (user principal name) i organisationen (till exempel @contoso.com eller @fabrikam.com) krävs för att distribuera en separat instans av AD FS 2.0 Federation Service för varje suffix. Det finns nu en sammanslagning för AD FS 2.0 (https://support.microsoft.com/kb/2607496) som fungerar med växeln "SupportMultipleDomain" för att göra det möjligt för AD FS-servern att stödja det här scenariot utan att kräva fler AD FS 2.0-servrar.

Kommandon som skulle skapa RP-förtroendet för Microsoft 365

New-MsolFederatedDomain -DomainName<domain>-SupportMultiDomain

Update-MSOLFederatedDomain -DomainName <domain>-SupportMultipleDomain

Convert-MsolDomainToFederated -DomainName <domain>-supportMultipleDomain

Get-MsolFederationProperty -DomainName <domain> på de federerade domänerna visar nu att "FederationServiceIdentifier" skiljer sig åt för AD FS och Microsoft 365. Varje federerad domän har "FederationServiceIdentifier" som http://<domainname>/adfs/services/trust/, medan AD FS-konfigurationen fortfarande har http://STSname/adfs/Services/trust.

På grund av det här matchningsfelet i konfigurationen måste vi se till att när en token skickas till Microsoft 365 är utfärdaren som nämns i den samma som den som konfigurerats för domänen i Microsoft 365. Annars får du felet.

Så när du lägger till eller uppdaterar RP-förtroende med SupportMultipleDomain-växeln läggs en tredje anspråksregel automatiskt till i RP-förtroendet för Microsoft 365.

Tredje standardregel:

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

Den här regeln använder suffixvärdet för användarens UPN och använder det för att generera ett nytt anspråk med namnet "Issuerid". Till exempel http://contoso.com/adfs/services/trust/.

Med fiddler kan vi spåra token som skickas till login.microsoftonline.com/login.srf. När du har kopierat token som skickats klistrar wresultdu in innehållet i Anteckningar och sparar filen som .xml. Senare kan du öppna token som sparats som .xml fil med hjälp av IE och se dess innehåll.

Det är intressant att notera att regeln utfärdar "Issuerid"-anspråket, vi ser inte det här anspråket i svarstoken, i själva verket ser vi attributet "Issuer" ändrat till det nyligen sammansatta värdet.

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

Obs!

• SupportMultipleDomain används utan ad FS-sammanslagning 1 eller 2 installerat. Du ser att svarstoken som genereras av AD FS har BÅDE Issuer="http://STSname/adfs/Services/trust" och anspråket "Issuerid" med det sammansatta värdet enligt den tredje anspråksregeln.

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

Stöd för underdomäner

Observera att växeln "SupportMultipleDomain" inte krävs när du har en enda toppnivådomän och flera underdomäner. Om domänerna som används för UPN-suffix till exempel är @sales.contoso.com, @marketing.contoso.comoch @contoso.com, och toppnivådomänen (contoso.com i det här fallet) lades till först och federerades, behöver du inte använda växeln "SupportMultipleDomain". Dessa underdomäner hanteras effektivt inom det överordnade omfånget och en enda AD FS-server kan användas för att hantera det här scenariot.

Om du däremot har flera toppnivådomäner (@contoso.com och @fabrikam.com), och dessa domäner också har underdomäner (@sales.contoso.com och @sales.fabrikam.com), fungerar inte växeln "SupportMultipleDomain" för underdomänerna och dessa användare kan inte logga in.

Varför fungerar inte den här växeln i scenariot ovan?

Svar:

• För den underordnade domänen, som delar samma namnområde, federerar vi dem inte separat. Den federerade rotdomänen omfattar även det underordnade, vilket innebär att federationServiceIdentifier-värdet för den underordnade domänen också är samma som för den överordnade domänen, det vill https://contoso.com/adfs/services/trust/säga .

• Men den tredje anspråksregeln, som slutar med att användaren hämtar UPN-suffixet för att skapa utfärdarvärdet, slutar med https://Child1.contoso.com/adfs/services/trust/, vilket återigen orsakar ett matchningsfel och därmed felet "Din organisation kunde inte logga in dig på den här tjänsten".

  Lös problemet genom att ändra den tredje regeln så att den genererar ett Utfärdarvärde som matchar "FederationServiceIdentifier" för domänen i Microsoft 365-slut. Två olika regler som kan fungera i det här scenariot finns nedan. Den här regeln hämtar bara rotdomänen från UPN-suffixet för att skapa utfärdarvärdet. För ett UPN-suffix child1.contoso.com genereras fortfarande ett Utfärdarvärde https://contoso.com/adfs/services/trust/ i stället för https://Child1.contoso.com/adfs/services/trust/ (med standardregel)

Anpassad tredje regel

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

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

Obs!

Dessa regler kanske inte gäller för alla scenarier, men kan anpassas för att säkerställa att värdet "Issuerid" matchar "FederationServiceIdentifier" för domänen som läggs till/federeras i Microsoft 365-slut.

Matchningsfelet för federationServiceIdentifier mellan AD FS och Microsoft 365 för en domän kan också korrigeras genom att ändra "federationServiceIdentifier" för domänen i Microsoft 365-slut så att den matchar "federationServiceIdentifier" för AD FS. Men federationServiceIdentifier kan bara konfigureras för en federerad domän och inte alla.

Set-MSOLDomainFederationSettings – domännamn Contoso.com – issueruri http://STS.contoso.com/adfs/services/trust/

Mer information som hjälper dig att skriva egna anspråksregler.**

• Anspråksregelspråkets roll
• Reguljära uttryck