SupportMultipleDomain byt vid hantering av SSO till Office 365

Anteckning

Office 365 ProPlus byter namn till Microsoft 365-appar för företag. Mer information om den här ändringen finns i det här blogginlägget.

Sammanfattning

Användning av SupportMultipleDomain-bytet när du hanterar SSO till Office 365 med ADFS

När en SSO har aktiverats för O365 via ADFS bör du se RP-förtroende (Relying Party) som skapats för O365.

En skärmbild av AD FS, som visar RP-förtroende (Relying Party) som har skapats för O365

Kommandon som skapar RP-förtroende för O365 visas nedan:

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

Det RP-förtroende som skapades ovan kom med 2 kravregler

Get-MsolFederationProperty -DomainName på de federerade domänerna visar att "FederationServiceIdentifier" var samma för källan ADFS och O365, dvs. http://stsname/adfs/Services/trust

Tidigare före uppdateringarna för ADFS Rollup 1 och Rollup 2 måste Microsoft Office 365-kunder använda enkel inloggning (SSO) via AD FS 2.0 och har flera toppnivådomäner för användarnas huvudnamnssuffix (UPN) inom organisationen (till exempel eller ) för att distribuera en separat instans av @contoso.com AD @fabrikam.com FS 2.0-federationstjänsten för varje suffix. Nu finns en samlad uppdatering för AD FS 2.0 ( ) som fungerar tillsammans med bytet "SupportMultipleDomain" för att aktivera AD FS-servern för att stödja det här scenariot utan ytterligare https://support.microsoft.com/kb/2607496 AD FS 2.0-servrar.

Med ADFS-uppdatering 1-uppdateringen har vi lagt till följande funktioner:

Stöd för flera utfärdare

"Tidigare var Microsoft Office 365-kunder som kräver enkel inloggning (SSO) med AD FS 2.0 och använder flera toppnivådomäner för användarnas UPN-suffix inom organisationen (till exempel) för att distribuera en separat instans av @contoso.us @contoso.de AD FS 2.0-federationstjänsten för varje suffix. När du har installerat den här samlad uppdatering på alla AD FS 2.0-federationsservrar i servergruppen och följer instruktionerna för att använda den här funktionen med Office 365 ställs nya anspråksregler in för att dynamiskt generera tokenutfärdare-ID baserat på UPN-suffixen för Office 365-användarna. Därför behöver du inte konfigurera flera instanser av AD FS 2.0-federationsserver som stöder SSO för flera toppnivådomäner i Office 365."

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

"För närvarande är det Microsoft Office 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 inom organisationen (till exempel eller ) för att distribuera en separat instans av @contoso.com @fabrikam.com AD FS 2.0-federationstjänsten för varje suffix. Det finns nu en samlad uppdatering för AD FS 2.0 ( ) som fungerar tillsammans med bytet "SupportMultipleDomain" för att aktivera AD FS-servern för att stödja det här scenariot utan ytterligare https://support.microsoft.com/kb/2607496 AD FS 2.0-servrar."

Kommandon som skapar RP-förtroende för O365 visas nedan:

New-MsolFederatedDomain -DomainName<domain>-SupportMultiDomain

Update-MSOLFederatedDomain -DomainName <domain>-SupportMultipleDomain

Convert-MsolDomainToFederated -DomainName <domain>-supportMultipleDomain

Get-MsolFederationProperty -DomainName på de federerade domänerna visar nu att "FederationServiceIdentifier" är annorlunda för ADFS och O365. Alla federerade domäner har "FederationServiceIdentifier" som http:// <domainname> /adfs/services/trust/ medan ADFS-konfigurationen fortfarande har http://STSname/adfs/Services/trust

På grund av den här inmatchning i konfigurationen måste vi se till att när en token skickas till O365 som den utfärdare som nämns i den, är densamma som den som konfigurerats för domänen i O365. Om du inte får felmeddelandet nedan:

När du lägger till eller uppdaterar RP-förtroende med SupportMultipleDomain-bytet läggs en tredje anspråksregel automatiskt till i RP-förtroende för O365.

Standard den tredje regeln:

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 som kallas "Issuerid". http://contoso.com/adfs/services/trust/Exempel.

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

En skärmbild av fidder

Det är intressant att observera att regeln utfärdar "Issuerid"-anspråk. Vi ser inte det här anspråket i svarstoken, i själva verket ser vi attributet "Utfärdare" ändrat till det nyligen skapade 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 att ADFS-sammanslagningen 1 eller 2 är installerad. Du ser att svarstoken som genereras av ADFS har BÅDE Utfärdare=" " och anspråket "Issuerid" med det sammansatta värdet enligt den http://STSname/adfs/Services/trust 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

"Det är viktigt att observera att bytet"SupportMultipleDomain" inte krävs om du har en enda toppnivådomän och flera underdomäner. Om de domäner som används för upn-suffix är till exempel och den översta nivån (contoso.com i det här fallet) först har lagts till och sedan federerats behöver du inte använda växeln @sales.contoso.com @marketing.contoso.com @contoso.com "SupportMultipleDomain". Det beror på att de här underdomänerna hanteras effektivt inom den överordnade domänens område och att en enda AD FS-server kan användas för att hantera detta redan."

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

Varför fungerar inte bytet i scenariot ovan?

Svar:

  • När det gäller underordnad domän, som delar samma namnområde, kommer vi inte att federera dem separat. Den federerade rotdomänen täcker även barnets värde, vilket innebär att federationServiceIdentifier-värdet för den underordnade domänen också är detsamma som det för överordnade domäner, https://contoso.com/adfs/services/trust/ dvs.

  • Men den tredje anspråksregeln, som tar UPN-suffixet för användaren att skapa Utfärdare-värdet slutar med , vilket orsakar en felmatchning och därmed felet "Din organisation kunde inte logga in dig i den här https://Child1.contoso.com/adfs/services/trust/ tjänsten".

    För att lösa detta kan vi ändra den tredje regeln så att den genererar ett utfärdarevärde som matchar "FederationServiceIdentifier" för domänen i O365-slutet. 2 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ärdare-värdet. För upn-suffix child1.contoso.com genererar det fortfarande ett utfärdarevärde istället för https://contoso.com/adfs/services/trust/ https://Child1.contoso.com/adfs/services/trust/ (med standardregel)

En skärmbild av anspråksregeln

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!

Reglerna ovan 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 den domän som lagts till/federerats i O365.end.

Felmatchningen för federationServiceIdentifier mellan ADFS och O365 för en domän kan också korrigeras genom att ändra "federationServiceIdentifier" för domänen i O365 end så att den matchar "federationServiceIdentifier" för ADFS. Men federationServiceIdentifier kan bara konfigureras för ONE federerad domän och inte alla.

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

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