Ein Windows 10 Gerät kann einen Domain Join gegen ein Windows Server Active Directory oder ein Azure AD vornehmen. Der Weg über das Azure AD war dabei lange nur für Firmen interessant, die keine klassischen OnPrem-Systeme wie Fileserver nutzen. Hier hat sich einiges geändert und der Domain Join zum Windows Server Active Directory wird für viele unnötig.

Azure AD Join

Der Domain Join von Computern gegen ein Windows Server Active Directory ist die weltweit verbreitetste Methode PCs in eine Unternehmensverwaltung aufzunehmen und den Login mit Unternehmensaccounts zu ermöglichen. Im Zeitalter mobiler Arbeitsplätze, aber auch für Firmen mit mehreren Standorten, führt dieses Konzept jedoch zu enormen Anforderungen an die Netzwerk-Infrastruktur: VPNs vernetzen sowohl Standorte als auch die Clients. Redundante Server werden in den Niederlassungen aufgestellt und Active Directorys zu diesen repliziert, damit die Funktionen zügig laufen.

Mit dem Azure AD betreibt Microsoft jedoch einen globalen Verzeichnisdienst der – VPN-los – hochverfügbar über das Internet zugängig ist. Dank Funktionen wie Conditional Access liegt dieser Dienst dabei weit über den Sicherheitsmaßstäben der meisten Unternehmen. Leider brachte der Wechsel des Domain Joins lange Zeit einige Nachteile beim Umgang mit vorhanden OnPremise-Ressourcen mit sich.

In diesem Artikel gehe ich auf Konzepte zur Cloud- & Hybrid-Cloud-Einbindung von Windows 10 Geräten sowie einige Funktionsabhängigkeiten für OnPremise-Systeme ein.

Domain Join: Wo wird ein Gerät zuerst registriert?

Bei der Einrichtung von Windows 10 steht nach Verbindung mit einem Netzwerk die Wahl, an welchem Verzeichnisdienst sich der Anwender anmelden soll.

Da es sich in dem hier beschriebenen Szenarien immer um eine Hybrid-Cloud handelt, sind auch immer beide Verzeichnisse involviert – die Erstwahl bestimmt jedoch die Verwaltungsmöglichkeiten.

Dieser Schritt wird durch Windows Autopilot automatisiert Richtung Azure AD gelenkt – analog dazu durch Einsatz von Hybrid Windows Autopilot zum Windows Server AD.

Im Fall eines lokalen Domain Join (bzw. Hybrid Autopilot), wird das Computerobjekt zunächst im Windows Server AD angelegt. Die primäre Verwaltung verläuft über diesen Dienst. Ausgehend hiervon wird die Geräteregistrierung im Azure AD angestoßen und das Gerät ist in beiden Verzeichnissen vorhanden.

Hybrid Azure AD Join

image

Dieses Vorgehen wird als Hybrid Azure AD Join bezeichnet. Wichtig ist hierbei, dass zwischen der Erstellung eines Computerobjekts in einem Verzeichnis und einer Client-Registrierung unterschieden werden muss. Der Sync erstellt das Objekt im Azure AD – aber der Client registriert sich zudem über eigene Windows-Funktionen.

Beim Einsatz von ADFS ändert sich der Geräteregistrierungsablauf leicht. Da das oben zu sehende Bild sowohl den Prozess für verwaltete als auch den Fallback-Mechanismus für föderierte Domänen beschreibt, belasse ich es hierbei.

Ist der Hybrid Join abgeschlossen, können Dienste wie Intune zusätzlich zu Gruppenrichtlinien und Co. zur Verwaltung des Clients genutzt werden.

Bei Auswahl eines reinen Azure AD Join verhält sich die Registrierung ein wenig anders: Hier kann sich der Client zwar den gesyncten Benutzerkonten des Windows Server AD bedienen und diese sogar via ADFS an der lokalen Domäne Authentifizieren – die Registrierung findet jedoch Ausschließlich im Azure AD statt.

image

