Was ist Hybrid Azure AD Join ?

Beginnen wir einfach mit der offiziellen Definition aus der Microsoft Dokumentation:

Hybrid Azure AD Join: Joined to on-premises AD and Azure AD requiring an organizational account to sign in to the device.

Dies bedeutet, dass sich das Gerät, nachdem es Hybrid Azure AD Joined wurde, genauso verhält wie jeder andere Computer, der mit Active Directory verbunden ist.

• Man muss sich mit einem Active Directory-Konto anmelden.
• Die Benutzeranmeldeinformationen werden mit einem Active Directory-Domänencontroller abgeglichen.
• Gruppenrichtlinienobjekte für Benutzer & Computer, die vom Domänencontroller gelesen werden) werden automatisch angewendet.

Nachdem der Active Directory Verbindungsprozess abgeschlossen ist, werden zusätzliche Schritte im Hintergrund asynchron durchgeführt, um das Gerät auch in Azure AD zu registrieren.

Warum Hybrid Azure AD Join ?

Man erhält das Beste aus der Cloud und der On-Prem Welt. Sobald das Gerät bei Azure AD registriert ist, erhalten nachfolgende Benutzeranmeldungen einen zusätzlichen Vorteil. Man erhält nicht nur ein Kerberos-Ticket von Active Directory, sondern auch ein Azure AD Benutzer Token, das für den Zugriff auf Azure AD geschützte Ressourcen wie Teams, Microsoft365 Apps oder OneDrive verwendet werden kann. Zusätzlich können die Geräte auch in beiden Welten verwaltet werden. Auf diese Weise ist man in der Lage, Tools wie Single Sign-On und Conditional Access zu nutzen und gleichzeitig GPOs und andere On-Premises-Dienstprogramme anzuwenden.

Des weiteren hilft ein Hybrid Azure AD Join bei verschiedenen Fehlern mit Microsoft Teams, OneDrive for Business, Microsoft365 Apps oder Edge (Chromium Based). Die folgenden Fehlerfälle treten nicht bei all meinen Kunden auf und es ist auch nicht ersichtlich, wann es dazu kommen kann. Das sind unsere geliebten RANDOM Fehler, wo ein Hybrid Azure AD Join der Worker bei Windows Server 2019 Worker geholfen hat.

Wichtig bei allen SSO Themen mit Teams und OneDrive for Business ist, dass Azure AD auch korrekt für SSO konfiguriert ist (Aktivierung PHS oder PTA).

Fehlerfälle Microsoft365 Apps

Bei Microsoft365 Apps (ehemals Office365) Published Application schlägt die Office Lizensierung fehl (Citrix Nummer LCM-7637).

Bei Microsoft365 Apps mit UPM 1912 wird der Shared Activation Token nicht erstellt.

Mit deaktivierten UPM oder anderen Version als 1912 funktioniert dies auf dem selben System.

Bei Microsoft365 Apps kommt der Fehlercode CAA50021 und die Server message Number of retry attempts exceeds expectation.

Diese Fehler konnten alle mit Hybrid Azure AD Join gelöst werden.

Fehlerfälle Microsoft Teams

Bei Microsoft Teams kommt der Error Code 80070003 beim zweiten Start von Microsoft Teams, wenn der darauffolgende (zweite, dritte usw.) Start auf einem anderen Worker durchgeführt wird, als der erste.

Bei Microsoft Teams kommt der Error Code c00ce584 bei verschiedenen Benutzern. Der Fehler kommt aber nicht bei allen Benutzern auf einem System.

Diese Fehler konnten alle mit Hybrid Azure AD Join gelöst werden.

Fehlerfälle Microsoft Edge & OneDrive for Business

Bei Microsoft Edge & OneDrive for Business funktioniert der SSO nicht sauber auf den Workern. Benutzername und Passwortabfrage auf dem Worker nach der Anmeldung.

Weitere Begriffe

Service connection points

Bevor Sie hybride Azure AD-Join-Geräte verwenden können, muss die lokale Active Directory über Azure AD Connect mit der eigenen Azure AD synchronisiert werden. Azure AD Connect verwendet einen Assistenten, um Hybrid Azure AD Join einzurichten, einschließlich der Konfiguration des Service connection points (SCP) in der lokalen Active Directory, die für die Geräteregistrierung bei Azure AD erforderlich ist.

Jeder AD Forest benötigt einen eigenen SCP. Da die Azure AD Registrierung für hybride Azure AD verbundene Geräte automatisch erfolgt, ist ein SCP erforderlich, um während des Registrierungsprozesses Informationen über den Azure AD Tenant zu finden.

Der SCP wird im AD (unter CN=Services) als Container unter CN=Device Registration Configuration registriert. In den Eigenschaften des Containers gibt es ein Attribut namens keywords, das zwei Zeichenfolgen enthält, die Windows verwendet, um den Azure AD Tenant zu finden.

Primary Refresh Token (PRT)

Der Primary Refresh Token (PRT) ist ein Schlüsselartefakt der Azure AD Authentifizierung. Es handelt sich um ein JSON Web Token (JWT), das speziell ausgestellt wird, um Single Sign-On (SSO) für die Anwendungen zu ermöglichen, die auf diesen Geräten verwendet werden.

Ein PRT enthält Claims, die im Allgemeinen in jedem Azure AD Refresh-Token enthalten sind. Zusätzlich gibt es einige gerätespezifische Claims, die in dem PRT enthalten sind. Diese sind wie folgt:

• Device-ID: Ein PRT wird für einen Benutzer auf einem bestimmten Gerät ausgestellt. Der Device-ID-Claim deviceID bestimmt das Gerät, auf dem das PRT an den Benutzer ausgestellt wurde. Dieser Claim wird später an Token ausgegeben, die über das PRT bezogen werden. Der Device-ID Claim wird verwendet, um die Berechtigungen für Conditional Access, basierend auf dem Gerätezustand oder der Konformität zu bestimmen.
• Session Key: Der Session Key ist ein verschlüsselter symmetrischer Schlüssel, der vom Azure AD Authentifizierungsdienst erzeugt und als Teil des PRT ausgegeben wird. Der Session Key dient als Nachweis, wenn ein PRT verwendet wird, um Token für andere Anwendungen zu erhalten.

Ein einmal ausgestelltes PRT ist 14 Tage lang gültig und wird laufend erneuert, solange der Benutzer das Gerät aktiv nutzt.

Computer Accounts und Certificates

Wenn Windows Geräte den SCP in der lokalen AD sehen, beginnen diese zu versuchen, sich bei Azure AD zu registrieren. Aber die Registrierung kann nicht abgeschlossen werden, bis ein paar weitere Bedingungen erfüllt sind.

Erstens muss das Computerkonto des Geräts von der lokalen AD mit Azure AD synchronisiert werden. Standardmäßig synchronisiert Azure AD Connect die Objekte alle 30 Minuten.

Zweitens synchronisiert Azure AD Connect das Computer Objekt erst dann, wenn sein userCertificate-Attribut mit einem selbst signierten Zertifikat gefüllt ist, das vom Gerät selbst generiert wurde.

Aber unabhängig davon, ob sich das Computerobjekt mit Azure AD synchronisiert hat, versucht das Gerät, sich bei Azure AD zu registrieren, was zu einem Fehler führt.

Wenn sich das Gerät erfolgreich bei Azure AD registriert hat, ist das Event 306 im Protokoll User Device Registration zu sehen: ‚Automatic registration Succeeded‘. Nach der Registrierung erhalten Benutzer auch ein Primary Refresh Token (PRT) von Azure AD, das für die Authentifizierung bei Diensten, die Azure AD verwenden, verwendet werden kann.

Wenn sich der Benutzer anmeldet, bevor die Azure AD Registrierung abgeschlossen ist, muss er sich entweder ab- und wieder anmelden oder das Gerät sperren und dann entsperren, um sich bei Azure AD zu authentifizieren.

Einrichten Hybrid Azure AD Join

Beginnen wir damit, uns anzusehen, wie wir den hybriden Azure AD-Join einrichten können.

Voraussetzungen

Es müssen folgende technische Anforderungen erfüllt sein:

• Betriebssystem Windows Server 2016, 2019 oder Windows 10 (Version 1809) Pro oder höher
• Rolle des Domain Controllers muss konfiguriert sein
• Synchronisation zum Azure AD (mit dem Azure AD Connect) muss konfiguriert sein
• Lokaler Active Directory UPN-Suffix mit einer passenden benutzerdefinierten Domäne in Azure AD
• Das Gerät muss Mitglied der lokalen Domäne sein
• Internet Konnektivität auf dem Windows Gerät und Firewall freigaben für die folgenden Zieladressen:
  • enterpriseregistration.windows.net:443
  • login.microsoftonline.com:443
  • device.login.microsoftonline.com:443
• Zugriff zum lokalen Administrator Account und zum globalen Azure AD Administrator

Nicht unterstützte Szenarien

• Hybrid Azure AD Join wird derzeit nicht unterstützt, wenn ein einzelner AD Forest mit mehr als einem Azure AD-Tenant synchronisiert werden soll
• Hybrid Azure AD Join wird für Windows Server mit der installierten Domain Controller (DC) Rolle nicht unterstützt
• Server Core OS unterstützt keine Art von Geräteregistrierung

Azure AD Connect konfigurieren

Als erstes öffnet Azure AD Connect.

Klickt im Welcome Screen auf Configure.

Danach werden eine ganze Liste von Additional tasks angezeigt, in der Configure device options ausgewählt werden soll. Bestätigt dies per klick auf Next.

Danach klickt auf der Overview Seite auf Next.

Im folgenden Fenster müssen die Anmeldedaten eines Azure AD Global Administrator hinterlegt werden.

Klickt nach der Eingabe auf Next, damit die Verbindung aufgebaut wird.

Nun wird Hybrid Azure AD join ausgewählt und per klick auf Next bestätigt.

Danach wird gewählt, welche Windows Versionen unterstützt werden sollen. Man kann beide Optionen auswählen, um auch ältere Betriebssysteme zu unterstützen oder wie in unserem Fall, nur die Option Windows 10 or later domain-joined devices. Mit dieser Option werden auch Windows Server 2016 und 2019 aktiviert. Ältere Betriebssysteme, in diesem Zusammenhang, sind zum Beispiel Windows Server 2012 oder Windows 8.1. Per Klick auf Next wird die Auswahl bestätigt.

Im SCP configuration Fenster werden die Forests ausgewählt, die konfiguriert werden soll.

Wählt den gewünschten Forest aus und klickt auf das erscheinende Add um den benötigten lokalen Enterprise Admin zu hinterlegen.

Es folgt eine Anmeldemaske indem der On-Prem Administrator hinzugefügt werden soll. Bestätigt die Anmeldedaten mit OK.

