ADSync mit Devices

ADSync repliziert nicht nur Benutzer und Gruppen samt Exchange Eigenschaften, sondern kann auch Computerobjekte zwischen dem AzureAD und dem lokalen AD synchronisieren.

Beachten Sie dazu auch die Seite SourceAnchor Computer, Azure AD Join und Device Registration.

Überblick

Ein Computer ist nicht mehr "nur" Mitglied einer lokalen Domäne. Auch im AzureAD können Computer durch Intune verwaltet werden. Das geht so weit, dass ein Computer sogar "Mitglied" eines "AzureAD Domin Services" sein kann, was hier erst einmal kein Thema ist. Ein Computer kann aber im AzureAD selbst den Status "Registered", "Joined" oder "Hybrid Joined" haben. Daraus erwachsen unterschiedliche Möglichkeiten das Gerät zu verwalten aber auch über Conditional Access zu berechtigen.

ADSync ist dabei eine wichtige Komponente, denn zu einem Gerät können Informationen im lokalen Active Directory aber auch im AzureAD liegen. Diese Informationen müssen abgeglichen werden. Abhängig vom Status des Geräts kommt ADSync eine andere Rolle zu:

Typ AD-Objekt AzureAD-Objekt Beschreibung

Unbekannt

Kein Objekt

Kein

Ein Computer ohne Mitgliedschaft in der Domäne erscheint weder im lokalen Active Directory noch im Azure Active Directory. Es sind Computer in einer Workgroup, auf denen sich auch noch nie jemand gegen Office 365/AzureAD registriert hat

AzureAD Registered

Kein Objekt

"Registered" AzureAD Objekt

Wenn ein Anwender auf einem Client ohne Mitgliedschaft im lokalen AD oder AzureAD die Cloud-Dienste nutzt, kann eine Registrierung am AzureAD erfolgen. Das Gerät ist dann nur im AzureAD als "registered" bekannt.

AzureAD Joined

Device-Objekt mit WriteBack

"Joined"-AzureAD Objekt

Ein Computer kann aber auch komplett ohne lokale Active Directory in das AzureAD aufgenommen und dann von dort z.B. Intune verwaltet werden.

Mitglied in lokalem AD

Computerkonto

KEIN Objekt

Das klassische lokale Computerkonto einer Firma ist natürlich Mitglied in einer Domäne und dazu gehört ein Computerkonto im Active Directory. ADSync "sieht" das Konto aber synchronisiert es noch nicht in die Cloud.

Hybrid AzureAD Joined

Computerkonto mit AzureAD-Zertifikat im Feld "UserCertificate"

AzureAD Objekt durch ADSync angelegt

Wenn der Domain-Computer auch im AzureAD registriert ist, dann stellt AzureAD ein Computer-Zertifikat aus. Der Computer schreibt dieses Zertifikat dann in lokale Active Directory in das Feld "UserCertificate". Die Existenz des Feldes ist für ADSync das Kriterium das Computerkonto ins die Cloud überträgt und damit ein" Hybrid Join"-Status erhält.

Weitere Details  zu den verschiedenen Zuständen eines Computer in Verbindung mit dem AzureAD finden Sie auch auf Device Registration und Azure AD Join.

Auf die weitere Möglichkeit der "Azure AD Domain Services" gehe ich hier nicht weiter ein.

Hybrid AzureAD Joined

Eine besondere Stellung nehmen die "Hybrid AzureAD Joined Device ein. Um diesen Status zu erreiche, müssen einige Komponenten zusammenspielen.

Der Prozess durchläuft folgende Schritte:

  • Der Computer wird ganz normal Mitglied im lokalen AD
    Meiner Erfahrung nach ist dieser Schritt schon nicht mehr möglich, wenn der Computer schon im AzureAD als "AzureAD Joined"-Device geführt wird.
  • Anwendung der Gruppenrichtlinie
    Der Administrator sollte per Gruppenrichtlinie dann vorgeben, dass sich dieser Computer im AzureAD registrieren soll.
  • Registrierung im AzureAD
    Der Computer wendet sich dann an das AzureAD und erstellt ein "Device Certificate". Laut Microsoft ist dies ein "SelfSigned"-Cert aber das ist wohl nur initial der Fall.
  • Upload Zertifikat ins lokale AD
    Über die Gruppenrichtlinie weiß nun der Client auch, dass er das Zertifikat ohne den privaten Key ins Computerobjekt veröffentlichen muss.

