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.

Weitere Links