Bestätigt die Konfiguration mit einem Klick auf Next.

Es wird nun geprüft, ob schon SCP konfiguriert ist.

Im anschließenden Fenster kann die Konfiguration des SCP in der lokalen Active Directory gestartet werden. Klickt hierfür auf Configure.

Der Azure AD Connect synchronization Service wird ebenfalls in dem Zuge angepasst.

Anschließend wird die erfolgreiche Konfiguration noch Bestätigt. Per Exit kann der Wizard geschlossen werden.

Überprüfung der Konfiguration

Jetzt kann geprüft werden, dass die Konfiguration des hybriden Azure AD Join erfolgreich war. Da die oben genannten Betriebssysteme sich automatisch hybrid verbinden, sollte man nach maximal 30 Minuten diese auch im Azure Portal sehen.

Active Directory Controller

Als erstes wird der eingerichtete SCP geprüft. Startet hierfür ADSI Edit auf einem Active Directory Controller.

Im ADSI Edit klickt mit der rechten Maustaste auf den obersten Eintrag (ADSI Edit) und im folgenden Menü auf Connect to….

Im folgenden Fenster wählt unter Select a well known Naming Context Configuration aus.

Klickt anschließend auf OK.

Klickt im nun verbundenen ADSI Edit auf Configuration > CN=Configuration,DC=… > CN=Services > CN=Device Registration Configuration. Danach auf den letzten Container mit der rechten Maustaste und auf Properties. In den Eigenschaften des Containers gibt es ein Attribut namens keywords, das zwei Zeichenfolgen enthält, die Windows verwendet, um den Azure AD Tenant zu finden.

Wenn der SCP vorhanden ist, sollten die Windows Maschinen sich automatisch am Azure AD anmelden können.

PowerShell

Über das PowerShell Cmdlet Get-MsolDevice kann der Status der Systeme bezüglich Hybrid Azure AD Join im Azure Tenant geprüft werden. Hierfür benötigt man die deviceId des Systems.

Sucht entweder das System in der lokalen Active Directory, klickt mit der rechten Maustaste auf den Computer > Properties > Attribute Editor. Scrollt nach unten zu objectGUID und verwendet diese Nummer als deviceId.

Oder nehmt die deviceId aus dem Error Code im Event Log (given id) des Systems oder die deviceID die beim Befehl dsregcmd /status angezeigt worden ist.

Öffnet PowerShell und führt den unten stehenden Code aus.

Windows Worker

Dies kann aber auch auf der Maschine selbst geprüft werden. Hierzu kann das Event Log geprüft werden (Applications and Service Logs > Microsoft > Windows > User Device Registration > Admin) oder per Command Prompt / PowerShell und dem Befehl dsregcmd /status.

Event Log

Die benötigten Event Logs sind unter Applications and Service Logs > Microsoft > Windows > User Device Registration > Admin zu finden.

…

Hier sollte ein Event mit der ID 306 zu finden sein. Dann hat sich die Maschine erfolgreich an Azure AD angemeldet.

Command Prompt / PowerShell

Hierfür starten wir die CMD oder eine PowerShell Konsole.

Gebt nun den folgenden Befehl ein.

Device State

Unter Device State bedeuten die Einträge:

AzureAdJoined (YES) – Das System ist mit Azure AD verbunden.

EnterpriseJoined (YES) – Das System ist mit ADFS verbunden.

DomainJoined (YES) – Das System ist Mitglied einer Active Directory.

DomainName – Zeigt den Domänen Namen an, wenn es mit einer verbunden ist.

Wichtig!
Ein System kann nicht gleichzeitig AzureAdJoined und EnterpriseJoined sein.

AzureAdJoined	EnterpriseJoined	DomainJoined	Device State
YES	NO	NO	Azure AD Joined
NO	NO	YES	Domain Joined
YES	NO	YES	Hybrid Azure AD Joined
NO	YES	YES	On-Prem ADFS Joined

Device Details

Die Einträge unter Device Details werden nur angezeigt, wenn das System Azure AD Joined oder Hybrid Azure AD Joined ist. Es werden in der Cloud gespeicherte geräteidentifizierende Details angezeigt:

DeviceId – Eindeutige ID des Geräts im Azure AD Tenant.

Thumbprint – Thumbprint des Gerätezertifikats.

DeviceCertificateValidity – Gültigkeitszeitraum des Gerätezertifikats.

KeyContainerId – Container ID des zum Gerätezertifikat gehörenden privaten Geräteschlüssels.

KeyProvider – Key Provider (Hardware / Software), der zum Speichern des privaten Schlüssels des Geräts verwendet wird.

TpmProtected (YES) – Der private Schlüssel des Geräts wird in einem Hardware TPM gespeichert.

Tenant Details

Die Einträge unter Tenant Details werden nur angezeigt, wenn das System Azure AD Joined oder Hybrid Azure AD Joined ist. Es werden die allgemeinen Tenant Informationen aufgelistet.

Wenn die MDM-URL leer ist, bedeutet dies, dass das MDM entweder nicht konfiguriert wurde oder der aktuelle Benutzer sich nicht im MDM Scope befindet.

User State

Es werden unter User State verschiedene Attribute für den aktuell am Gerät angemeldeten Benutzer aufgelistet:

NgcSet (YES) – Bedeutet das für den aktuell angemeldeten Benutzer ein Windows Hello Schlüssel gesetzt ist.

NgcKeyId – ID des Windows Hello Schlüssels, falls einer für den aktuell angemeldeten Benutzer gesetzt ist.

