SupportMultipleDomain-bryter ved administrasjon av SSO til Office 365

Obs!

Office 365 ProPlus får nytt navn og heter nå Microsoft 365-apper for enterprise. Hvis du vil ha mer informasjon om denne endringen, kan du lese dette blogginnlegget.

Sammendrag

Bruk av SupportMultipleDomain-bryter når du administrerer SSO til Office 365 ved hjelp av ADFS

Når et SSO er aktivert for O365 via ADFS, skal du se at den beroende parts klareringen (RP) er opprettet for O365.

Et skjerm bilde av AD FS, som viser avhengig part (RP)-klarering opprettet for O365

Kommandoer som vil opprette en RP-klarering for O365, er nedenfor:

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

RP-klareringen som ble opprettet ovenfor, ble levert med to krav regler

Get-MsolFederationProperty-DomainName i de samlede domenene viser at "FederationServiceIdentifier" var det samme for kilde ADFS og O365, det vil sihttp://stsname/adfs/Services/trust

Tidligere før oppdateringene for ADFS samle oppdatering 1 og samle oppdatering 2 , Microsoft Office 365-kunder som bruker enkel pålogging (SSO) gjennom AD FS 2,0, og som har flere domener på øverste nivå for brukerens suffikser for brukerhovednavn (UPN) i organisasjonen (for eksempel @contoso.com eller @fabrikam.com ), kreves for å DISTRIBUERE en separat 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 sammen med "SupportMultipleDomain"-bryteren for å aktivere AD FS-serveren for å støtte dette scenariet uten å kreve ytterligere AD FS 2,0-servere.

Med oppdateringen for ADFS-Samleoppdatering 1 har vi lagt til følgende funksjonalitet:

Flere utsteder støtter

"Tidligere, Microsoft Office 365-kunder som krever enkel pålogging (SSO) ved hjelp av AD FS 2,0 og bruker flere domener på øverste nivå for brukernes UPN-suffikser (User Principal Name) i organisasjonen (for eksempel @contoso.us eller @contoso.de ), kreves for å distribuere en separat FOREKOMST av ad 2,0 FS, Federation service for hvert suffiks. Når du har installert denne samle oppdateringen på alle AD FS 2,0-Forbunds-serverne i farmen og følger instruksjonene for å bruke denne funksjonen med Office 365, blir nye krav regler satt til dynamisk generering av token-Issuer-ID-er basert på UPN-suffiksene til Office 365-brukerne. Resultatet er at du ikke trenger å konfigurere flere forekomster av AD FS 2,0 Federation server for å støtte SSO for flere domener på topp nivå i Office 365.

Støtte for flere domener på øverste nivå

"Microsoft Office 365-kunder som bruker enkel pålogging (SSO) via AD FS 2,0, og som har flere domener på øverste nivå for brukerens suffikser (UPN) i organisasjonen (for eksempel @contoso.com eller @fabrikam.com ), er nødvendige for å distribuere en separat FOREKOMST av ad 2,0 FS, Federation service for hvert suffiks.Det finnes nå en beregnet verdi for AD FS 2,0 ( https://support.microsoft.com/kb/2607496 ) som fungerer sammen med "SupportMultipleDomain"-bryteren for å aktivere AD FS-serveren for å støtte dette scenariet uten å kreve ytterligere AD FS 2,0-servere.»

Kommandoer som vil opprette en RP-klarering for O365, er nedenfor:

New-MsolFederatedDomain -DomainName<domain>-SupportMultiDomain

Update-MSOLFederatedDomain -DomainName <domain>-SupportMultipleDomain

Convert-MsolDomainToFederated -DomainName <domain>-supportMultipleDomain

Get-MsolFederationProperty-DomainName i de samlede domenene viser nå at «FederationServiceIdentifier» er forskjellig for ADFS og O365. Alle forbundede domener har «FederationServiceIdentifier» som http://- <domainname> /ADFS/Services/Trust/, mens ADFS-konfigurasjonen fremdeles harhttp://STSname/adfs/Services/trust

