Warum sollte ein Windows Server 2019 VDI Hybrid Azure AD joined sein

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.
Hybrid Azure AD Join

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).

Sign in to set up Office

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

No Shared Activation Token

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.

Error code: CAA50021 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.

Error Code 80070003 Microsoft Teams

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

Error Code c00ce584 Microsoft Teams

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.

OneDrive for Business No SSO

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.

Service connection points

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.

Azure AD Devices

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.

userCertificate

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.

Certificates Device

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.

Automatic registration Succeeded Event ID 306 User Device Registration

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.

Azure AD Connect
Azure AD Connect Splash Screen

Klickt im Welcome Screen auf Configure.

Welcome to Azure AD Connect 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.

Additional tasks Configure device options

Danach klickt auf der Overview Seite auf Next.

Overview Hybrid Azure AD join Device writeback

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

Connect to Azure AD

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

Connecting to Microsoft Online to verify credentials

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

Device Options Configure Hybrid Azure AD join

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.

Device operating systems Windows 10 or later domain-joined devices supported windows downlevel domain-joined devices

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

SCP configuration Forest

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

SCP configuration Enterprise Admin Authentication Service Azure Active Directory

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

Windows Security Enterprise Administrator On-Prem

Bestätigt die Konfiguration mit einem Klick auf Next.

SCP configuration service connection point

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

Ready to configure

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

Ready to configure Configure the SCP for device registration

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

Configuring Azure AD Connect synchronization service

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

Configuration complete

Ü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.

ADSI Edit

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

ADSI Edit Connect to...

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

Select a well known Naming Context Configuration

Klickt anschließend auf OK.

Configuration LDAP://DC.domain.local/configuration

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.

Configuration CN=Configuration,DC=  CN=Services CN=Device Registration Configuration

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.

Properties Attribute Editor objectGUID 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.

device ID
device ID

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

Get-msoldevice -deviceId

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.

Event Viewer Applications and Service Logs > Microsoft > Windows > User Device Registration > Admin

Event Viewer Applications and Service Logs > Microsoft > Windows > User Device Registration > Admin

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

Event 306 User Device Registration Automatic registration Succeeded
Command Prompt / PowerShell

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

Command Prompt PowerShell

Gebt nun den folgenden Befehl ein.

dsregcmd /status Device State Device Details
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.

AzureAdJoinedEnterpriseJoinedDomainJoinedDevice State
YESNONOAzure AD Joined
NONOYESDomain Joined
YESNOYESHybrid Azure AD Joined
NOYESYESOn-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.

dsregcmd /status Tenant Details User State SSO State
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.

dsregcmd /status Diagnostic Data Pre-Join Diagnostics
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.

dsregcmd /status Diagnostic Data  Post-Join Diagnostics

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.

dsregcmd /status NGC prerequisite check
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.

Azure Portal Logon Mask

Klickt auf Azure Active Directory.

Azure Active Directory

Im darauf folgenden Fenster klickt auf Devices.

Azure Active Directory Devices

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

Azure AD Joined Azure AD Registered 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

PhaseErklärung
ADer 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.
BDer 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.
CFü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.
DDer 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.
EDer 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.
FDer 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).
GDer 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.
HDie 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  

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. 

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

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.

Hybrid Azure AD Join with 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.

Hybrid Azure AD Join without SCP

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):

TenantName TenantID CDJ AAD
TenantId TenantName

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.

Register domain joined computers as devices

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.

Device ID

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.

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.

BIS-F Checking DSRegcmd State
dsregcmd /status bis-f

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

BIS-F Personalization

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.

Microsoft Windows User Device Registration Admin

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 306 Automatic registration Succeeded

Event ID 105

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

The complete join response was successful Event ID 105

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 111 The registration status has been successfully flushed to disk

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 106 The post join tasks for the AAD Authentication Package completed successfully

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 104 The get join response operation callback was successful

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 103 The join request was successfully sent to server

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 102 The initialization of the join request was successful

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 101 The discovery operation callback was successful

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 100 The discovery request send operation was successful

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 212 Error happened while accessing registry

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.

The task ... was successfully disabled Event ID 259
Task Device Sync disabled

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).

The get join response operation callback failed with exit code Event ID 204

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 304 Automatic registration failed at join phase

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).

Event ID 331 Automatic device join pre-check tasks completed

Hier eine positive Meldung vor dem eigentlichen Join.

Event ID 331 Automatic device join pre-check tasks completed

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.

Client Error Code 0x801c03f2

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

User Device Registration Event ID 204
User Device Registration Event ID 304

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

Azure Portal Device

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.

Synchronization Service
Azure Active Directory Sync Services

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

Connectors Properties

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

Connectors Select Object Types

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

Connectors Select Object Types device

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

Configure Directory Partitions

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

Containers Credentials

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

OU Filter Select Containers

Nun startet die Synchronisierung manuell oder wartet 30 Minuten.

Run Connector

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

Export Statistic

Im folgenden Fenster klickt auf Properties.

Export Statistic Properties

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

Connector Space Object Properties

Im Azure Portal ist dies nun auch zu finden.

Azure Portal Device

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.

Synchronization 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).

Synchronization Rules Editor Overview

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

Connected System Object Type Metaverse Object Type

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

Scoping filter

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

Oder deaktiviert / löscht die Synchronization Rule.

Synchronization Rule disable

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

dsregcmd /status

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.

Client Error Code 0x1 Error Phase pre-check

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.

Event ID 331 User Device Registration resultCode: 0x1 preCheckResult: DoNotJoin

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

Azure AD Portal Device Pending

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.

mmc certificate local computer

Prüft die vorhandenen Zertifikate unter Personal > Certificates.

mmc certificate local computer personal

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:

dsregcmd /join /debug

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

Scheduled Task Automatic-Device-Join Microsoft > Windows > Workplace Join

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

Scheduled Task Automatic-Device-Join Microsoft > Windows > Workplace Join Trigger

Zertifikate sind nun auf dem System eingebunden.

mmc certificate local computer personal

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

dsregcmd /status AzureAdJoined YES DomainJoined YES
Azure Portal Device

AzureAdPrt: NO

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

AzureAdPrt: NO

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

Azure AD Device Pending

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.

dsregcmd /debug /leave

Ü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.

dsregcmd /debug /join

Danach sollte ein PRT vorhanden sein.

AzureAdPrt: YES

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

Hybrid Azure AD Joined Device

$ 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.

$ behind the name

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

Resolve $ behind the name

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

* I consent to having this website store my submitted information so they can respond to my inquiry.