Damit wissen Sie nun auch, dass Sie über eine LDAP-Suche im lokalen AD nach Computern mit einem Wert im Feld "Usercertificate" die AzureAD-Computer finden können.

  • ADSync repliziert die Information
    Nur Computer mit einem Zertifikat in "Usercertificate" werden von ADSync auch ins AzureAD repliziert.
  • Match und Hybrid Join
    Damit ist der Prozess abgeschlossen und sie sollten nun ein Device im AzureAD-Portal sehen, welche des Status "Hybrid AzureAD Joined" hat

Microsoft hat sogar noch ein etwas umfangreichere Bild publiziert

Device Zertifikat

Ich habe andere Blog-Artikel gesehen bei denen en Client ein "SelfSigned"-Zertifikat erstellt und dann immer wieder sich damit ausweisen will, z.B.

Das deckt sich aber nicht mit meiner Analyse. Wenn ich meinen PC nach dem Device Zertifikat mit "DSREGCMD /status" abfrage, dann bekomme ich folgende Information:

Passend dazu gibt es in meinem Zertifikatspeicher des lokalen Computers ein von "MS-Organization-Access" ausgestelltes Zertifikat.

Die passende IssuingCA ist auf meinem Client zwar nicht als "Trusted Root" addiert, aber das muss sie auch nicht sein. Es ist aber definitiv kein "SelfSigned"-Zertifikat.

Object Writeback

Wenn es Objekte im lokale Active Directory und im AzureAD gibt, dann muss die ja auch finden. Auf AzureAD haben Sie natürlich keinen "LDAP"- Zugriff aber per Powershell finden Sie dort schon entsprechende Computerkonten. Im lokalen Active Directory ist es anders. Hier können Sie per LDAP nach den Geräten suchen und neben den bekannten "Computerkonten" müssen Sie bei der Einrichtung von ADSync mit Device-Writeback auch eine OU für diese "Geräte" angeben. Dort landen dann Objekte vom Typ "msDS-Device".

Damit erkennt dann auch das lokale Active Directory diese Objekte, denn es gibt durchaus die Funktion, dass ein Computer, welcher nur "AzureAD-Joined" ist, dennoch per VPN eine Verbindung in ihr Firmennetzwerk hat und der Nutzer per Kerberos auf interne Server zugreifen kann.

ADSync Konfiguration

Standardmäßig findet diese Replikation aus dem lokalen Active Directory in die Cloud nicht ohne entsprechende Vorarbeiten statt und die Gegenrichtung erfordert sogar eine Lizenz für die Funktion "Device Writeback", z.B. AzureAD P1. Wenn Sie den Setup-Assistenten für ADSync starten, dann sollten Sie auch die Funktion "Configure device options" finden:

Schon im ersten Fenster bekommen Sie beide Optionen erklärt. Hybrid Azure AD Join erfordert ein Service Connection Point in ihrem lokalen Active Directory. Kompatible Clients, die Mitglied ihrer lokalen Active Directory Domäne sind, suchen nach diesem LDAP-Eintrag und versuchen dann sich auch im AzureAD zu registrieren.

Im ersten Schritt konfiguriere ich "Hybrid Azure AD Join" über die Optionen:

Der Assistent fordert mich dann auf, die Forests auszuwählen, in denen er den SCP anlegen soll und mit welchem Konto ich diesen Eintrag anlege.

Dann kommt nur noch eine Rückfrage, ehe der Eintrag angelegt wird: 

Wenn alles in Ordnung ist, dann sehen Sie den Bestätigungsdialog.

