Azure AD 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 "OnPremises"-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 OnPremises 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.

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

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