SupportMultipleDomain-bryter når du administrerer SSO til Microsoft 365

• Gjelder for:

  Microsoft 365

Sammendrag

Bruk av SupportMultipleDomain-bryteren når du administrerer SSO til Microsoft 365 ved hjelp av AD FS

Når en SSO er aktivert for Microsoft 365 via AD FS, skal du kunne se klareringen fra Beroende part (RP) opprettet for Microsoft 365.

Kommandoer som vil opprette RP-klarering for Microsoft 365

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

Obs!

Azure AD- og MSOnline PowerShell-moduler avvikles fra og med 30. mars 2024. Hvis du vil ha mer informasjon, kan du lese avskrivingsoppdateringen. Etter denne datoen er støtte for disse modulene begrenset til overføringshjelp til Microsoft Graph PowerShell SDK og sikkerhetsoppdateringer. De avskrevne modulene vil fortsette å fungere til og med 30. mars 2025.

Vi anbefaler at du overfører til Microsoft Graph PowerShell for å samhandle med Microsoft Entra ID (tidligere Azure AD). Se vanlige spørsmål om overføring for vanlige spørsmål om overføring. Merk: Versjoner 1.0.x av MSOnline kan oppleve forstyrrelser etter 30. juni 2024.

RP-klarerte kom med to kravregler

Get-MsolFederationProperty -DomainName <domain> på de samlede domenene viser at "FederationServiceIdentifier" var den samme for kilde AD FS og Microsoft 365, som er http://stsname/adfs/Services/trust.

