AzureAD Join

Ein Mitarbeiter bekommt ein neues Notebook und installiert es "selbst". Windows 10 fragt nach Benutzername/Mailadresse und Kennwort und schon war der PC in AzureAD angemeldet. So hatte ich notgedrungen meinen ersten Kontakt zum AzureAD mit Clients, die nicht mehr in der lokalen Domäne Mitglied waren sondern nur noch im Azure AD.

Vision

Wenn es nach Microsoft geht, dann könnte das lokale Active Directory immer weniger Bedeutung haben. Speziell wenn Firmen kleiner sind und der Betrieb eines lokalen Active Directory aus mindestens zwei Domaincontrollern und einer ADSync-Instanz samt Administrator einfach zu teuer ist. Wenn sie aber ihre Mails, Chats, Konferenzen, Dateien schon in Office 365 betreiben und die Endgeräte per Intune aus der Cloud verwalten und dann noch ihre Buchhaltung in einer Cloud (Navision, SAP, LexWare) führen, dann gibt es lokal eigentlich nur noch den Internet-Router, der zugleich DHCP-Server ist, ein Drucker im LAN, den ihr PC auch alleine findet und vielleicht noch die ein oder andere Branchenlösung, die aber meist auch ohne Active Directory genutzt werden kann.

Dann macht es schon Sinn, dass Clients sich direkt in der Cloud anmelden, von dort per Endpoint Management/Intune inventarisiert und mit Richtlinien versehen werden und für "Conditional Access" bekannt sind.

Unter bestimmten Umgebungen können Clients sogar auch lokale Ressourcen zugreifen, ohne dass der PC "Mitglied der lokalen Domäne" ist. Der Client muss nur die Domain Controller, z.B. per VPN oder weil Sie im LAN sind, erreichen können.

Vorbemerkung

Als ich das erste Mal mit dem Problem konfrontiert wurde, dachte ich einfach, dass der PC im AzureAD sei. Nach einigen Experimenten habe ich nun verschiedene Client-Konfigurationen ermittelt, die vorliegen können. Ein PC kann sich in drei Konfigurationen befinden und entsprechend kann auch der Benutzer unterschiedlich verbunden sind. Von den vielen Variationen habe ich drei Konstellationen näher betrachtet:

  • PC in der Domäne mit Domain User
    Diese Konstellation leben und nutzen wir schon viele Jahrzehnte seit es Windows Domänen gibt.
  • PC in AzureAD mit AzureAD User
    Diese Konstellation ist nun komplett neu und durchaus interessant für Firmen, die z.B.: gar kein lokales Active Directory haben (wollen)
  • PC in Workgroup mit lokalen User, der aber eine „Verknüpfung“ mit einem AzureAD Konto haben kann
    Diese Konstellation ist für den BYOD-Ansatz interessant, bei der ein Anwender zuhause mit "seinem" lokalen Konto arbeitet aber zumindest eine Verknüpfung mit dem AzureAD-Konto herstellt. Allerdings muss sich die Firma natürlich fragen lassen, ob das geduldet wird.

Natürlich gibt es noch viele andere Varianten. So kann man sich auf einem Domain-Joined PC auch als lokaler User anmelden und ein AzureAD-Konto verknüpfen aber im Geschäftsumfeld sind diese andere Fälle aus meiner Sicht nicht relevant. Wenn ich dann in meinem Azure Portal die Gerte anschaue, dann finde ich hier mehrere "JoinType":

Eine kurze Interpretation:

Joint Type

OS

Interpretation

<leer>

 

Das Gerät ist der Cloud bekannt aber ist kein klassisches "Computerkonto". Meist sind die Geräte zu alt, z.B. Windows 7 oder ältere Android-Geräte, die keinen weiteren Status haben. ADSync ignoriert das Gerät und im lokalen Active Directory sind diese Geräte nicht bekannt.

Hybrid Azure AD Joined

Windows 10/8/7
Server 2008+

Diesen Status sollten alle Computerkonten haben, die im lokalen Active Directory aufgenommen und durch ADSync auch in die Cloud repliziert wurden. Das AzureAD "kennt" diese Clients über diesen Weg.

Azure AD registered

Windows 10, MacOS, iOS, Android

Das Gerät ist der Cloud bekannt und hat sogar ein "Computerkonto" bekommen. Aber es ist nur "registriert" aber nicht "joined". Dies sind in der Regel private Windows 10 Clients, die von Anwendern nur genutzt werden. iOS/Android nutzen das Company Portal oder die Authentiator App. MacOS das Company Portal zum Provisioning.