CanReset – Gibt an, ob der Windows Hello Key vom Benutzer zurückgesetzt werden kann (DestructiveOnly, NonDestructiveOnly, DestructiveAndNonDestructive, oder Unknown wenn ein Fehler aufgetreten ist).

WorkplaceJoined (YES) – Impliziert das dem Gerät im aktuellen NTUSER-Kontext Azure AD registrierte Konten hinzugefügt wurden.

WamDefaultSet (YES) – Wenn ein WAM Standard WebAccount für den angemeldeten Benutzer erstellt wird. Es kann ein Fehler angezeigt werden, wenn dsregcmd /status von einer Administrativen CMD / PowerShell ausgeführt wird.

WamDefaultAuthority – Bei Azure AD wird organizations angezeigt.

WamDefaultId – Immer auf https://login.microsoft.com gestellt bei Azure AD.

WamDefaultGUID– Die GUID des WAM Provider (Azure AD / Microsoft-Konto) für den Standard WAM WebAccount.

SSO State

SSO State kann für Azure AD registrierte Geräte ignoriert werden. Es werden nur die Ergebnisse angezeigt für den Benutzer der den Befehl ausführt:

AzureAdPrt (YES) – Wenn für den angemeldeten Benutzer ein PRT auf dem Gerät vorhanden ist.

AzureAdPrtUpdateTime – Wird auf die Zeit in UTC gesetzt, zu der das PRT zuletzt aktualisiert wurde.

AzureAdPrtExpiryTime – Eingestellt auf die Zeit in UTC, zu der das PRT abläuft, wenn es nicht erneuert wird.

AzureAdPrtAuthority – Azure AD authority URL.

EnterprisePrt (YES) – Wenn das Gerät über ein PRT von einer lokalen ADFS Infrastruktur verfügt.

EnterprisePrtUpdateTime – Eingestellt auf die Zeit in UTC, zu der das Enterprise PRT zuletzt aktualisiert wurde.

EnterprisePrtExpiryTime – Eingestellt auf die Zeit in UTC, zu der das PRT abläuft, wenn es nicht erneuert wird.

EnterprisePrtAuthority: – ADFS authority URL.

Diagnostic Data

Es gibt verschiedene Diagnostic Data Container, anhängig in welchem Kontext sich das System befindet.

Pre-Join Diagnostics

Es wird nur angezeigt, wenn das Gerät Domain Joined ist und nicht in der Lage ist Hybrid Azure AD Joined zu werden. Verschiedene Tests werden durchgeführt, die bei der Diagnose von Verbindungsfehlern helfen. Diese Informationen umfassen die Error Phase, Error Codes, Request ID, den Https Status und die Server Message.

User Context – Der Kontext, in dem die Diagnose ausgeführt wird (SYSTEM, UN-ELEVATED User oder ELEVATED User).

Wichtig!
Da der eigentliche Join im SYSTEM-Kontext durchgeführt wird, kommt die Ausführung der Diagnose im SYSTEM-Kontext dem tatsächlichen Join-Szenario am nächsten. Um die Diagnose im SYSTEM-Kontext auszuführen, muss der Befehl dsregcmd /status über eine administrative CMD / PowerShell ausgeführt werden.

Client Time – Die Systemzeit in UTC.

AD Connectivity Test – Führt einen Konnektivität Test zum Domänen Controller durch. Fehler in diesem Test führen wahrscheinlich zu Verbindungsfehlern in der Pre-Check Phase.

AD Configuration Test – Dieser Test liest und prüft, ob das SCP Objekt in der lokalen AD Gesamtstruktur richtig konfiguriert ist. Fehler in diesem Test würden wahrscheinlich zu Join Fehlern in der Discover Phase mit dem Fehlercode 0x801c001d führen.

DRS Discovery Test – Er ruft die DRS Endpunkte vom Discovery Metadata Endpunkt ab und führt einen User Realm Request aus. Fehler in diesem Test würden wahrscheinlich zu Join Fehlern in der Discover Phase führen.

DRS Connectivity Test – Führt einen grundlegenden Konnektivität Test zum DRS-Endpunkt durch.

Token acquisition Test – Dieser Test versucht, ein Azure AD Authentifizierungstoken zu erhalten, wenn der User Tenant Federated ist. Fehler in diesem Test führen zu Join Fehlern in der Auth-Phase. Wenn die Authentifizierung fehlschlägt, wird Sync-Join als Fallback versucht, es sei denn, Fallback wird explizit mit den folgenden Registrierungsschlüssel Einstellungen deaktiviert.

Fallback zu Sync-Join – Ist Enabled, wenn der obige Registrierungsschlüssel nicht vorhanden ist, um den Fallback zu Sync-Join bei Auth-Fehlern zu verhindern.

Previous Registration – Zeitpunkt des letzten Join Versuchs. Es werden nur fehlgeschlagene Join Versuche protokolliert.

Error Phase – Die Join-Phase, in der der Abbruch erfolgte (pre-check, discover, auth oder join).

Client ErrorCode –  Der zurückgegebene Client Error Code (HRESULT).

Server ErrorCode – Wenn eine Anforderung an den Server gesendet wurde und dieser mit einem Fehlercode antwortet.

Server Message – Meldung vom Server, die zusammen mit dem Server Error Code zurückgegeben wird.

Https Status – Der vom Server zurückgegebene HTTP-Status.

