Konflikte

Konflikte lassen sich bei einem Verzeichnisabgleich natürlich immer mal schnell provozieren, wenn Sie auf beiden Seiten "Schreibrechte" haben und gegensätzliche Änderungen machen.

AD-Kontakt

Eher zufällig habe ich aber schon beim ersten Lauf ein Problemkonto, welches ADSync problemlos repliziert hat. Im Azure Portal habe ich zuerst den Fehler gesehen

Die Details dazu sagen leider nicht viel aus. Anscheinend hat mein Agent ein Objekte lokal gefunden, welches er nicht per HTTPS zur Gegenstelle in der Cloud übertragen kann.

Leider habe ich kein weiteres Protokoll auf dem ADSync Cloud Provisioning-Service gefunden, welches hier mehr Informationen der Verarbeitung bereit gestellt hat. Erst ein Blick in die Protokolle im Azure Portal verrät zumindest das betroffene Objekt:

Der Event ist vom 24.4.2020 07:10:35 und ein Retry wird erst wieder am 26.4.2020 05:10 UTC, also auch wieder 7:10 ausgeführt. Das ist schon mal eine Information, dass hier nicht alle 2 Sekunden wieder ein Versuch gestartet wird, sondern ganze 48 Stunden vergehen und ich habe keinen "Jetzt replizieren" Button gefunden. Eine Änderung des Quell-Objekts hat AzureAD Cloud Sync auch nicht dazu gebracht, noch mal einen Abgleich zu starten.

AzureAD Cloud Provisioning kann also einen lokalen AD-Kontakte nicht im AzureAD anlegen. Auch auf den anderen Reitern gibt es keine Information, welches Feld das Problem ist. Über die Schritte kann ich zumindest sehen, was ADSync Cloud Provisioning gerne getan hätte:

Auch die geänderten Eigenschaften zeigen nur die maßgeblichen Felder aber keinen Hinweise, ob ihm da ein Feld nicht gefällt.

Das lokale AD-Objekte hatte eigentlich keine besonderen Einträge:

dn: CN=ADContact1,OU=Firma,DC=carius,DC=de
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: contact
cn: ADContact1
sn: ADContact1 Last
givenName: ADContact1
distinguishedName: CN=ADContact1,OU=Firma,DC=carius,DC=de
instanceType: 4
whenCreated: 20180127114145.0Z
whenChanged: 20180127114145.0Z
displayName: ADContact1
uSNCreated: 13171
uSNChanged: 13171
name: ADContact1
objectGUID:: pP0Yt5D14kWn+cLjAUz9jA==
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=carius,DC=de
dSCorePropagationData: 16010101000000.0Z

Vielleicht stört sich ADSync daran, dass der Kontakt keine Mailadresse hat. Im in der AzureAD-Verwaltung können Sie Kontakte gar nicht sehen und in der Exchange Konsole ist er auch nicht aufgetaucht. Ich habe dem Benutzer als einfach eine Mailadresse gegeben:

Beim nächsten Abgleich war der Kontakt dann auch im AzureAD.

Als "Key" nutzt AzureAd Cloud Provisioning hier wohl der GUID, da ein Kontakt naturgemäß keinen UPN hat.

PS C:\> Get-ADObject -Identity "CN=ADContact1,OU=Firma,DC=carius,DC=de"

DistinguishedName                      Name       ObjectClass ObjectGUID
-----------------                      ----       ----------- ----------
CN=ADContact1,OU=Firma,DC=carius,DC=de ADContact1 contact     b718fda4-f590-45e2-a7f9-c2e3014cfd8c

In Exchange ist der Kontakt dann auch sichtbar:

Soweit funktioniert AzureAD Cloud Provisioning mit Exchange.

Neue Benutzer

Zum Thema "Matching" habe ich auf der Seite Einrichtung schon einiges geschrieben. Solange das Kontaktobjekt "ADContact1" einen Fehler wirft, habe ich einen weiteren Benutzer "OnPremises" angelegt, um zu sehen, ob ADSync dennoch weiter macht. Hier die Stammdaten eines normalen Active Directory Benutzers:

dn: CN=ADUser3,OU=Firma,DC=carius,DC=de
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: ADUser3
sn: ADUser3
distinguishedName: CN=ADUser3,OU=Firma,DC=carius,DC=de
instanceType: 4
whenCreated: 20200425210833.0Z
whenChanged: 20200425210833.0Z
displayName: ADUser3
uSNCreated: 1250134
uSNChanged: 1250140
name: ADUser3
objectGUID:: 8iWDbTRnV0+xVuIveyqxbA==
userAccountControl: 512
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 0
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAwM8SUMELJU0m/cWzawQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: aduser3
sAMAccountType: 805306368
userPrincipalName: aduser3@msxfaq.net
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=carius,DC=de
dSCorePropagationData: 16010101000000.0Z

Der User wurde 23:08 angelegt und wurde 23:09 angelegt

Das ist schnell gewesen. Allerdings kann ich mir nicht erklären, wo die fremden Domainnamen herkommen. ich schiebe das einmal auf die Preview und hoffe, dass dies zukünftig passt.

Irritierend finde ich aber, dass der Agent im lokalen Active Directory das Objekte nicht geändert hat. Ich habe extra per LDIFDE.EXE ein Export nach dem Abgleich gemacht und es wurde nichts geändert.

Insbesondere das Feld "mS-DS-ConsistencyGuid" ist leer geblieben.

Sie haben damit im lokale Active Directory keinen Hinweis, dass dieses Objekte in die Cloud repliziert wird. Ich frage mich dann natürlich auch. wie ADSync Cloud Provisioning mit Umbenennungen umgeht

Rename

Daher war ja klar, dass ich alles an dem Benutzer "ADUser3" ändere, was möglich ist und dann den Status des Abgleichs wieder erreiche. Alle bisherigen Einträge haben ja die Vermutung aufkommen lassen, dass der UPN der Schlüssel ist. Daher war die Änderung des UPN natürlich interessant. Die Protokolle lassen dann erst einmal Schlimmes erahnen:

Es sieht so aus, als ob ein neuer Benutzer angelegt wurde. Im AzureAD gab es aber den vorherigen User4 auch nicht. Er wurde aber tatsächlich umbenannt und das erkennen Sie auch hier im Protokoll, wenn Sie die GUID der Quell-ID und Ziel-ID anschauen. Diese sind nämlich gleich. Da aber auch hier AzureAD Cloud Provisioning keinen Eintrag im lokalen AD-Objekt zurückschreibt, halte ich fest:

AzureAD Cloud Provisioning bedient sich der ObjectGUID, um lokale Konten und AzureAD-Objekte zusammen zu halten. Das hat natürlich Auswirkungen auf spätere Migrationen. Siehe auch SourceAnchor, ImmutableId und ADMT

Wer mit AzureAD Cloud Provisioning arbeitet, muss dann wohl erst das Konto in der Quelle entfernen, damit die Identität in Azure als "Gelöschtes Objekt" erscheint und dann nach der Neuanlage/Migration in einen anderen Forest wieder zurückgeholt wird.

Cloud-Objekte

Ich habe dann in Exchange auch zwei Objekte angelegt, die bisher mit ADSync ignoriert wurden.

Hier hat mich interessiert. Ob die Objekte vielleicht irgendwann mal auch OnPremises auftauchen. Allerdings erwarte ich dies heute noch nicht, da die Konfiguration dazu viel zu wenig Einstellmöglichkeiten bietet, z.B.: in welcher OU die Objekte angelegt werden sollen.

Weitere Links