Im Hintergrund wurde nun ein LDAP-Objekte in der Configuration-Partition ihres Forest angelegt. Der Name ist immer gleich:

CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=domain,DC=tld

azureADId; The Azure Active Directory tenant ID
azureADName; DNS-Domäne aus dem Azure AD oder ersatzweise die *.onmicrosoft.com DNS domain name

Wenn Sie einen Forest mit mehreren Tenants verbinden, dann sollten Sie den richtigen Tenant über Gruppenrichtlinien zuweisen und den Service Connection Point entfernen.

Das ist einfach nur ein Pointer" für den Client, an welchem AzureAD er sich registrieren muss.

Achtung: Es gibt keine weitere Verifikation oder Kennwort o.ä. Wenn ein Angreifer die Werte ändert, dann melden sich ihre Clients am falschen AzureAD an

Für den Fall, dass eine Firma nicht nur genau ein AzureAD hat, sondern mehrere Tenants angebunden sind, sollten Sie die Konfiguration pro Client über eine Gruppenrichtlinie vornehmen und auf den SCP verzichten.

Device ohne UserCertificate

Es reicht nicht, in ADSync die Funktion "Hybrid Computer Join" zu aktivieren. Wenn Sie sich dann ADSync anschauen, dann erkennen sie das Lesen der Computerobjekte ins Metaverse:

Allerdings hat das Objekt nur den Connector zum lokalen Active Directory:

Die Ursache finden Sie in den Synchronization Rules des eingehenden Connectors aus dem lokalen AD:

Hier gibt es eine Transformationsregel, die das Feld "CloudFiltered" auf "true" setzt, wenn besondere Bedingungen erfüllt sind.

Die ausgeschriebene Bedingung in den ADSync Transformation-Rules ist:

IIF(
IsNullOrEmpty([userCertificate])
|| (
(InStr(UCase([operatingSystem]),"WINDOWS") > 0)
&& (Left([operatingSystemVersion],2) = "6.")
),
True,
NULL)

Es muss sich zuerst einmal um einen Windows Client Version 6  (also Windows Vista-8.1 oder 2008-2012R2) handeln oder das Feld "UserCertificate" des Computerkontos muss gefüllt sein

Das Feld "UserCertificate" ist bei einem normalen "Domain Joined"-Computer eigentlich leer. Aber wenn der Computer dann erfolgreich sich mit dem AzureAD registriert hat, dann bekommt er von der Cloud ein Zertifikat, welches er in das Feld UserCertificate im lokalen AD hinterlegt.

Damit ist diese Feld ab Windows 10 zugleich in guter Indikator, welche Computer es schon geschafft haben.

Device mit UserCertificate

Sobald das Computerkonto das Feld bekommen hat, erkennt ADSync dies beim nächsten Lauf und importiert das Feld in das Metaverse:

Dann ist er nicht mehr "Cloud Filtered:$True" und der Connector zum Tenant wird aktiv.

Per Powershell können Sie das Gerät auch im AzureAD finden:

PS C:\> Get-AzureADDevice -SearchString fc-t480s | fl


DeletionTimestamp             :
ObjectId                      : ba94d06f-17da-4b82-983c-e8bde7535042
ObjectType                    : Device
AccountEnabled                : True
AlternativeSecurityIds        : {class AlternativeSecurityId {
                                  IdentityProvider:
                                  Key: System.Byte[]
                                  Type: 2
                                }
                                }
ApproximateLastLogonTimeStamp : 07.02.2021 05:31:03
ComplianceExpiryTime          :
DeviceId                      : d7402cb8-aaba-46ea-a613-cb300c8b55e5
DeviceMetadata                :
DeviceObjectVersion           : 2
DeviceOSType                  : Windows
DeviceOSVersion               : 10.0.18362.0
DevicePhysicalIds             : {[USER-GID]:f0e2c2ef-0ebe-4633-900d-xx:xxx,
                                [GID]:g:xxx,
                                [USER-HWID]:f0e2c2ef-0ebe-4633-900d-xxx:xxx,
                                [HWID]:h:xxx}