Request ID – Die an den Server gesendete Request ID. Praktisch zum vergleichen mit serverseitigen Protokollen.

Post-Join Diagnostics

Zeigt die Ausgabe der Sicherheitsüberprüfungen an, die für ein mit der Cloud verbundenes Gerät durchgeführt wurden.

AadRecoveryEnabled (YES) – Es sind die im Gerät gespeicherten Schlüssel nicht verwendbar und das Gerät wird zur Wiederherstellung markiert. Bei der nächsten Anmeldung wird der Recovery Flow ausgelöst und das Gerät neu registriert.

KeySignTest (PASSED) – Die Device Keys sind in einem gutem Zustand. Wenn KeySignTest fehlschlägt, wird das Gerät normalerweise zur Recovery markiert. Bei der nächsten Anmeldung wird der Recovery Flow ausgelöst und das Gerät neu registriert. Für Hybrid Azure AD Joined Geräte ist die Recovery ohne Abfrage von Zugansdaten. Während bei Azure AD Joined oder Azure AD Registered Geräten eine Benutzer Authentifizierung erscheint, damit das Gerät wiederhergestellt und neu registriert werden kann, falls erforderlich.

Wichtig!
Der KeySignTest erfordert eine administrative Command Prompt / PowerShell.

NGC prerequisite check

Die Vorabprüfungen für die Bereitstellung von Windows Hello for Business (WHFB) werden angezeigt.

Wichtig!
Möglicherweise werden die Details der NGC prerequisite check in dsregcmd /status nicht angezeigt, wenn der Benutzer WHFB bereits erfolgreich konfiguriert hat.

IsDeviceJoined (YES) – Das System ist mit Azure AD verbunden.

IsUserAzureAD (YES) – Der angemeldete Benutzer ist in Azure AD vorhanden.

PolicyEnabled (YES) – Die WHFB Richtlinie ist auf dem Gerät aktiviert.

PostLogonEnabled (YES) – Die WHFB Anmeldung wird nativ von der Plattform ausgelöst. Wenn es auf NO gesetzt ist, zeigt es an, dass die Windows Hello for Business Anmeldung durch einen benutzerdefinierten Mechanismus ausgelöst wird.

DeviceEligible (YES) – Das Gerät erfüllt die Hardware Voraussetzungen für die Anmeldung beim WHFB.

SessionIsNotRemote (YES) – Der aktuelle Benutzer ist direkt am Gerät angemeldet und nicht remotely.

CertEnrollment – Speziell für den Einsatz von WHFB Certificate Trust, das die Registrierungsstelle für Zertifikate für WHFB angibt. Wird auf enrollment authority gesetzt, wenn die Quelle der WHFB Richtlinie die Gruppenrichtlinie ist, auf mobile device management, wenn die Quelle MDM ist. Steht auf none, wenn beides nicht genutzt wird.

AdfsRefreshToken – Speziell für den Einsatz von WHFB Certificate Trust. Nur vorhanden, wenn CertEnrollment auf enrollment authority gestellt ist. Zeigt an, ob das Gerät ein Enterprise PRT für den Benutzer hat.

AdfsRaIsReady – Speziell für den Einsatz von WHFB Certificate Trust. Nur vorhanden, wenn CertEnrollment auf enrollment authority gestellt ist. Ist auf YES gesetzt, wenn ADFS in den Discovery Metadaten angegeben hat, dass es WHFB unterstützt und wenn eine Logon Certificate Template verfügbar ist.

LogonCertTemplateReady – Speziell für den Einsatz von WHFB Certificate Trust. Nur vorhanden, wenn CertEnrollment enrollment authority ist. Auf YES gesetzt, wenn der Status der Logon Certificate Template gültig ist und bei der Fehlersuche in ADFS RA hilft.

PreReqResult – Liefert das Ergebnis aller WHFB Prerequisite Evaluation. Wird auf Will Provision gesetzt, wenn die WHFB Registrierung bei der nächsten Anmeldung des Benutzers als Post-Logon-Aufgabe gestartet werden soll.

Azure Portal

Wir können ebenfalls den Status der Systeme im Azure Portal prüfen.

Hierfür öffnet den Link https://portal.azure.com im Browser und gebt die benötigten Zugangsdaten ein.

Klickt auf Azure Active Directory.

Im darauf folgenden Fenster klickt auf Devices.

Hier sieht man alle im Azure AD hinterlegten Systeme. Sowohl Azure AD Joined, Azure AD Registered und Hybrid Azure AD Joined.

Systeme im Pending State sind zwar über Azure AD Connect ins Azure AD synchronisiert worden, aber das System selber hat sich nicht im Azure AD gemeldet.

Ablauf eines Hybrid Azure AD Join