På grunn av denne uoverensstemmelsen i konfigurasjonen må vi sikre at når et token sendes til O365 som utstederen som ble nevnt i den, er det samme som er konfigurert for domenet i O365. Hvis ikke, får du feilen nedenfor:

Når du legger til eller oppdaterer RP-klarering med SupportMultipleDomain-bryter, legges det automatisk til en tredje krav regel i RP-klarering for O365.

Standard tredje regel:

c: [type = = " http://schemas.xmlsoap.org/claims/UPN](http://schemas.xmlsoap.org/claims/UPN "] => problem (type = " https://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid "; verdi = regexreplace (c. verdi;. +@(?<domain>.+ ) http://${domain}/adfs/services/trust/ ;));

Denne regelen bruker suffiks verdien til brukerens UPN og bruker det til å generere et nytt krav kalt «Issuerid». Eksempel http://contoso.com/adfs/services/trust/ .

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

Et skjerm bilde av Fidder

Det er interessant å være oppmerksom på at regel problemene «Issuerid», vi ser ikke dette kravet i Response-tokenet, og vi ser faktisk at attributtet Issuer er endret til den nylig satte 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">

EGENVEKSELREMITTERING

  • SupportMultipleDomain brukes uten å installere ADFS Rollup 1 eller 2. Du vil se at Response-tokenet som ble generert av ADFS, har både utsteder = " http://STSname/adfs/Services/trust " og kravet "Issuerid" med den satte verdien i henhold til den tredje krav regelen.

    <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 under domener

"Det er viktig å være klar over at «SupportMultipleDomain»-bryteren ikke er nødvendig når du har ett enkelt domene på øverste nivå og flere under domener.For eksempel hvis domenene som brukes for UPN-suffikser er @sales.contoso.com , @marketing.contoso.com og @contoso.com og det overordnede domenet (contoso.com i dette tilfellet) ble lagt til først og forbunden, trenger du ikke å bruke «SupportMultipleDomain»-bryteren.Dette skyldes at disse under domenene administreres effektivt innenfor omfanget av den overordnede og en enkelt AD FS-server kan brukes til å håndtere dette som allerede finnes.

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

Hvorfor fungerer ikke denne bryteren i scenarioet ovenfor?

Aksepterer

  • Hvis du vil dele det samme navne området i et underordnet domene, kan vi ikke sammensluttet dem separat. Det samlede rot domenet dekker det underordnede i tillegg til at federationServiceIdentifier-verdien for det underordnede domenet også vil være det samme som overordnet, https://contoso.com/adfs/services/trust/ dvs.

  • Men den tredje claim-regelen, som ender opp ved å velge UPN-suffikset for brukeren for å skrive utsteder verdien, avsluttes med https://Child1.contoso.com/adfs/services/trust/ , igjen for år saker en konflikt og feilen «organisasjonen din kunne ikke logge deg på denne tjenesten.»

    Vi kan løse dette ved å endre den tredje regelen, slik at den slutter å generere en utsteder verdi som Sams varer med «FederationServiceIdentifier» for domenet i O365-enden. 2 ulike regler som kan fungere i dette scenariet, er under. Denne regelen henter bare rot domenet fra UPN-suffikset for å opprette utsteder verdien. For et UPN-suffiks child1.contoso.com vil det fremdeles generere en utsteder verdi i https://contoso.com/adfs/services/trust/ stedet for https://Child1.contoso.com/adfs/services/trust/ (med standard regel)

Et skjerm bilde av krav regelen

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

EGENVEKSELREMITTERING

Reglene ovenfor gjelder kanskje ikke for alle scenarioer, men kan tilpasses for å sikre at verdien "Issuerid" Sams varer med "FederationServiceIdentifier" for domenet som er lagt til/forbund ved O365-enden.

Manglende samsvar mellom federationServiceIdentifier mellom ADFS og O365 for et domene, kan også rettes ved å endre "federationServiceIdentifier" for domenet i O365 end, for å samsvare med "federationServiceIdentifier" for ADFS. Men federationServiceIdentifier kan bare konfigureres for ett samlet domene, og ikke alle.

Set-MSOLDomainFederationSettings-Domain Name Contoso.com – issuerurihttp://STS.contoso.com/adfs/services/trust/

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