DeviceTrustType               : Domain Joined
DirSyncEnabled                :
DisplayName                   : PC-FC-WIN10
IsCompliant                   :
IsManaged                     :
LastDirSyncTime               :
ProfileType                   : RegisteredDevice
SystemLabels                  : {}

Der "DeviceTustType ist hier der Schlüssel:

DeviceTrustType Beschreibung

"Domain Joined"

Der PC ist Mitglied einer lokalen Active Directory Domäne und wird per ADSync dank eines vorhandenen UserCertificate auch ins Azureda repliziert. Er ist als ein "Hybrid Joined" Device

"Azure AD Joined"

Der Computer ist quasi "Mitglied" im Azure AD und kann auch von dort verwaltet werden aber es gibt keinen Gegenpart im lokalen Active Directory

"Workplace"

Dieser Status entspricht "Azure AD Registered"

Mein Testcomputer erscheint in der Cloud nun als "Hybrid Joined".

In dem kleinen Fenster zwischen "PC erfolgreich im AzureAD angemeldet" und "ADSync hat repliziert", ist das Computerkonto in der Cloud nur "Azure Joined". Das "Hybrid" kommt also im nachhinein und nicht vorab. Aber selbst dann dauert es noch etwas, bis der Computer die Partnerschaft mit dem AzureAD abschließt.

Ich habe auch einen PC lokal mit einem UserCertificate angelegt, ohne dass es ein Gegenstück in der Cloud gegeben hätte: ADSync hat den Computer in den Connectorspace repliziert aber wartet nun auf das eingehende Objekt aus der Cloud.

Den Prozess zum Registrieren können Sie auf dem Client auch manuell antriggern:

dsregcmd /join

Den aktuellen Status können Sie auch abfragen.

dsregcmd /status

Dann erscheint der Status "Registered" mit einem Datum:

Microsoft pflegt nicht nur seine Dokumentation in GIT sondern auch Fragen und Verbesserungen. So findet sich auch folgender Dialog, der die Funktion detaillierter beschreibt:

In its default configuration from version 1.1.553 Azure AD Connect wont synchronise Computer objects unless the userCertificate attibute is populated. Is this attribute required for implementing hybrid domain join? Can I safely disable this Scoping Filter on the Out to AAD - Device Join SOAInAD rule in AAD Connect?

Specific to userCertificate attribute on Device objects, Azure AD Connect now looks for certificates values required for Connecting domain-joined devices to Azure AD for Windows 10 experience and filters out the rest before synchronizing to Azure AD. To enable this behavior, the out-of-box sync rule “Out to AAD - Device Join SOAInAD” has been updated.

Out to AAD - Device Join SOAInAD sync rule is used to implement Hybrid Azure ad join / Domain Join in a managed domain. In a federated domain this rule is not used as the STS / AD FS would authenticate the device. In a managed domain the certificate for the device would be used to authenticate the device in AAD. You can disable the sync rule as long as you are using a federated environment.

The userCertificate attribute on the computer account in your On-Premises AD gets populated by the User Device Registration Scheduled Task on the workstation. It generates a self-signed certificate and populates the computer account with the public key of this cert.
Quelle: https://GitHub.com/MicrosoftDocs/azure-docs/issues/5872

Computer gelöscht

Nichts ist für die Ewigkeit und natürlich wird auch ein Computer irgendwann ersetzt. Also löschen Sie im normalen Provisioning-Prozess auch das Computerkonto im lokalen Active Directory. Wenn Sie den Computer noch "geplant" aus der Domäne entfernen, dann passiert mit einem "Hybrid Joined" PC folgendes:

Aktion Lokales AD AzureAD ADSync

Computer wird aus aus dem ADSync Scope verschoben

Computerkonto ist in einer anderen OU aktiv

Das Computerobjekt wird im AzureAD gelöscht!