Azure AD Joined

Windows 10 (nicht Home)

Das sind Geräte, die quasi "nur" Mitglied im AzureAD sind aber nicht in die lokale Active Directory Domäne aufgenommen wurden. ADSync kann mit "Device Writeback" diese Objekte auch in das lokale AD übertragen, so dass die Domaincontroller die Anfragen besser einordnen können. Sie sind aber nicht Mitglied des lokalen AD und bekommen von dort auch keine Gruppenrichtlinien etc.

AzureAD Join-Berechtigung

Vielleicht kennen Sie noch die Funktion, dass ein normaler Windows Domain Benutzer bis zu 10 Computer in ein lokales Active Directory aufnehmen kann, wenn Sie dies nicht per Gruppenrichtlinie abweichend einstellen.

Diese Funktion gibt es auch beim AzureAD, nur dass hier ein Anwender bis zu 20 Geräte einfach so addieren darf. Diese Funktion können sie natürlich ebenfalls über das Azure Portal steuern. In diesem Tenant wurde das "All" schon auf "Selected" umgestellt und dann 5 Benutzer bestimmt, die Computer in das AzureAD aufnehmen dürfen.


https://portal.azure.com/#blade/Microsoft_AAD_Devices/DevicesMenuBlade/DeviceSettings/menuId/

Sie können hier auch die Anzahl "20" umstellen.

AzureAD Join mit Windows 10 Setup

Wenn Sie bislang sich noch nicht um AzureAD-Join gekümmert haben, dann könnte es in ihrem Verzeichnis schon den ein oder anderen Client geben, denn die Aufnahme erfolgt mit Windows 10 sehr einfach. Wenn Sie einen nagelneuer PC das erste Mal einschalten, dann erfragt Windows ihre "Mailadresse". Was vielen hier nicht bewusst ist, dass Windows diese Information nutzt, um ein passendes AzureAD/Microsoft-ID-Benutzer-Konto zu suchen und dann das Kennwort abzufragen. Es wird dem Anwender sehr schwer gemacht, überhaupt noch ein "lokales Konto" anzulegen.

Sie sollten auf jeden Fall dafür sorgen, dass die verwendete Domain nicht für AzureAD und Microsoft-Konten verwendet wird. Neue Microsoft-Konten können nicht mehr mit einer Domäne angelegt werden, die auch schon als AzureAD-Domain registriert ist. Allerdings gilt das nicht für Bestandskonten.

Wenn die vom Anwender eingegebene Benutzer-Adresse und Kennwort zu einem AzureAD-Konto passt und der Benutzer das Recht zur Aufnahme ins AzureAD hat, dann wird der PC zu einem "AzureAD-Join"-PC in ihrem Tenant.

Ohne Anpassung der Konfiguration müssen Sie als Firma damit rechnen, dass so auch private PCs in ihrem Tenant auftauchen und theoretisch auch Windows Enterprise, Office Produkte etc. bekommen.

AzureAD Join manuell

Über die Windows Systemsteuerung können Sie einen Computer auch nachträglich noch ins AzureAD aufnehmen. Das ist für "Einzelarbeitsplätze" durchaus interessant, wenn die Clients nicht Mitglied der Active Directory Domäne sind.

Wenn ihr Computer bereits Mitglied eines lokale Active Directory ist, dann sollte ADSync die Identität schon ins AzureAD übertragen haben und der Computer als "Hybrid AzurAD Joined" aufgeführt werden.

Über die Systemsteuerung könnten sie die Verbindung zum AzureAD herstellen.

Das Beispiel zeigt noch einen Test-PC mit einer Domäne, die eine Authentifizierung per ADFS erfordert.

Nach erfolgter Anmeldung und Registrierung kann der PC über Office 365 verwaltet werden.

Der Administrator kann das Konto dann im AzureAD-Portal unter Devices finden oder im Intune-Portal.

AzureAD vs. lokalem AD