Phase	Erklärung
A	Der Benutzer meldet sich an einem Domain Joined Windows System mit Domänen Anmeldedaten an. Dies kann ein Benutzername und ein Passwort oder eine Smartcard-Authentifizierung sein. Die Benutzeranmeldung löst den Task Automatic Device Join aus. Hinweis: Der Task Automatic Device Join wird beim Domain Join ausgelöst und jede Stunde wiederholt. Sie ist nicht allein von der Benutzeranmeldung abhängig.
B	Der Task fragt Active Directory mithilfe des LDAP-Protokolls nach dem Attribut keywords für den SCP ab, der in der Configuration Partition der Active Directory gespeichert ist (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,…). Der im Attribut keywords zurückgegebene Wert bestimmt, ob die Geräteregistrierung an den Azure Device Registration Service (ADRS) oder an den unternehmenseigenen Geräteregistrierungsdienst, der vor Ort gehostet wird, geleitet wird. Hinweis (Nicht im Bild): Wenn, zur besseren Kontrolle, der SCP geleert wurde, holt sich der Task als Fallback die benötigten Informationen aus der Registry (siehe unten), wenn diese dort vorhanden sind.
C	Für die verwaltete Umgebung erstellt der Task eine erste Authentifizierungsberechtigung in Form eines selbstsignierten Zertifikats. Der Task schreibt das Zertifikat mithilfe von LDAP in das userCertificate Attribut auf dem Computerobjekt in Active Directory.
D	Der Computer kann sich nicht bei Azure DRS authentifizieren, bis ein Geräteobjekt, das den Computer repräsentiert und das Zertifikat im Attribut userCertificate enthält, in Azure Active Directory erstellt wird. Azure AD Connect erkennt eine Attributänderung. Beim nächsten Synchronisierungszyklus sendet Azure AD Connect das userCertificate, die Objekt GUID und die Computer SID an Azure DRS. Azure DRS verwendet die Attributinformationen, um ein Geräteobjekt in Azure Active Directory zu erstellen.
E	Der Task Automatic Device Join wird bei jeder Benutzeranmeldung oder stündlich ausgelöst und versucht, den Computer mit dem entsprechenden privaten Schlüssel des öffentlichen Schlüssels im Attribut userCertificate bei Azure Active Directory zu authentifizieren. Azure Active Directory authentifiziert den Computer und gibt ein ID Token an den Computer aus.
F	Der Task erzeugt bevorzugt ein TPM gebundenes RSA-2048-Bit-Schlüsselpaar, bekannt als Device Key (dkpub/dkpriv). Die Anwendung erstellt eine Zertifikatsanforderung mit dkpub und dem öffentlichen Schlüssel und signiert die Zertifikatsanforderung mit dkpriv. Als nächstes leitet die Anwendung ein zweites Schlüsselpaar aus dem Speicherstammschlüssel des TPMs ab. Dies ist der Transport Key (tkpub/tkpriv).
G	Der Task sendet eine Device Registration an Azure DRS, die das ID Token, die Zertifikatsanforderung, tkpub und die Bescheinigungsdaten enthält. Azure DRS validiert das ID Token, erstellt eine Device ID und erstellt ein Zertifikat basierend auf der enthaltenen Zertifikatsanforderung. Azure DRS aktualisiert dann das Geräteobjekt in Azure Active Directory und sendet die Device ID und das Gerätezertifikat an den Client.
H	Die Device Registration wird durch den Erhalt der Device ID und des Gerätezertifikats von Azure DRS abgeschlossen. Die Device ID wird für zukünftige Referenzen gespeichert (einsehbar über dsregcmd.exe /status), und das Gerätezertifikat wird im persönlichen Speicher des Computers installiert. Wenn die Device Registration abgeschlossen ist, wird der Task beendet.

Regulierung des Hybrid Azure AD Join

Der über Azure AD Connect konfigurierte SCP wird von allen Windows Geräten ausgewertet und führt dazu, dass zum Beispiel alle Windows 10 Geräte automatisch einen Hybrid Azure AD Join durchführen. Die Windows Server (2016 / 2019) Betriebssysteme versuchen dies erst, nach erfolgreicher Synchronisierung der Computer Objekte, über Azure AD Connect, in die Azure AD.

Ausgelöst wird der Hybrid Azure AD Join auf dem lokalen Gerät durch einen Scheduled Task, welcher beim Starten von Windows und bei der Anmeldung eines Benutzers auf dem System ausgelöst wird. 

Scheduled Tasks\Microsoft\Windows\Workplace Join\Automatic-Device-Join  

Bei der Ausführung des Tasks werden die benötigten Informationen entweder über den SCP in der Configuration Partition der lokalen AD oder über die lokale Registry des Clients (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD) gesucht. Mit den gefunden Information (TenantID / TenantName) prüft das System nun, ob die Angaben valide sind. 

Automatischer Hybrid Azure AD Join 

Hierbei wird jedes Computer Konto das das Selbstsignierte Zertifikat erstellt und in AD Attribut userCertificate abgelegt hat automatisch nach Azure AD synchronisiert. Dies geschieht automatisch, wenn der Trigger des Tasks ausgelöst wird (Anmeldung oder Neustart) durch Abrufen der benötigten Informationen beim SCP.

Kontrollierter Hybrid Azure AD Join

Will man diesen Prozess kontrollieren, so kann man den SCP leeren und die benötigten Einstellung auf anderem Weg an die Windows Geräte verteilen.

Der gelöschte SCP enthielt Informationen über den Ziel Tenant, mit dem sich der Client verbinden sollte. Diese Informationen können gezielt zum Beispiel per GPO oder WEM auf dem Zielsystem hinterlegt werden, indem die folgenden Registry Keys gesetzt werden (Die Keys CDJ und AAD müssen neu erstellt werden):

Des weiteren kann mit der folgenden GPO Einstellung der automatische Workplace Join bei Windows 10 Geräten auch ohne Löschen des SCP unterbunden werden.

Zu finden ist diese Einstellung unter Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration.

Besonderheiten bei Non-Persistent Maschinen

Beachtet das mit Hybrid Azure AD Join eine weitere Unique ID für die Systeme erstellt wird, ähnlich der SID in der lokalen Active Directory. Die DeviceID ist ebenfalls mit dsregcmd /status ablesbar und muss für alle Systeme Unique sein.

