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
- Hybrid Azure AD joined in Managed
environments
https://learn.microsoft.com/en-us/azure/active-directory/devices/device-registration-how-it-works#hybrid-azure-ad-joined-in-managed-environments
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.
- Digging into Hybrid Azure AD Join
https://oofhours.com/2020/05/23/digging-into-hybrid-azure-ad-join/
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 Bidirektional
- Conditional Access
- Azure Conditional Access
- Azure AD Join
- Djoin - Offline Domain Join
- Device writeback
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-aadconnectsync-attributes-synchronized#device-writeback - Connect domain-joined devices to Azure
AD for Windows 10 experiences
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-azureadjoin-devices-group-policy - Configuring Writeback Permissions in
Active Directory for Azure Active Directory
Sync
http://c7solutions.com/2015/07/configuring-writeback-permissions-in-active-directory-for-azure-active-directory-sync
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.
- Tutorial: Configure hybrid Azure Active Directory join for managed domains
https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-managed-domains - A closer look at Azure AD Connect’s Service Connection Point
https://dirteam.com/sander/2020/03/23/a-closer-look-at-azure-ad-connects-service-connection-point/ - Enroll a Windows device automatically
using Group Policy
https://learn.microsoft.com/en-us/windows/client-management/enroll-a-windows-10-device-automatically-using-group-policy
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.
- Operating System Version
https://docs.microsoft.com/en-us/windows/win32/sysinfo/operating-system-version - Operating-System-Version attribute
https://docs.microsoft.com/en-us/windows/win32/adschema/a-operatingsystemversion
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
- Azure AD Join
- ADSync Bidirektional
- Device Registration
- Djoin - Offline Domain Join
- SourceAnchor
- SourceAnchor Computer
- How To: Plan your hybrid Azure Active
Directory join implementation
https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-plan - Azure AD Connect: Device options
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-device-options - Azure AD Hybrid Join and the
UserCertificate Attribute
https://www.amobileattempt.com/2018/07/hybrid-join-azure-ad-and.html - userCertificate required on AD Computer account for AAD Connect to sync
https://GitHub.com/MicrosoftDocs/azure-docs/issues/5872 - Hybrid Azure AD joined in Managed
environments
https://learn.microsoft.com/en-us/azure/active-directory/devices/device-registration-how-it-works#hybrid-azure-ad-joined-in-managed-environments - Azure AD Connect: Device options
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-device-options - Azure AD Connect: Enabling device writeback
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-device-writeback - (2019-10-08) Synched Computers/Devices Being Cleaned Up From Azure AD
https://jorgequestforknowledge.wordpress.com/category/active-directory-domain-services-adds/active-directory-users-and-computers/ - Understanding Azure AD Connect 1.4.xx.x and device disappearance
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-device-disappearance - Troubleshooting weird Azure AD Join
issues
https://www.itpromentor.com/troubleshooting-weird-azure-ad-join-issues/ - (2019-10-06) Examining Pending Export Deletions In Azure AD Connect
https://jorgequestforknowledge.wordpress.com/2019/10/06/examining-pending-export-deletions-in-azure-ad-connect/ - How does a hybrid Azure AD join work?
https://albertneef.wordpress.com/2019/01/15/how-does-a-hybrid-azure-ad-join-work/ - Digging into Hybrid Azure AD Join
https://oofhours.com/2020/05/23/digging-into-hybrid-azure-ad-join/ - Understanding Azure AD Connect 1.4.xx.x
and device disappearance
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-device-disappearance - Find The Azure AD Join Type
https://www.petenetlive.com/KB/Article/0001597