Da keine Registrierung im Windows Server AD vorgenommen wird, können auch keine Gruppenrichtlinien greifen. Das ist aber in soweit kein Problem: Durch Administrative Templates (ADMX) in Intune ergeben sich umfangreichere Verwaltungsmöglichkeiten und durch ein Co-Management mit System Center Configuration Manager (SCCM) können diese sogar nochmal erweitert werden.

Der Fokus liegt im folgenden auf dem Cloud-Only Client der beim Azure AD registriert wurde.

Clients ins Active Directory: Device writeback und Richtlinien

Azure AD Connect, bietet neben der Möglichkeit zum Hybrid AD Join auch ein Device writeback. Die writeback-Funktion synchronisiert das Computerobjekt (auch mobile Geräte wie iPhones) ins Windows Server AD.

image

Die durch writeback erstellten Computerobjekte sind in einer zunächst versteckten OU des AD zu finden und nach der Objekt- bzw. Geräte-ID des Azure AD Objekts benannt.

image

Wie zuvor schon erwähnt wird hierbei das Computerobjekt erstellt – eine Betriebssystem-abhängige Registrierung findet jedoch nicht statt. Gruppenrichtlinien können die Geräte somit nicht erfassen; Namenskonventionen, Sub-OUs und co. bieten also keinen Funktionalen Mehrwert. Die Computerobjekte sind lediglich dazu gedacht, dass Dienste wie z.B. ein ADFS-basierter Conditional Access oder die Erstellung gerätebasierter Zertifikate via Network Device Enrollment Service (NDES), die nicht direkt auf das AzureAD zugreifen (können), eine Datenbank haben, anhand derer sie Geräte zuordnen können, wenn sie mit Anfragen für diese konfrontiert werden. Die gerätebasierte Zertifikatsausstellung ist dabei erst seit November möglich.

Ohne ein explizites Szenario, bei dem der Einsatz von ADFS und NDES für gewöhnlich ebenfalls nötig ist, bietet es also keinen Mehrwert den writeback zu aktivieren und es sollte darauf verzichtet werden, um das Verzeichnis nicht unnötig vollzumüllen.

Typische Anforderungen, wie der Zugriff auf Fileshares, lokale Webapplikationen oder Drucker benötigen diese Funktion nicht.

Fileshares: PIN, Fingerabdruck & Gesichtserkennung mit Windows Hello

Der Zugriff auf einen Fileshare über die Anmeldedaten des Benutzers ist auch von einem Azure AD Client aus möglich. Dabei muss erstmal nur die Netzwerkverbindung – ggf. via VPN – gewährleistet sein. Ein Cloud-Client kann dabei aber auch einfach im Standard-Unternehmensnetz genutzt werden. Durch Einsatz von OneDrive und SharePoint sollte sich die Notwendigkeit Netzlaufwerken minimieren, sodass dieser Zugriff für den Cloud-Client meist nicht (mehr) die primäre Arbeitsweise umfasst.

Mit Windows 10 setzt Microsoft stark auf Windows Hello um einen höheren Schutz für Anmeldeinformationen zu gewährleisten und zudem den Login für Anwender zu vereinfachen.

Beim Zugriff auf einen Fileshare – oder eine Remotesession – wird ein Use ggf. zur Authentifizierung aufgefordert.

image

Windows Hello ist jedoch zunächst nur ein Azure AD-Feature. Die Authentifizierung am lokalen Fileshare kann so also nicht gelingen, da das Windows Server AD diese Methode nicht kennt. Zudem wäre beim Einsatz von ADFS ein Single Sign On schön – Anwender sollten gar nicht zur Eingabe von Anmeldeinformationen aufgefordert werden, wenn sie bereits an einem anderen Dienst authentifiziert wurden. Um dies zu gewährleisten ist der Einsatz einer PKI und der Konfiguration der Hybridbereitstellung von Windows Hello notwendig.

Azure AD Application Proxy: Zugriff auf lokale Webapps

Im Gegensatz zu Fileshares ist der Zugriff auf Webapps nicht auf eine direkte Netzwerkanbindung limitiert, diese können auch ins Internet publiziert werden. Eine direkte Publikation ist fürs Intranet jedoch eher selten gewünscht – schließlich sollen lediglich Mitarbeiter auf diese Dienste zugreifen können und keine Angriffsfläche von außen bieten. Eine Lösung bietet dabei der Azure AD Application Proxy.

