SourceAnchor Computer
Auch Computer können mit ADSync zwischen dem lokalen Active Directory und AzureAD abgeglichen werden. Für ein Management per Intune und Conditional Access ist dies wichtig. Auf der Seite ADSync mit Devices habe ich einige Details schon beschrieben. Diese Seite konzentriert sich auf das Mapping.
Computerkonto anlegen
Wenn Sie einen Windows 10 Computer schon ins AzureAD aufgenommen haben, dann können Sie ihn nicht mehr einfach in das lokale AD aufnehmen. Die Reihenfolge ist klar: Erst Aufnahme in das lokale Active Directory und dann die Registrierung im Azure AD. Siehe dazu auch Device Registration. Ich habe also einen Computer in die Domäne aufgenommen und das AD-Objekt betrachtet: (verkürzt)
PS C:\> Get-ADComputer pc-fc-win10 -Properties *
accountExpires : 9223372036854775807
AccountNotDelegated : False
AllowReversiblePasswordEncryption : False
CannotChangePassword : False
CanonicalName : msxfaq.de/Clients/unbekannt/PC-FC-WIN10
Certificates : {System.Security.Cryptography.X509Certificates.X509Certificate}
CN : PC-FC-WIN10
CompoundIdentitySupported : {False}
countryCode : 0
Created : 01.03.2021 14:00:37
createTimeStamp : 01.03.2021 14:00:37
DistinguishedName : CN=PC-FC-WIN10,OU=unbekannt,OU=Clients,DC=msxfaq,DC=de
DNSHostName : PC-FC-WIN10.msxfaq.de
Enabled : True
instanceType : 4
isCriticalSystemObject : False
KerberosEncryptionType : {RC4, AES128, AES256}
lastLogon : 132590772664232799
LastLogonDate : 01.03.2021 14:00:39
lastLogonTimestamp : 132590772399937463
localPolicyFlags : 0
LockedOut : False
logonCount : 2
MemberOf : {}
MNSLogonAccount : False
Modified : 01.03.2021 14:04:19
modifyTimeStamp : 01.03.2021 14:04:19
msDS-SupportedEncryptionTypes : 28
msDS-User-Account-Control-Computed : 0
Name : PC-FC-WIN10
ObjectCategory : CN=Computer,CN=Schema,CN=Configuration,DC=msxfaq,DC=de
ObjectClass : computer
ObjectGUID : cf280414-d476-47f1-a7ab-xxxxxxxxxxx
objectSid : S-1-5-21-11949449-30417519-xxxx-xxxx
OperatingSystem : Windows 10 Enterprise
OperatingSystemVersion : 10.0 (19042)
PasswordExpired : False
PasswordLastSet : 01.03.2021 14:00:37
PasswordNeverExpires : False
PasswordNotRequired : False
PrimaryGroup : CN=Domänencomputer,CN=Users,DC=msxfaq,DC=de
primaryGroupID : 515
pwdLastSet : 132590772377966973
SamAccountName : PC-FC-WIN10$
sAMAccountType : 805306369
servicePrincipalName : {TERMSRV/PC-FC-WIN10,
TERMSRV/PC-FC-WIN10.msxfaq.de,
RestrictedKrbHost/PC-FC-WIN10,
HOST/PC-FC-WIN10...}
ServicePrincipalNames : {TERMSRV/PC-FC-WIN10,...}
SID : S-1-5-21-11949449-xxxxxx-xxxxxxx-xxxxxx
SIDHistory : {}
userAccountControl : 4096
userCertificate : {48 130 2 232 48 130 1....30 110}
UserPrincipalName :
uSNChanged : 49248653
uSNCreated : 49248451
whenChanged : 01.03.2021 14:04:19
whenCreated : 01.03.2021 14:00:37
Soweit gibt es noch keine Besonderheiten. Auch DSREGCMD liefert den Status.
C:\Users\adm-fcarius.MSXFAQ>dsregcmd /status
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : NO
EnterpriseJoined : NO
DomainJoined : YES
DomainName : MSXFAQ
Device Name : PC-FC-WIN10.msxfaq.de
Aber auch ADSync lässt das Objekt erst einmal unberücksichtigt. Es gibt dort einen Input-Filter, der nur Computerobjekte mit "UserCertificate" liest. Details dazu finden Sie auf ADSync mit Devices
Join Azure AD
Der nächste Schritt ist also die Anlage des Objekts in der Cloud, indem der Computer "aufgenommen wird. Der Schritt addiert nicht nur das Computerobjekt in der Cloud sondern addiert auch ein "userCertificate" am Computerobjekt.
ADSync Flow
Beim nächsten "Import" aus der Cloud erscheint das AzureAD Objekt auf beiden Seiten und schreibt auch etwas zurück
Der "SourceAnchor wird auch hier nur als der BASE64-codierten ObjectGUID des Computerobjekts im lokalen Active Directory gebildet. Dazu liest ADSync aus dem lokalen AD folgende Felder aus: Aus dem AzureAD kommt aber auch noch ein "CloudSourceAnchor", der aber nicht mit der ObjectGUID matched.
Regel Computer Join
Bei einem Blick in die Regeln von ADSync fällt aber die Regel "In from AD - Computer Join" auf und die besagt, dass eine Übereinstimmung anhand der ObjectGUID im lokalen AD und der deviceid im AzureAD bestehen muss
Dann schauen wir uns die beiden Felder im AzureAD und lokalen AD per Powershell an.
PS C:\> Get-ADComputer pc-fc-win10 -Properties objectguid | select name,objectguid Name : PC-FC-WIN10 ObjectGUID : cf280414-d476-47f1-a7ab-e85bf1c9cbe6
Und im AzureAD:
PS C:\> Get-AzureADDevice -SearchString pc-fc-win10 | fl Displayname,ObjectID,DeviceID DisplayName : PC-FC-WIN10 ObjectId : 97ca5b53-7a41-4360-b29e-e7def5f210df DeviceId : cf280414-d476-47f1-a7ab-e85bf1c9cbe6
Und tatsächlich stimmt hier die DeviceID im AzureAD mit der lokalen ObjectGUID überein. Natürlich habe ich dann versucht das Feld in der Cloud einmal zu ändern. Bei Benutzern gibt es ja die "ImmutableID". Das war aber nicht erfolgreich. Zuerst wollte ich einfach eine Zahl schreiben.
PS C:\> Get-AzureADDevice -SearchString pc-fc-win10 | Set-AzureADDevice -DeviceId 12345 Set-AzureADDevice : Error occurred while executing SetDevice Code: Request_BadRequest Message: Cannot convert a primitive value to the expected type 'Edm.Guid'. See the inner exception for more details.
Das wurde aber mit der Begründung abgelehnt, dass es keine GUID ist. Also habe ich einfach eine GUID genommen aber auch das funktoinierte nicht
PS C:\> Get-AzureADDevice -SearchString pc-fc-win10 | Set-AzureADDevice -DeviceId 97ca5b53-7a41-4360-b29e-e7def5f210df Set-AzureADDevice : Error occurred while executing SetDevice Code: Request_BadRequest Message: Unable to update the specified properties for On-Premises mastered Directory Sync objects or objects
Und hier ist die Fehlermeldung auch deutlich, dass dieses Objekt mit dem lokalen AD synchronisiert wird.
Metaverse
Im Metaverse sehe ich dann noch mal alle Properties und woher die Daten kommen.
Ergebnis
Der "Source Anchor" bei einem Device oder Computer ist die ObjectID des lokalen Active Directory, welche mit der DeviceID im AzureAD verbunden ist. Anders als bei Benutzer oder Gruppen kommt hier nicht die ms-ds-ConsistencyGuid als alternatives Feld zum Einsatz. Im AzureAD ist das relevante Feld die "DeviceID", welche auch per Get-AzureADDevice gelesen werden kann. Ich konnte das Feld aber nicht manuell setzen.
Für Migrationen bedeutet dies, dass Sie beim Verschieben eines Computers in eine andere OU oder eine andere Domain des gleichen Forests natürlich die ObjectGUID beibehalten aber sie aufpassen müsse, dass das Objekt nie von ADSync als "gelöscht" angesehen wird.