Wenn wir die Verteilung von Non-Persistent Workern über ein Golden Image durchführen, muss der Golden Master entweder bezüglich Hybrid Azure AD Join ausgeschlossen sein oder bevor das Image versiegelt und verteilt wird muss der Join aufgelöst werden , über dsregcmd /debug /leave.

Wenn dies nicht gemacht wird, verteilt sich die Unique ID des Golden Masters über alle Worker, die aus ihm entstehen. Daraus folgt, das die Non-Persistent Worker erhebliche Probleme bei der Kommunikation mit der Microsoft Cloud haben (SSO Probleme usw.).

Wer dies nicht im Hinterkopf behalten möchte, kann hierfür natürlich auch BIS-F in seiner aktuellsten Version nutzen. In dieser kann man diesen Schritt konfigurieren und das Script erkennt automatisch, das der Golden Master Hybrid Azure AD Joined ist und führt daraufhin ein Leave durch.

Nach dem Start der Non-Persistenten Worker wird durch BIS-F wiederum ein Join angetriggert.

Troubleshooting

Event Logs

Bei der Fehlersuche zu einem Hybrid Azure AD Join liefern die Event Logs (Microsoft > Windows > User Device Registration > Admin) eine Menge Informationen.

Event ID 306

Der Inhalt von Event ID 306 besagt Automatic registration Succeeded. Dies ist die Abschlussmeldung für einen erfolgreichen Hybrid Azure AD Join.

Event ID 105

Event ID 105 sagt The complete join response was successful. Dies bedeutet das der Join finalisiert wurde.

Event ID 111

Event ID 111 hat den Inhalt The registration status has been successfully flushed to disk, also die Registrierung wurde erfolgreich auf dem System gespeichert.

Event ID 106

Event ID 106 hat den Inhalt The post join tasks for the AAD Authentication Package completed successfully. Das System führt nach dem Join noch einige Arbeiten aus (Senden von Geräteinformationen usw.), diese sind nun abgeschlossen.

Event ID 104

Event ID 104 hat den Inhalt The get join response operation callback was successful. Die Join Response war erfolgreich und die Antwort war das benötigte Certificate.

Event ID 103

Der Inhalt von Event ID 103 besagt The join request was successfully sent to server. Dies bedeutet das das System seine Join Anforderung versendet hat an Azure AD.

Event ID 102

Der Inhalt von Event ID 102 besagt The initialization of the join request was successful. Hier zu finden ist der Tenant Name. Wenn diese Information nicht stimmt oder leer ist, stimmt etwas mit dem SCP oder den hinzugefügten Registry Keys nicht.

Event ID 101

Event ID 101 hat den Inhalt The discovery operation callback was successful. Das bedeutet, dass das System erfolgreich mit Azure AD Kontakt aufgenommen hat und keine Netzwerk Probleme bestehen.

Event ID 100

Event ID 100 hat den Inhalt The discovery request send operation was successful. In diesem Schritt sendet der Computer eine Anfrage an Azure AD. Wenn in der Ereignisanzeige Fehler auftauchen, die Sekunden nach diesem Ereignis auftreten, bedeutet dies, dass der Computer Probleme beim Senden des Discovery Request hat. Dies deutet in den meisten Fällen auf Netzwerkprobleme hin.

Event ID 212

Event ID 212 hat den Inhalt Error happened while accessing registry. Dieser Fehler tritt auf, wenn die Registrierungswerte nicht konfiguriert sind und der SCP geleert ist. Wenn der SCP in Active Directory verwendet wird, um die Tenant Informationen zu veröffentlichen, erscheint ebenfalls dieser Fehler. Aber in diesem Fall gibt es keinen Grund zur Sorge und er kann ignoriert werden!

Event ID 259

Event ID 259 mit dem Inhalt The task … was successfully disabled, weißt nur daraufhin das der Device-Sync Task deaktiviert wurde.

Event ID 204

Event ID 204 mit dem Inhalt The get join response operation callback failed with exit code, weißt daraufhin das das System nicht in Azure AD vorhanden ist (siehe auch Client Error Code 0x801c03f2).

Event ID 304

Event ID 304 mit dem Inhalt Automatic registration failed at join phase, weißt ebenfalls daraufhin das das System nicht in Azure AD vorhanden ist (siehe auch Client Error Code 0x801c03f2). Event ID 204 und 304 kommen fast immer gemeinsam.

Event ID 331

Event ID 331 mit dem Inhalt Automatic device join pre-check tasks completed, kann sowohl positiv als auch negativ sein. Hierfür muss man betrachten, was das preCheckResult aussagt (siehe auch Client Error Code 0x1).

Hier eine positive Meldung vor dem eigentlichen Join.

Errors

Um die Verbindung zu debuggen hilft das Event Log und der Befehl dsregcmd /status. Hier ein paar Beispiele für häufige Fehler.

Client Error Code 0x801c03f2

Der Error Code 0x801c03f2 in dsregcmd /status bedeutet, dass das System das Hybrid Azure AD Joined werden soll, sich nicht in Azure AD befindet.

Dies kann ebenfalls im Event Log verifiziert werden. Hier sind Event ID 204 und 304 unter User Device Registration zu finden.

Überprüft das Azure AD Portal unter Devices, ob das System dort zu finden ist.