ADSync erkennt eine "Löschung" des Objekts und entfernt das AzureAD-Objekt. Das ist inkonsistent, da das lokale AD-Objekte und der Computer ja noch da sein können aber keine AzureAD-Verbindung mehr haben

Computerobjekt wird im lokalen AD wieder hergestellt bzw. in den ADSync-Scope verschoben

Computerkonto ist wieder in einer ADSync-akivierten OU

Computer wird neu angelegt!

ADSync repliziert wieder das Objekt aber es wird mit einer neuen ObjectID angelegt und ist "Pending", d.h. der Client muss die Verbindung neu aufbauen

Computer wird aus der Domain entfernt

Computerkonto wird deaktiviert aber nicht gelöscht.

Computer wird in AzureAD deaktiviert

ADSync hält das Cloud-Objekte auch auf dem aktuellen Stand.

Computerobjekt wird im AzureAD entfernt

Unverändert

Computer verschwindet

ADSync erkennt den "Delete" im AzureAD und stellt das Objekt wieder mit einer neuen ObjectID her. Der Computer hat keine Verbindung mehr mit Azure. Das lokale AD-Konto wird nicht verändert und der Computer ist weiterhin Domainmitglied.

Je nach Aktion ist es also möglich, dass ein Domain-Computer mit Registrierung im AzureAD diese Registrierung verliert. Es gibt in der Cloud kein "Undelete" eines Device, um Fehler beim Provisioning ungeschehen zu machen. Der lokale PC bekommt von dem allem aber erst mal nicht direkt etwas mit und denkt, er wäre immer noch AzureAD-Joined. Spätestens nach dem Reboot wird auf dem Client dies aber bemerkt

C:\>dsregcmd /status

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : YES
          EnterpriseJoined : NO
              DomainJoined : YES
                DomainName : MSXFAQ
               Device Name : PC-FC-WIN10.msxfaq.de

+----------------------------------------------------------------------+
| Device Details                                                       |
+----------------------------------------------------------------------+

                  DeviceId : cf280414-d476-47f1-a7ab-e85bf1c9cbe6
                Thumbprint : E98B66563EE2369868A2087ED6230DFFAFB57A20
 DeviceCertificateValidity : [ 2021-03-01 17:06:01.000 UTC -- 2031-03-01 17:36:01.000 UTC ]
            KeyContainerId : 53c51e0c-fd8f-40d5-a218-4837d5bb68d3
               KeyProvider : Microsoft Software Key Storage Provider
              TpmProtected : NO
          DeviceAuthStatus : FAILED. Device is either disabled or deleted

Der Benutzer bekommt aber eine Meldung im Messagecenter von Windows 10, dass er sein "Konto reparieren muss".

Allerdings wird es nicht selbständig repariert. Der Fehler wird auch im Eventlog gelistet

Protokollname: Microsoft-Windows-AAD/Operational
Quelle:        Microsoft-Windows-AAD
Datum:         02.03.2021 17:18:44
Ereignis-ID:   1081
Aufgabenkategorie:AadCloudAPPlug-in Operation
Ebene:         Fehler
Schlüsselwörter:Operational,Error
Benutzer:      SYSTEM
Computer:      PC-FC-WIN10.msxfaq.de
Beschreibung:
OAuth response error: invalid_grant
Error description: AADSTS50155: Device authentication failed.
Trace ID: aa7baa1f-8b4a-4a5b-b6dd-xxxxxxxxxx
Correlation ID: d483c4b5-45b6-4888-ab8c-xxxxxxx
Timestamp: 2021-03-02 16:18:44Z
CorrelationID: d483c4b5-45b6-4888-ab8c-xxxxxxxx

Die Lösung: Sie müssen dann schon das Gerät mal aus AzureAD entfernen und wieder neu aufnehmen. Das geht per GUI aber auch per klassischer Kommandozeile als Administrator.

DSREGCMD /leave
DSREGCMD /join

Bei mir hat es aber einen Reboot gebraucht, dass die Verbindung zum AzureAD wieder hergestellt wurde.

Weitere Links