- Artikkel
Formålet med dette dokumentet er å beskrive områder som må vurderes når du konfigurerer Azure AD Connect. Dette dokumentet er et dypdykk på enkelte områder og disse konseptene er kort beskrevet i andre dokumenter også.
kildeanker
sourceAnchor-attributtet er definert somen egenskap som er uforanderlig i løpet av et objekts levetid. Den identifiserer unikt et objekt som det samme objektet lokalt og i Azure AD. Attributten kalles ogsåuforanderlig IDog de to navnene brukes om hverandre.
Ordet uforanderlig, det vil si "kan ikke endres", er viktig for dette dokumentet. Siden dette attributtets verdi ikke kan endres etter at det er angitt, er det viktig å velge et design som støtter scenarioet ditt.
Attributtet brukes for følgende scenarier:
- Når en ny synkroniseringsmotorserver bygges, eller gjenoppbygges etter et katastrofegjenopprettingsscenario, kobler dette attributtet eksisterende objekter i Azure AD med objekter på stedet.
- Hvis du flytter fra en skybasert identitet til en synkronisert identitetsmodell, lar dette attributtet objekter "hard matche" eksisterende objekter i Azure AD med lokale objekter.
- Hvis du bruker føderasjon, vil dette attributtet sammen meduserPrincipalNamebrukes i kravet for å identifisere en bruker unikt.
Dette emnet snakker bare om sourceAnchor når det gjelder brukere. De samme reglene gjelder for alle objekttyper, men det er bare for brukere dette problemet vanligvis er et problem.
Velge et godt sourceAnchor-attributt
Attributtverdien må følge følgende regler:
- Færre enn 60 tegn
- Tegn som ikke er a-z, A-Z eller 0-9 er kodet og telles som 3 tegn
- Ikke inneholde et spesialtegn: \ ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ' ; : , [ ] " @ _
- Må være globalt unik
- Må enten være en streng, heltall eller binær
- Bør ikke være basert på brukernavn fordi disse kan endres
- Bør ikke skille mellom store og små bokstaver og unngå verdier som kan variere fra tilfelle til tilfelle
- Bør tildeles når objektet er opprettet
Hvis det valgte sourceAnchor ikke er av typen streng, så Azure AD Connect Base64Encode attributtverdien for å sikre at ingen spesialtegn vises. Hvis du bruker en annen føderasjonsserver enn ADFS, sørg for at serveren din også kan Base64Encode attributtet.
sourceAnchor-attributtet skiller mellom store og små bokstaver. En verdi av "JohnDoe" er ikke det samme som "JohnDoe". Men du bør ikke ha to forskjellige objekter med bare en forskjell i kasus.
Hvis du har en enkelt skog på stedet, er attributtet du bør brukeobjektGUID. Dette er også attributtet som brukes når du bruker ekspressinnstillinger i Azure AD Connect og også attributtet som brukes av DirSync.
Hvis du har flere skoger og ikke flytter brukere mellom skoger og domener, daobjektGUIDer en god egenskap å bruke selv i dette tilfellet.
Hvis du flytter brukere mellom skoger og domener, må du finne et attributt som ikke endres eller som kan flyttes med brukerne under flyttingen. En anbefalt tilnærming er å introdusere en syntetisk egenskap. Et attributt som kan inneholde noe som ser ut som en GUID ville være passende. Under opprettelsen av objektet opprettes en ny GUID og stemples på brukeren. En egendefinert synkroniseringsregel kan opprettes i synkroniseringsmotorserveren for å opprette denne verdien basert påobjektGUIDog oppdater det valgte attributtet i AD DS. Når du flytter objektet, sørg for å også kopiere innholdet til denne verdien.
En annen løsning er å velge et eksisterende attributt du vet ikke endres. Vanlige brukte attributter inkludererAnsatt ID. Hvis du vurderer et attributt som inneholder bokstaver, sørg for at det ikke er noen sjanse for at store og små bokstaver kan endres for attributtverdien. Dårlige attributter som ikke skal brukes inkluderer disse attributtene med navnet på brukeren. I et ekteskap eller en skilsmisse forventes navnet å endres, noe som ikke er tillatt for denne egenskapen. Dette er også en grunn til at attributter som f.eksuserPrincipalName,post, ogmåladresseer ikke engang mulig å velge i installasjonsveiviseren for Azure AD Connect. Disse attributtene inneholder også tegnet "@", som ikke er tillatt i kildeankeret.
Endre sourceAnchor-attributtet
sourceAnchor-attributtverdien kan ikke endres etter at objektet er opprettet i Azure AD og identiteten er synkronisert.
Av denne grunn gjelder følgende restriksjoner for Azure AD Connect:
- sourceAnchor-attributtet kan bare angis under den første installasjonen. Hvis du kjører installasjonsveiviseren på nytt, er dette alternativet skrivebeskyttet. Hvis du trenger å endre denne innstillingen, må du avinstallere og installere på nytt.
- Hvis du installerer en annen Azure AD Connect-server, må du velge det samme sourceAnchor-attributtet som tidligere ble brukt. Hvis du tidligere har brukt DirSync og flyttet til Azure AD Connect, må du brukeobjektGUIDsiden det er attributtet som brukes av DirSync.
- Hvis verdien for sourceAnchor endres etter at objektet har blitt eksportert til Azure AD, gir Azure AD Connect sync en feil og tillater ikke flere endringer på det objektet før problemet er løst og sourceAnchor endres tilbake i kildekatalog.
Bruker ms-DS-ConsistencyGuid som sourceAnchor
Som standard bruker Azure AD Connect (versjon 1.1.486.0 og eldre) objectGUID som sourceAnchor-attributtet. ObjectGUID er systemgenerert. Du kan ikke spesifisere verdien når du oppretter lokale AD-objekter. Som forklart i avsnittkildeanker, er det scenarier der du må spesifisere sourceAnchor-verdien. Hvis scenariene er aktuelle for deg, må du bruke et konfigurerbart AD-attributt (for eksempel ms-DS-ConsistencyGuid) som sourceAnchor-attributtet.
Azure AD Connect (versjon 1.1.524.0 og nyere) forenkler nå bruken av ms-DS-ConsistencyGuid som sourceAnchor-attributt. Når du bruker denne funksjonen, konfigurerer Azure AD Connect automatisk synkroniseringsreglene til å:
Bruk ms-DS-ConsistencyGuid som sourceAnchor-attributtet for brukerobjekter. ObjectGUID brukes for andre objekttyper.
For et gitt lokalt AD-brukerobjekt hvis ms-DS-ConsistencyGuid-attributt ikke er fylt ut, skriver Azure AD Connect sin objectGUID-verdi tilbake til ms-DS-ConsistencyGuid-attributtet i lokale Active Directory. Etter at ms-DS-ConsistencyGuid-attributtet er fylt ut, eksporterer Azure AD Connect objektet til Azure AD.
Merk
Når et lokalt AD-objekt er importert til Azure AD Connect (det vil si importert til AD Connector Space og projisert inn i Metaverse), kan du ikke endre sourceAnchor-verdien lenger. For å spesifisere sourceAnchor-verdien for et gitt lokalt AD-objekt, konfigurer dets ms-DS-ConsistencyGuid-attributt før det importeres til Azure AD Connect.
Tillatelse kreves
For at denne funksjonen skal fungere, må AD DS-kontoen som brukes til å synkronisere med lokal Active Directory gis skrivetillatelse til ms-DS-ConsistencyGuid-attributtet i lokal Active Directory.
Slik aktiverer du ConsistencyGuid-funksjonen - Ny installasjon
Du kan aktivere bruk av ConsistencyGuid som sourceAnchor under ny installasjon. Denne delen dekker både Express- og Custom-installasjon i detaljer.
Merk
Bare nyere versjoner av Azure AD Connect (1.1.524.0 og senere) støtter bruken av ConsistencyGuid som sourceAnchor under ny installasjon.
Slik aktiverer du ConsistencyGuid-funksjonen
Ekspressinstallasjon
Når du installerer Azure AD Connect med Express-modus, bestemmer Azure AD Connect-veiviseren automatisk det mest passende AD-attributtet som skal brukes som sourceAnchor-attributtet ved hjelp av følgende logikk:
Først spør Azure AD Connect-veiviseren din Azure AD-leietaker for å hente AD-attributtet som ble brukt som sourceAnchor-attributtet i den forrige Azure AD Connect-installasjonen (hvis noen). Hvis denne informasjonen er tilgjengelig, bruker Azure AD Connect det samme AD-attributtet.
Merk
Bare nyere versjoner av Azure AD Connect (1.1.524.0 og senere) lagrer informasjon i Azure AD-leietakeren om sourceAnchor-attributtet som ble brukt under installasjonen. Eldre versjoner av Azure AD Connect gjør det ikke.
Hvis informasjon om sourceAnchor-attributtet som brukes ikke er tilgjengelig, sjekker veiviseren tilstanden til ms-DS-ConsistencyGuid-attributtet i din lokale Active Directory. Hvis attributtet ikke er konfigurert på noe objekt i katalogen, bruker veiviseren ms-DS-ConsistencyGuid som sourceAnchor-attributtet. Hvis attributtet er konfigurert på ett eller flere objekter i katalogen, konkluderer veiviseren at attributtet brukes av andre applikasjoner og ikke er egnet som kildeankerattributt...
I så fall faller veiviseren tilbake til å bruke objectGUID som sourceAnchor-attributtet.
Når sourceAnchor-attributtet er bestemt, lagrer veiviseren informasjonen i Azure AD-leieren. Informasjonen vil bli brukt ved fremtidig installasjon av Azure AD Connect.
Når Express-installasjonen er fullført, informerer veiviseren deg om hvilket attributt som er valgt som kildeankerattributt.
Tilpasset installasjon
Når du installerer Azure AD Connect med tilpasset modus, gir Azure AD Connect-veiviseren to alternativer når du konfigurerer sourceAnchor-attributt:
Innstilling | Beskrivelse |
---|---|
La Azure administrere kildeankeret for meg | Velg dette alternativet hvis du vil at Azure AD skal velge attributtet for deg. Hvis du velger dette alternativet, bruker Azure AD Connect-veiviseren det sammelogikk for valg av sourceAnchor-attributt brukt under ekspressinstallasjon. I likhet med ekspressinstallasjon informerer veiviseren deg om hvilket attributt som er valgt som kildeankerattributtet etter at den tilpassede installasjonen er fullført. |
En bestemt egenskap | Velg dette alternativet hvis du ønsker å spesifisere et eksisterende AD-attributt som sourceAnchor-attributtet. |
Slik aktiverer du ConsistencyGuid-funksjonen - Eksisterende distribusjon
Hvis du har en eksisterende Azure AD Connect-distribusjon som bruker objectGUID som Source Anchor-attributtet, kan du bytte den til å bruke ConsistencyGuid i stedet.
Merk
Bare nyere versjoner av Azure AD Connect (1.1.552.0 og senere) støtter bytte fra ObjectGuid til ConsistencyGuid som Source Anchor-attributtet.
Slik bytter du fra objectGUID til ConsistencyGuid som kildeankerattributtet:
Start Azure AD Connect-veiviseren og klikkKonfigurerfor å gå til Oppgaver-skjermen.
VelgKonfigurer kildeankeroppgavealternativet og klikkNeste.
Skriv inn Azure AD-administratorlegitimasjonen din og klikkNeste.
Azure AD Connect-veiviseren analyserer tilstanden til ms-DS-ConsistencyGuid-attributtet i din lokale Active Directory. Hvis attributtet ikke er konfigurert på noe objekt i katalogen, konkluderer Azure AD Connect med at ingen andre applikasjoner bruker attributtet for øyeblikket, og at det er trygt å bruke det som kildeankerattributtet. KlikkNesteå fortsette.
IKlar til å konfigurereskjerm, klikkKonfigurerfor å endre konfigurasjonen.
Når konfigurasjonen er fullført, indikerer veiviseren at ms-DS-ConsistencyGuid nå brukes som kildeankerattributtet.
Under analysen (trinn 4), hvis attributtet er konfigurert på ett eller flere objekter i katalogen, konkluderer veiviseren at attributtet brukes av et annet program og returnerer en feil som illustrert i diagrammet nedenfor. Denne feilen kan også oppstå hvis du tidligere har aktivert ConsistencyGuid-funksjonen på den primære Azure AD Connect-serveren, og du prøver å gjøre det samme på oppsamlingsserveren.
Hvis du er sikker på at attributtet ikke brukes av andre eksisterende programmer, kan du undertrykke feilen ved å starte Azure AD Connect-veiviseren på nytt med/SkipLdapSearchbryter spesifisert. For å gjøre det, kjør følgende kommando i ledeteksten:
"c:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe" /SkipLdapSearch
Innvirkning på AD FS eller tredjeparts føderasjonskonfigurasjon
Hvis du bruker Azure AD Connect til å administrere lokal AD FS-distribusjon, oppdaterer Azure AD Connect automatisk kravreglene for å bruke det samme AD-attributtet som sourceAnchor. Dette sikrer at ImmutableID-kravet generert av ADFS er konsistent med sourceAnchor-verdiene som eksporteres til Azure AD.
Hvis du administrerer AD FS utenfor Azure AD Connect eller du bruker tredjeparts føderasjonsservere for autentisering, må du manuelt oppdatere kravreglene for ImmutableID-krav for å være konsistente med sourceAnchor-verdiene eksportert til Azure AD som beskrevet i artikkelen seksjonEndre AD FS-kravsregler. Veiviseren returnerer følgende advarsel etter at installasjonen er fullført:
Legger til nye kataloger til eksisterende distribusjon
Anta at du har distribuert Azure AD Connect med ConsistencyGuid-funksjonen aktivert, og nå vil du legge til en annen katalog til distribusjonen. Når du prøver å legge til katalogen, sjekker Azure AD Connect-veiviseren statusen til ms-DS-ConsistencyGuid-attributtet i katalogen. Hvis attributtet er konfigurert på ett eller flere objekter i katalogen, konkluderer veiviseren at attributtet brukes av andre applikasjoner og returnerer en feil som illustrert i diagrammet nedenfor. Hvis du er sikker på at attributtet ikke brukes av eksisterende programmer, kan du undertrykke feilen ved å starte Azure AD Connect-veiviseren på nytt med/SkipLdapSearchbryteren spesifisert som beskrevet ovenfor, eller du må kontakte kundestøtte for mer informasjon.
Azure AD-pålogging
Mens du integrerer den lokale katalogen din med Azure AD, er det viktig å forstå hvordan synkroniseringsinnstillingene kan påvirke måten brukeren autentiserer på. Azure AD bruker userPrincipalName (UPN) for å autentisere brukeren. Men når du synkroniserer brukerne dine, må du velge attributtet som skal brukes for verdien av userPrincipalName nøye.
Velge attributtet for userPrincipalName
Når du velger attributtet for å angi verdien av UPN som skal brukes i Azure, bør du sørge for
- Attributtverdiene samsvarer med UPN-syntaksen (RFC 822), den skal være i formatet brukernavn@domene
- Suffikset i verdiene samsvarer med et av de bekreftede egendefinerte domenene i Azure AD
I ekspressinnstillinger er det antatte valget for attributtet userPrincipalName. Hvis userPrincipalName-attributtet ikke inneholder verdien du vil at brukerne skal logge på Azure, må du velgeTilpasset installasjon.
Merk
Det anbefales som en beste praksis at UPN-prefikset inneholder mer enn ett tegn.
Egendefinert domenestatus og UPN
Det er viktig å sikre at det er et verifisert domene for UPN-suffikset.
John er bruker i contoso.com. Du vil at John skal bruke den lokale UPN-en john@contoso.com for å logge på Azure etter at du har synkronisert brukere til Azure AD-katalogen din contoso.onmicrosoft.com. For å gjøre det, må du legge til og bekrefte contoso.com som et tilpasset domene i Azure AD før du kan begynne å synkronisere brukerne. Hvis UPN-suffikset til John, for eksempel contoso.com, ikke samsvarer med et verifisert domene i Azure AD, erstatter Azure AD UPN-suffikset med contoso.onmicrosoft.com.
Ikke-ruterbare lokale domener og UPN for Azure AD
Noen organisasjoner har ikke-ruterbare domener, som contoso.local, eller enkle domener med enkelt etikett som contoso. Du kan ikke bekrefte et ikke-ruterbart domene i Azure AD. Azure AD Connect kan synkroniseres til bare et verifisert domene i Azure AD. Når du oppretter en Azure AD-katalog, oppretter den et ruterbart domene som blir standarddomene for din Azure AD, for eksempel contoso.onmicrosoft.com. Derfor blir det nødvendig å verifisere et hvilket som helst annet ruterbart domene i et slikt scenario i tilfelle du ikke ønsker å synkronisere til standard onmicrosoft.com-domenet.
LeseLegg til det egendefinerte domenenavnet ditt i Azure Active Directoryfor mer informasjon om å legge til og bekrefte domener.
Azure AD Connect oppdager om du kjører i et ikke-ruterbart domenemiljø og advarer deg mot å gå videre med ekspressinnstillinger. Hvis du opererer i et ikke-ruterbart domene, er det sannsynlig at UPN-en til brukerne også har ikke-ruterbare suffikser. Hvis du for eksempel kjører under contoso.local, foreslår Azure AD Connect at du bruker egendefinerte innstillinger i stedet for ekspressinnstillinger. Ved å bruke egendefinerte innstillinger kan du spesifisere attributtet som skal brukes som UPN for å logge på Azure etter at brukerne er synkronisert til Azure AD.
Neste skritt
Lære mer omIntegrering av lokale identiteter med Azure Active Directory.