Dies bedeutet das die AD Synchronisierung im Azure AD Connect angepasst werden muss, da dort entweder eine OU- oder Attribut-Filterung eingerichtet ist, die das System ausschließt oder der Objekt Typ Device ist nicht eingeschlossen.

Startet Synchronisation Service um dies zu überprüfen und zu editieren.

Klickt auf Connectors und dort mit der rechten Maustaste auf die lokale Domäne. Im folgenden Fenster auf Properties.

In den Properties prüft unter Select Object Types, was synchronisiert wird.

Wie hier zu sehen ist device nicht markiert und daher werden die Systeme nicht mit synchronisiert. Korrigiert dies durch die Aktivierung von device.

Prüft ebenfalls die OU-Filterung unter Configure Directory Partitions.

Klickt auf Containers … und gebt im folgenden Fenster Administrative Anmeldedaten ein.

Im folgenden Fenster kann die OU-Filterung editiert werden. Bestätigt die Anpassung mit Klick auf OK.

Nun startet die Synchronisierung manuell oder wartet 30 Minuten.

In der Zusammenfassung klickt auf den manuell gestarteten Connector und in der Export Statistic auf Add.

Im folgenden Fenster klickt auf Properties.

Hier ersichtlich, das das System VDI1 hinzugefügt wurde.

Im Azure Portal ist dies nun auch zu finden.

Wenn das System dann immer noch nicht im Azure AD erscheint, ist noch eine Attribut-Filterung aktiv. Um dies zu prüfen klickt auf Synchronisation Rules Editor.

Klickt im folgenden Fenster doppelt auf In from AD – Computers Filtered, um denn Device Filter zu überprüfen. Die Regel kann natürlich auch einen anderen Namen haben. Überprüft alle Regeln mit dem Connected System Object Type (computer) und Metaverse Object Type (device).

Überprüft die Allgemeinen Einstellungen bezüglich Connected System Object Type (computer) und Metaverse Object Type (device). Klickt danach auf Scoping filter.

Hier ist nun ersichtlich, das nur Systeme synchronisiert werden, die im extensionAttribute12 den Eintrag Sync2O365 haben.

Um dies aufzulösen bestückt die entsprechenden Systeme mit diesem Attribut manuell oder per PowerShell.

Oder deaktiviert / löscht die Synchronization Rule.

Über dsregcmd /status kann der Status nun auf dem System auch erfolgreich abgefragt werden.

Client Error Code 0x1

Der Error Code 0x1 und die angezeigte Error Phase in dsregcmd /status bedeutet, dass das System schon im Pre-Check hängen geblieben ist. Es ist ebenfalls ersichtlich das der Token acquisition Test Skipped Status hat.

Dies kann ebenfalls im Event Log verifiziert werden. Hier ist Event ID 331 unter User Device Registration zu finden. Event ID 331 ist aber eine reine Information und impliziert nicht direkt einen Fehler. In unserem Event ID 331 ist aber auch der resultCode: 0x1 zu finden und es sagt als preCheckResult: DoNotJoin.

System ist aber in Azure AD vorhanden, hat aber einen Pending Status.

Bei dieser Kombination an Fehlern, prüft ob das System die benötigten Certificate im Computer Kontext Personal gespeichert hat.

Öffnet die mmc und fügt das Snap-in Certificate (Local Computer) hinzu.

Prüft die vorhandenen Zertifikate unter Personal > Certificates.

Leider sind die benötigten Zertifikate nicht vorhanden. Man kann den Join Prozess nochmals über den Geplanten Task starten, in dem man sich neu an der Maschine anmeldet oder mit dem Befehl:

Der angesprochene Geplante Task Automatic-Device-Join ist unter Microsoft > Windows > Workplace Join zu finden.

Eine erneute Anmeldung reicht ebenfalls, da ein Trigger At log on of any user eingerichtet ist.

Zertifikate sind nun auf dem System eingebunden.

Azure AD Join ist nun auch erfolgt. Zu sehen über dsregcmd /status und im Azure Portal.

AzureAdPrt: NO

Wenn AzureAdPrt auf NO steht, bedeutet dies das das System keinen PRT zugeordnet bekommen hat.

Wir prüfen das System ebenfalls im Azure AD unter Devices. Es befindet sich im Pending Status in der Azure AD.

Um dies zu lösen, muss das System nochmals neu gejoined werden. Hierfür starten wir eine Administrative CMD /PowerShell.

Hier geben wir den Befehl dsregcmd /debug /leave ein, um das System aus der Azure AD zu entfernen.

Überprüfung der Azure AD unter Devices, das das System nicht mehr vorhanden ist und Neustart des Betroffenen Systems, damit der Trigger für den erneuten join gestartet wird.

Oder manuellen join durch den Befehl dsregcmd /debug /join.

Danach sollte ein PRT vorhanden sein.

Und das System auch nicht mehr auf Pending stehen im Azure AD.

$ hinter Computer Namen im Azure Portal

Das „Problem“ löst sich nach wenigen Stunden von selbst. Dies impliziert einfach das ein System lokal umbenannt wurde.

Nach wenigen Stunden ist im Azure Portal der neue Name zu sehen.

Hybrid Azure AD Join und SAML Auth

Wenn man eine Verbindung über eine SAML Auth aufbaut (z.B. über Citrix ADC), kann Hybrid Azure AD Join den Benutzer nicht erkennen und daher keinen PRT erzeugen.

Zu erkennen ist dies am Punkt IsUserAzureAD, dieser steht dann auf NO. SSO funktioniert dann auch nicht sauber.