Tidligere før AD FS Rollup 1 - og Rollup 2-oppdateringene , har Microsoft 365-kunder som bruker SSO gjennom AD FS 2.0 og har flere toppnivådomener for brukernes UPN-suffikser i organisasjonen (for eksempel, @contoso.com eller @fabrikam.com) som kreves for å distribuere en egen forekomst av AD FS 2.0 Federation Service for hvert suffiks. Det finnes nå en beregnet verdi for AD FS 2.0 (https://support.microsoft.com/kb/2607496) som fungerer med «SupportMultipleDomain»-bryteren for å aktivere AD FS-serveren for å støtte dette scenariet uten å kreve flere AD FS 2.0-servere.

Med AD FS-oppdateringen for beregnet verdi 1 har vi lagt til følgende funksjonalitet

Støtter flere utstedere

Tidligere har Microsoft 365-kunder som krever SSO, brukt AD FS 2.0 og bruker flere toppdomener for brukernes UPN-suffikser i organisasjonen (for eksempel, @contoso.us eller @contoso.de) som kreves for å distribuere en egen forekomst av AD FS 2.0 Federation Service for hvert suffiks. Når du har installert denne samleoppdateringen på alle AD FS 2.0-forbundsserverne i farmen og følger instruksjonene for å bruke denne funksjonen med Microsoft 365, angis nye kravregler for dynamisk generering av tokenutsteder-ID-er basert på UPN-suffiksene til Microsoft 365-brukerne. Derfor trenger du ikke å konfigurere flere forekomster av AD FS 2.0-forbundsserveren for å støtte enkel pålogging for flere domener på øverste nivå i Microsoft 365.

Støtte for flere Top-Level domener

«For øyeblikket har Microsoft 365-kunder som bruker enkel pålogging (SSO) gjennom AD FS 2.0 og har flere domener på øverste nivå for brukernes brukerhovednavn (UPN)-suffikser i organisasjonen (for eksempel, @contoso.com eller @fabrikam.com) som kreves for å distribuere en egen forekomst av AD FS 2.0 Federation Service for hvert suffiks. Det finnes nå en beregnet verdi for AD FS 2.0 (https://support.microsoft.com/kb/2607496) som fungerer med «SupportMultipleDomain»-bryteren for å aktivere AD FS-serveren til å støtte dette scenariet uten å kreve flere AD FS 2.0-servere.»

Kommandoer som vil opprette RP-klarering for Microsoft 365

New-MsolFederatedDomain -DomainName<domain>-SupportMultiDomain

Update-MSOLFederatedDomain -DomainName <domain>-SupportMultipleDomain

Convert-MsolDomainToFederated -DomainName <domain>-supportMultipleDomain

Get-MsolFederationProperty -DomainName <domain> på de samlede domenene viser nå at "FederationServiceIdentifier" er forskjellig for AD FS og Microsoft 365. Hvert forbundsdomene har FederationServiceIdentifier som http://<domainname>/adfs/services/trust/, mens AD FS-konfigurasjonen fremdeles har http://STSname/adfs/Services/trust.

På grunn av denne manglende konfigurasjonen må vi sørge for at når et token sendes til Microsoft 365, er utstederen som er nevnt i den, den samme som den som er konfigurert for domenet i Microsoft 365. Ellers får du feilen.

Så når du legger til eller oppdaterer RP-klarering med SupportMultipleDomain-bryteren, legges en tredje kravregel automatisk til i RP-klarering for Microsoft 365.

Standard tredje regel:

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

Denne regelen bruker suffiksverdien for brukerens UPN og bruker den til å generere et nytt krav kalt «Issuerid». For eksempel http://contoso.com/adfs/services/trust/.

Ved hjelp av fiddler kan vi spore tokenet som sendes til login.microsoftonline.com/login.srf. Når du har kopiert tokenet som ble sendt inn wresult, limer du inn innholdet i notisblokken og lagrer filen som .xml. Senere kan du åpne tokenet som er lagret som .xml fil ved hjelp av IE, og se innholdet.

Det er interessant å være oppmerksom på at regelen utsteder "Issuerid"-krav, vi ser ikke denne påstanden i svartokenet, faktisk ser vi at «Utsteder»-attributtet er endret til den nylig sammensatte verdien.

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

MERK

• SupportMultipleDomain brukes uten at AD FS rollup 1 eller 2 er installert. Du ser at svartokenet som genereres av AD FS, har BÅDE Utsteder="http://STSname/adfs/Services/trust og kravet «Utstedtid» med den sammensatte verdien i henhold til den tredje kravregelen.

  <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øtte for underdomener

Det er viktig å være oppmerksom på at «SupportMultipleDomain»-bryteren ikke er nødvendig når du har ett enkelt domene på øverste nivå og flere underdomener. Hvis for eksempel domenene som brukes for UPN-suffikser er @sales.contoso.com, @marketing.contoso.comog @contoso.com, og toppdomenet (contoso.com i dette tilfellet) ble lagt til først og i forbund, trenger du ikke å bruke «SupportMultipleDomain»-bryteren. Disse underdomenene administreres effektivt innenfor området til den overordnede, og én enkelt AD FS-server kan brukes til å håndtere dette scenarioet.

Hvis du imidlertid har flere domener på øverste nivå (@contoso.com og @fabrikam.com), og disse domenene også har underdomener (@sales.contoso.com og @sales.fabrikam.com), vil ikke «SupportMultipleDomain»-bryteren fungere for underdomenene, og disse brukerne vil ikke kunne logge på.

Hvorfor fungerer ikke denne bryteren i scenarioet ovenfor?

Svar:

• Når det gjelder underordnet domene, deler vi det samme navneområdet, vi gir dem ikke mat separat. Det samlede rotdomenet dekker også underordnet, noe som betyr at federationServiceIdentifier-verdien for det underordnede domenet også vil være den samme som overordnet, det vil si https://contoso.com/adfs/services/trust/.

• Men den tredje kravregelen, som ender opp med å plukke UPN-suffikset for brukeren til å skrive utstederverdien, ender opp med https://Child1.contoso.com/adfs/services/trust/, igjen forårsaker en mismatch og dermed feilen "Organisasjonen kan ikke logge deg på denne tjenesten."

  Du kan løse dette problemet ved å endre den tredje regelen slik at den ender opp med å generere en utstederverdi som samsvarer med FederationServiceIdentifier for domenet ved slutten av Microsoft 365. Nedenfor finner du to forskjellige regler som kan fungere i dette scenarioet. Denne regelen henter bare rotdomenet fra UPN-suffikset for å skrive utstederverdien. For et UPN-suffiks child1.contoso.com vil det likevel generere en utstederverdi https://contoso.com/adfs/services/trust/ i stedet https://Child1.contoso.com/adfs/services/trust/ for (med standardregel)

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

MERK

Disse reglene gjelder kanskje ikke for alle scenarioer, men kan tilpasses for å sikre at Issuerid-verdien samsvarer med FederationServiceIdentifier for domenet som er lagt til/samlet på Microsoft 365-slutten.

Samsvaret mellom federationServiceIdentifier mellom AD FS og Microsoft 365 for et domene kan også korrigeres ved å endre federationServiceIdentifier for domenet ved slutten av Microsoft 365 for å samsvare med "federationServiceIdentifier" for AD FS. FederationServiceIdentifier kan imidlertid bare konfigureres for ett forbundsdomene og ikke alle.

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

Mer informasjon som skal hjelpe deg med å skrive dine egne kravregler.**

• Rollen til språket for kravregel
• Vanlige uttrykk