Ein direkter Wechsel eines Computers aus dem Status "Azure AD Joined" in den Status "Hybrid AzureAD Joined" ist nicht möglich (stand Dez 2020). Das kann passieren, wen ein Mitarbeiter einen PC zuhause installiert oder erstmals einrichtet und damit "nur" eine Registrierung als "AzureAD Joined" vornimmt. Wenn er dann wieder in der Firma ist, kann er die meisten "On-Premises"-Systeme durchaus erreichen aber er hat z.B. keine Gruppenrichtlinien. Damit dürften ihm einige essentielle Einstellungen fehlen. Wenn der Mitarbeiter oder Administrator dann den PC mal eben schnell über die Eigenschaften des Computers "in die Domäne" aufnehmen will, dann sehen Sie folgenden Fehler:

Der richtige Weg geht auch hier über die Konto-Einstellungen. Allerdings müssen sie hier zuerst das "Geschäfts- oder Schulkonto" trennen:

Danach ist ein Neustart erforderlich nachdem Sie dann den Computer in die Domäne aufnehmen können. Als Domain Computer sollte ADSync das Konto in einigen Minuten auch in die Cloud repliziert haben, so dass das Konto dann auch in der Cloud den Status "Hybrid AzureAD Joined" hat.

AzureAD-Connect

Allerdings benötigt AzureAD-Connect dazu noch ein paar Einstellungen. Wenn Sie den Assistenten durchführen und die Meldungen lesen, dann sollte ihnen folgende Meldung aufgefallen sein:

ADSync benötigt noch etwas Hilfe, wenn Sie Geräte synchronisieren wollen. Wenn Sie Geräte ins AzureAD replizieren, dann bekommen Sie dort auch eine DeviceID und andere Werte, die ADSync auch an die Computerobjekte im lokalen Active Directory anfügen muss.

Lokaler AD Zugriff und AD-Join

Es ist kein Geheimnis, dass Microsoft die Zukunft in der Cloud sieht und dazu gehören auch Clients, die über die Cloud verwaltet werden. Mit der passenden Konfiguration können sogar AzureAD-Joined Clients auf Dienste im lokalen Active Directory zugreifen. Der Client ist per "Device WriteBack" ja auch dem lokalen Domain Controller bekannt und wenn das Endgerät eine direkte Verbindung zum Domaincontroller aufbauen kann, dann kann er sich sogar ein Kerberos-Ticket für den Anwender holen und auf On-Premises Windows Dateiserver und andere Dienste zugreifen.

Sollte ihnen das aber nicht ausreichen und muss der Client auch im lokalen Active Directory aufgenommen werden, dann ist eine Verbindung des Clients zum Domaincontroller erforderlich. Aktuell ist es nicht möglich, dass ein Gerät sich im AzureAD registriert und über ADSync dann ein vollwertiges Computerkonto im lokalen Active Directory bekommt. ADSync legt nur ein Device-Konto an aber der Client ist nicht Mitglied der Domäne.

Aber auch für diese Anforderung gibt es schon lange nutzbare Wege. Allerdings kann hier Autopilot und das Management aus der Cloud unterstützen.

Wenn der Computer eh in ihrem Firmennetzwerk ist, dann ist die Aufnahme in die Domäne nicht besonders schwer.

Wenn sich der PC aber nicht im Firmennetzwerk befindet, dann muss quasi eine transparente Netzwerkverbindung, z.B. per VPN, aufgebaut werden.

Autopilot Device Rename und Hybrid Join

Wenn Sie Computer per Autopilot installieren, dann stellt sich immer die Frage nach dem Computernamen. Bei Autopilot kann ich nur ein Prefix und zwei Platzhalter eingeben.

Damit bekommen die neuen PCs natürlich eine nicht immer dem eigenen Namenskonzept entsprechenden Namen. Ein Rename ist von Microsoft nicht wirklich vorgesehen, wenn es ein Windows Computer ist.


Rename a device in Intune https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-rename