image

Über einen Connector wird der Zugriff dabei über das Azure AD, ohne VPN o.ä., ermöglicht. Der Aufruf der Webapp (und damit auch die Erzeugung von Last auf dem Server) erfolgt hierbei erst, wenn eine Vorauthentifizierung durch das AzureAD vorgenommen wurde. Die weite Öffnung der internen Firewall und Bereitstellung zusätzlicher Web Application Proxys entfällt hierbei. Zudem kann ein Anwender die Webapp bequem aus dem Office 365 oder Myapps-Portal öffnen.

image

Webapplikationen, die z.B. Integrated Windows Authentication (IWA) unterstützen, profitieren zudem von Single Sign On, da durch die Anmeldung am Azure AD bereits eine Benutzersession mit qualifiziertem Kerberos-Ticket vorhanden ist; durch das vorschalten der Azure AD Authentifizierung sind außerdem Sicherungsmaßnahmen wie eine bedinge Zugriffssteuerung (Conditional Access) und Bring your Own Device (BYOD) Szenarien abgedeckt.

Noch kein papierloses Büro? Hybrid Cloud Print

Die letzte typische Anforderung zum Zugriff auf interne Dienste stellen Drucker dar. Einerseits wird das papierlose Büro breit propagiert und digitale Signaturverfahren ermöglichen es, diverse Verträge rechtssicher zu schließen. Andererseits können wir uns aber doch noch nicht so ganz von der klassischen Ablage lösen. Seit wir intern unsere Reisekostenabrechnung digitalisieren konnten, habe ich meinen Drucker allerdings nur noch für arbeitsfremde Tätigkeiten genutzt. Mittlerweile ist er auch nicht mehr am Netz. Die Notwendigkeit besteht für andere Arbeitsbereiche aber durchaus.

A diagram showing a graphic depiction of the Hybrid Cloud Print solution

(Quelle: Microsoft)

Drucker benötigen meist GPOs, die Erkennung von Subnetzen und Netzwerkzugriffe abseits von HTTPs, was die automatisierte Bereitstellung für PCs ohne lokale Domänenzugehörigkeit verhindert. Unter Einsatz des Azure AD Application Proxys, Intune und Windows Server Hybrid Cloud Print, lässt sich jedoch auch dieses Manko beheben.

Fazit

Lang war der Weg, doch endlich ist die Bereitstellung standortunabhängiger Clients machbar, ohne dabei auf kritische Verwaltungsmöglichkeiten verzichten zu müssen. Die hier beschriebenen Maßnahmen sind auf den ersten Blick umfangreich. Jedoch schwindet der Eindruck, wenn man vergleicht, was Unternehmen bislang investieren. Denn oft werden interne Dienste doppelt und dreifach bereitgestellt, um eine simple Anmeldung und Geräteverwaltung zu ermöglichen. Mit den neuen Maßnahmen wird die lokale Infrastruktur für den Client – und für den Anwender – zum Teil einer echten Cloud und als ein Konstrukt – und nicht zwei Welten – wahrgenommen. Zudem löst sich dadurch auch die Plattformabhängigkeit. Die hier beschriebenen Dienste und der Weg zur einheitlich webbasierten Bereitstellung ermöglicht nicht nur den Einsatz von Windows-Geräten, auch Android, iOS und MacOS können auf diese weise OnPremise-Dienste nutzen ohne eine direkte Abhängigkeit zu diesen aufzuweisen.

Sie müssen noch in diesem Jahr den Wechsel von Windows 7 auf Windows 10 in Angriff nehmen?

Dann sollten Sie sich unbedingt mit dem Konzept des Azure AD-Clients, der automatisierten Bereitstellung via Windows Autopilot und dem Transfer von Netzlaufwerken zu OneDrive und SharePoint auseinandersetzen.

Jetzt Kontakt aufnehmen zu aConTechs Cloud-Expert:innen.