Allerdings ist das wohl nur die halbe Wahrheit.  Man kann schon einen Computer im lokalen AD umbenennen und dies hat Michael Niehaus (https://www.linkedin.com/in/mniehaus/) im Mail 2020 beschrieben. Damals war er noch "Product management for Windows Autopilot and Microsoft Endpoint Manager". Seine Beschreibung ist umfangreich, weil er mit Intune ein PowerShell-Skripte verteilt, welches einen geplanten Task einstellt und das Computerkonto vorab auch die Rechte zum Umbenennen des AD-Objekts eingeräumt bekommt. Zudem hat er für sich eine Azure-Function programmiert, um Rechnernamen zu vergeben. Da wären aber auch Optionen denkbar, z.B. indem der Computer den neuen Namen aus einem Feld des alten Computerobjekts einfach ausliest.

Azure AD Domain Services

Verwechseln sie das lokale Active Directory oder das AzureAD aber nicht mit einem "Managed Active Directory" in der Cloud. Auch dies ist eine Option

AzureAD und DNS Updates

Wenn ihre Clients nicht mehr "Domain-Mitglied" sind, dann gibt es auch kein Computerkonto im lokalen Active Directory. Sie schalten den Computer im LAN an, er bekommt per DHCP eine IP-Adresse aber kann sich erst einmal nicht selbst im DNS-Server eintragen. Er kann sich nämlich gar nicht am lokalen AD authentifizieren. Vielleicht wollten oder brauchen Sie aber diese Funktion um z.B. per Reverse-DNS zu einer IP-Adresse auch den aktuellen Computernamen aufzulösen. Das kann ja durchaus wichtig sein, wenn Sie Protokolldateien auswerten und nur IP-Adressen haben.

Damit dies funktioniert, sollten sie zuerst sicherstellen, dass der Client, der ja schon zu ihrem Netzwerk gehört, den richtigen "DNS-Suffix" hat. Ich habe viele "AzureAD-Joined" Devices gesehen, die nur einen Hostnamen aber keine DNS-Domain hatte. Die DNS-Domain wird normalerweise beim AD-Join auf die AD-Domäne gesetzt. Die AzureAD-Joined Computer haben diesen Prozess aber nicht durchlaufen. Damit meine ich nicht die DNS-Suffix-Liste, die per DHCP oder z.B. Intune gesetzt werden kann. Die ist nur für die Suche des Clients nach Namen relevant.

Da der Client aber auch mit dem gewünschten FQDN seinen Eintrag nicht im DNS-Server ändern kann, bleiben ihnen nur zwei Optionen:

  • Unsichere Zonen-Updates erlauben
    Sie könnten die DNS-Zone auf ihrem DNS-Server so einrichten, dass jeder einen Namen addieren und ändern kann. Ratsam ist das natürlich nicht, denn dann könnte auch ein Angreifer z.B. Hostnamen wie "www" oder "intranet" etc. registrieren und Client dazu verleiten, diese Adressen als vertrauenswürdig anzusehen. Microsoft hat zwar die "_msdsc.<domain"-Zone seit Windows 2003 schon ausgelagert, so dass Sie diese Zone weiter auf "Secure Update Only" betreiben können aber es bleibt ein Risiko.
  • DHCP übernimmt die Registrierung
    Es ist aus meiner Sicht daher besser, dass der DHCP-Server die Aufgabe übernimmt und den Namen im DNS für den Client verwaltet. Das ist aber auch nicht perfekt, da der Client auch hier mit seinem DHCP-Request über die Option 81 seinen FQDN mitliefert. Allerdings kann der DHCP-Server nur Einträge ändern, die er selbst angelegt hat. Die DNS-Zone ist aber weiter auf "Secure Updates" gestellt, so dass von Domainmitgliedern oder vom Administrator manuell gepflegte Einträge nicht überschrieben werden können. Das reduziert das Risiko dann schon sehr stark.
    Es verhindert aber nicht, dass ein solcher Client per DHCP den Eintrag eines anderen Client ohne weitere Authentifizierung überschreibt.

Beide Verfahren sind also weniger sicher als ein authentifizierter Zugriff eines Domainmitglieds aber wenn ein Client kein Mitglied der Domain ist, gibt es keine andere einfache Option.

AzureAD und Netzwerkprofil

Ein Windows Client weist der Netzwerkverbindung dann eines von drei Profilen (Domain/Privat/Öffentlich) zu. Dazu bedient er sich einiger Prüfungen. Ein Domain-Mitglied ermittelt per DNS seine Domain-Controller und versucht eine Verbindung aufzubauen. Wenn ihm dies gelingt, dann geht er davon aus, dass er im lokalen Netzwerk ist und aktiviert das "Domain-Profil" auf der Netzwerkkarte. Wenn er keinen Domain Controller erreicht oder, wie beim AzureAD-Joined-Computern gar nicht Mitglied einer Domain ist, dann fällt er auf das Profil "Öffentlich" zurück.

Dieses Profil hat natürlich ein anderes Firewall-Regelset. Die Netzwerk-Administratoren merken das in der Regel sofort, wenn Sie den Client über seine IP-Adresse per PING ansprechen wollen. Ein Windows Desktop antwortet nur auf einen IMCP-ECHO-Request, wenn er Domain Netzwerk ist. Sonderfälle wie eigene Regeln oder eine deaktivierte Firewall ignorieren wir besser

Für eine Firma muss das aber kein Problem sein, wenn die Client wirklich jede Verbindung von sich nach extern aufbauen. Sollten Sie im Netzwerk aber als Teil verschiedener Prozesse einen Zugriff auf den Client benötigen, dann ist "öffentlich" sicher das falsche Profile.

Bitte bohren Sie keine Löcher in das "Öffentlich"-Profil, denn es gilt auch, wenn der Anwender tatsächlich mal im Homeoffice oder unterwegs an einem Hotspot im Internet ist.

Sie sollten eher dem Client beibringen, dass er noch anhand anderer Kriterien erkennen kann, wann er in einem "vertrauenswürdigen Netzwerk" ist und das "Domain"-Profil aktivieren kann. Ein IP-Subnetz oder die MAC-Adresse eines Gateways o.ä. zählen nicht zu den verlässlichen Indikatoren. Microsoft hat hier einen anderen Weg geschaffen. Sie stellen in ihrem internen Netzwerk einen Service bereit, der per TLS erreichbar ist und ein gültiges vertrauenswürdiges Zertifikat vorweist. Diese Adresse und der Server darf natürlich nie aus dem Internet oder anderen weniger vertrauenswürdigen Diensten erreichbar sein.

Der Client startet die Namensauflösung auf den hinterlegten Service und startet den TLS-Handshake. Wenn das vom Service gelieferte Zertifikat vertrauenswürdig ist, dann geht der Computer von einem "Domain Netzwerk" aus. Sie sollten dann aber einen "zuverlässig erreichbaren" TLS-Endpunkt haben, z.B. einen Loadbalancer oder sie nutzen DNS Round Robin, um mehrere Server unter dem gleichen Namen erreichbar zu machen. Das wäre dann auch eine Option für größere Firmen mit mehreren Standorten, damit Client einen "Probe-Host" einen lokalen Endpunkt prüft. Vielleicht haben Sie ja schon ihre verteilten Domain Controller nicht nur mit ihrem FQDn sondern auch einem Alias, z.B. "ldap.<firmendomain>" auflösbar gemacht oder sie denken über Anycast-Routing nach. Die Technik wird der ein oder andere Administrator schon vom Direct Access Network Location Service NLS kennen. Vergessen Sie dabei nicht die Erreichbarkeit dieser "Probe-Hosts" auch zu überwachen.

Einschätzung

Ein erstmals gestartetes Windows 10 verhält sich heute so, wie es die Vision von Microsoft ist und ist schneller mit dem AzureAD-Tenant verbunden als mit einem lokalen Active Directory. Für Firmen, die heute schon viele Dienste aus der Cloud nutzen, ist es damit der logische Schritt, auch das Management der Clients in die Cloud zu verlegen. Wenn Sie dann noch lokale Services über HTTPS erreichbar machen und den Azure AD Application Proxy zur Veröffentlichung einsetzen, dann bleiben lokal nur noch Spezialanwendungen übrig. Wozu brauchen Sie dann noch ein lokales Active Directory?

Ganz so einfach ist es aber dann doch nicht. Es gibt immer noch sehr viele Produkte, die ein lokale Active Directory voraussetzen und solange nur eine Applikation ein lokale AD benötigt, benötigen Sie lokale Benutzer und Gruppen und ADSync zum Abgleich. Sobald ADSync aktiv ist, brauchen Sie offiziell (Stand Dez 2020) einen lokalen Exchange Hybrid Server (ADSync mit Exchange Online und Hybrid Connector Server).

Damit macht es für die meisten Firmen heute immer noch Sinn, die Clients ins eh vorhandene lokale Active Directory aufzunehmen, per ADSync in der Cloud bekannt zu machen und als "Hybrid AzureAD-Joined" -Geräte zu verwalten.

Es wird aber immer mehr Firmen geben, die eine Teil oder sogar alle Clients nur noch über das AzureAD verwalten und auf ein lokales Active Directory verzichten werden. Zuerst dürfte dies für kleinere Firmen, Startup oder Ausgründungen relevant werden. Das habe ich schon 2018 begleitet. Mittlerweile gibt es auch größere Firmen, die nur noch 2interne" PCs in das lokale Active Directory aufnehmen aber Vertriebsmitarbeiter gar nicht mehr ins das "interne Netzwerk" lassen-

Weitere Links