Let´s encrypt-Zertifikate automatisieren

Sparfüchse aufgepasst! 🙂 Sicher hat der ein oder andere schon von Let´s encrypt gehört: Eine tolle Sache! Kostenlose SSL-Zertifikate, die von allen gängigen Browsern als vertrauenswürdig angesehen werden, SAN support… ab 01/2018 sollen sogar Wildcard-Zertifikate unterstützt werden. Über z.B. SSLforFree lässt sich recht bequem arbeiten und man erhält vor Ablauf der Zertifikate eine Erinnerungsmail, praktisch. Mindestens mal für Test- und Entwicklungssysteme sehr interessant!

Nicht ganz so trivial ist dabei aber die Erbringung des Nachweises, dass man Besitzer der jeweiligen öffentlichen Domänen ist. Es stehen 3 Überprüfungsmethoden zur Verfügung: Upload von Infos zu einem FTP-Server (noch keine Erfahrung), Upload zu einem HTTP-Server oder Upload zum öffentlichen DNS. Wir schauen uns kurz die letzten beiden an.

  • DNS: Wenn ich ein Zertifikat für „sub.domain.com“ beantragen möchte, muss ich für diesen Namen im öffentlichen DNS einen speziellen TXT-Eintrag mit kryptischem Inhalt erstellen. Soweit, so gut. Wenn ich eine Reihe von SANs benötige, wird das schon etwas aufwändig und mühselig – je nach DNS-Provider und Güte des Tools kann es auch nervtötend werden.
  • HTTP: Wenn ich ein Zertifikat für „sub.domain.com“ beantragen möchte, muss ich einen unter diesem Namen per HTTP (ohne „s“) erreichbaren Web-Server bereitstellen (!) und dort im WWW-Root ein Verzeichnis namens „.well-known“ sowie einen Unterordner „acme-challenge“ anlegen. Dort hinein kommen spezielle Dateien mit kryptischen Namen. Klingt kompliziert? Ist es auch. Mal eben einen Web-Server für jeden Namen bereitstellen ist schon eine Herausforderung. Hier ist es ja nicht nur damit getan, z.B. ein zusätzliches Binding im IIS zu konfigurieren (wenn denn überhaupt IIS zum Einsatz kommt). HTTP-Anfragen müssen auch von extern hereinkommen können und an die richtige Stelle gelangen – ein geeignetes HTTP-Publishing ist also Pflicht. Wenn ich auch noch eine Reihe von SANs benötige, brauche ich für alle Namen auch jeweils ein Publishing. Dieses muss jeweils zu einem Web-Server zeigen, in dessen WWW-Root ein Ordner „.well-known“ existiert, usw.

Übrigens: Einmal präpariert, sind die Nachweise nicht von Dauer. Nach 90 Tagen verlieren sie ihre Gültigkeit und müssen erneuert werden.

Das wäre alles halb so schlimm, wenn die eigentlichen Zertifikate länger gültig wären. Sind sie aber leider nicht: Nach 3 Monaten ist auch hier Schluss und sie müssen erneuert werden. Dies gilt auch für die o.g. Autorisierungsnachweise. Und dann wäre da noch eine Kleinigkeit: Die neuen Zertifikate müssen ja auch noch den anhängigen Diensten wie z.B. Exchange, ADFS, WAP, RDS oder IIS bekannt gemacht werden, das war ja Ziel des Spiels. Natürlich kann man all das manuell machen. Mit einer guten Doku kann das sogar gut funktionieren. Aber bequem ist anders und wenn viele Dienste aktualisiert werden müssen, artet das in eine Menge Arbeit aus. Nun gut – ohne Herausforderungen wird es schnell langweilig. Es muss also eine bessere Lösung her…

Kann man das nicht irgendwie automatisieren?

Einige findige Leute haben sich diese Frage auch schon gestellt und bemerkenswerte Lösungen auf Powershell-Basis (ACMESharp Modul) entwickelt. Diese sind jeweils auf bestimmte Zielsysteme zugeschnitten, z.B.

a) für Exchange von Frank Zoechling,

b) für RDS-Server von Daniel Melanchthon oder

c) für IIS-WebServer von Marc Durdin.

Wohlgemerkt sind alle Lösungen auf exakt einen Server geeicht – also für jeden Server ein eigenes Zertifikat. Hat man mehr als 1 Exchange Server (z.B. in einer DAG) oder eine aus mehreren Servern bestehende RDS-Farm, muss man die Skripte nachfeilen.

Das Prinzip bei allen:

  1. Autorisierungsinfos für die öffentlichen Domänen erstellen
    • Der eine (b) favorisiert DNS , weil es simpler ist und weniger Anpassungen in der Infrastruktur erfordert. Allerdings ist hier die Automatisierung schwierig – je nach DNS-Provider mal mehr, mal weniger. Eine Standardlösung für alle DNS-Provider ist nur schwer vorstellbar.
    • Die anderen (a, c) favorisieren HTTP, weil es tatsächlich vollständig automatisierbar ist. Diverse Publishings mit geschickten Umleitungen etc. sind aufwändig und komplex, der Aufwand fällt aber bei gleichbleibenden Domänen nur einmal an.
  2. Anfordern des Zertifikats, dabei Überprüfung der in Schritt 1 erstellten Autorisierungsinfos
  3. Export des Zertifikats ins PFX-Format
  4. Einbinden des Zertifikats in die jeweiligen Dienste

Sofern man kein Problem mit der HTTP-Variante und ihren Nachteilen hat (und sich alles um Single-Server-Deployments dreht), lassen sich die Skripte a) für Exchange Server und c) für IIS-WebServer schon mal prima einsetzen. Gleiches gilt für RDS und b) wenn man mit einer Halbautomatik erst einmal zufrieden ist.

Ich für meinen Teil hatte für meine Testumgebung etwas speziellere Wünsche. Da ich dort nur eine öffentliche IP habe und einen großen Fuhrpark von Servern, Diensten und (sub-)domains versorgen muss, benötige ich ein SAN-Zertifikat mit sämtlichen DNS-Namen, das auf viele verschiedene Server zum Einsatz kommt. D.h. ich musste dafür sorgen, dass Autorisierungsinfos für alle Domänen zugreifbar sind. Nach einigen Modifikationen war das Skript von Frank Zoechling soweit, dass es im WWW-Root eines Web-Servers die Infos für alle Domänen ablegte.

2017-11-20_17h23_20

Nun noch eine Veröffentlichungsregel auf dem guten alten TMG, die incoming HTTP an diese Domänen zum obigen Web-Server leitet.

clip_image002

Damit war Punkt 1 erledigt, Punkt 2 und 3 funktionierten ohne weitere Modifikationen.

clip_image003

Punkt 4 sind eigene, separate Skripte auf den jeweiligen Zielservern (Exchange, ADFS, usw.), bislang noch nicht vollständig automatisiert. Bis hierhin zu kommen war schon eine Menge Arbeit, aber es hat sich gelohnt!

Es folgt eine Liste von Befehlen, die ich auf den jeweiligen Systemen abfeuere sowie ggf. weiterführende Infos.

Exchange 2016

  • Import-ExchangeCertificate -FileName \\centralserver\share\certnewest.pfx -FriendlyName „SAN domain.com“ -Password (ConvertTo-SecureString „HOCHGEHEIMESPASSWORT“ -AsPlainText -Force) -PrivateKeyExportable:$true | Enable-ExchangeCertificate -Services „SMTP, IMAP, POP, IIS“ -force

Exchange 2010

  • $ex=Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path \\centralserver\share\certnewest.pfx -Encoding byte -ReadCount 0)) -FriendlyName $ExchangeSubject -Password (ConvertTo-SecureString „HOCHGEHEIMESPASSWORT“ -AsPlainText -Force) -PrivateKeyExportable:$true
  • Enable-ExchangeCertificate -Services „SMTP, IMAP, POP, IIS“ -force -thumbprint $ex.Thumbprint

IIS

RDS

ADFS

  • Die Funktion „Set-CertificatePermission“ stammt auch aus den Tiefen des WWW
  • $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString „HOCHGEHEIMESPASSWORT“ -AsPlainText -Force)
  • $installedcert=Get-ChildItem Cert:\LocalMachine\My | ? {$_.Thumbprint -eq $certresult.Thumbprint}
  • Set-AdfsSslCertificate -Thumbprint $installedcert.Thumbprint
  • Get-AdfsSslCertificate
  • Set-CertificatePermission -pfxThumbPrint $installedcert.Thumbprint -serviceAccount „s_adfs“
  • Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint $certresult.Thumbprint
  • Restart-Service adfssrv

WAP

  • Hier fehlt noch die vernünftige Speicherung des „FederationServiceTrustCredential“, bislang nur interaktiv
  • $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString „HOCHGEHEIMESPASSWORT“ -AsPlainText -Force)
  • $installedcert=Get-ChildItem Cert:\LocalMachine\My | ? {$_.Thumbprint -eq $certresult.Thumbprint}
  • Install-WebApplicationProxy -FederationServiceTrustCredential (Get-Credential) -CertificateThumbprint $installedcert.Thumbprint -FederationServiceName ‚adfs.domain.com‘

Work Folders

  • $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString „HOCHGEHEIMESPASSWORT“ -AsPlainText -Force)
  • cmd /c netsh http delete sslcert ipport=0.0.0.0:443
  • cmd /c netsh http add sslcert ipport=0.0.0.0:443 certhash=$certresult.Thumbprint appid=“{CE66697B-3AA0-49D1-BDBD-A25C8359FD5D}“ certstorename=MY

Kemp VLM, SharePoint

  • Offen: Hier muss ich mir noch etwas überlegen/auf die Suche gehen

Fazit: Das Ganze ist noch eine offene Baustelle, von einer vollständigen Automatisierung bin ich noch ein Stück entfernt. Nichtsdestotrotz ist auch der aktuelle Stand mehr als nützlich und vereinfacht die Angelegenheit enorm. Let´s encrypt-Zertifikate sind eine tolle Sache. Aller Automatisierung zum Trotz sollten diese jedoch meiner Meinung nach Stand heute besser nicht in produktiven Umgebungen eingesetzt werden. Dann lieber ein paar Euro in ein 3 Jahre gültiges Zertifikat investieren. Für Test- und Entwicklungsumgebungen eignet sich das Ganze aber sehr gut!

Ich hoffe, diese Infos sind für den ein oder anderen nützlich.

PS: Danke an die genannten Quellen, ihr habt tolle Vorarbeit geleistet!

Windows 10 im Unternehmensumfeld – SSO, "Hybrid" und andere Mysterien (Teil 2)

Hier folgt nun die versprochene Fortsetzung. Im 1. Teil haben wir uns über das Szenario „Windows Store for Business“ (WSfB) dem Thema „Automatische Azure AD-Registrierung (für domain-joined Computer)“ genähert. Man kann festhalten, dass diese der Schlüssel für den bequemen und unternehmenstauglichen Zugriff auf Microsoft Online Ressourcen ist. Durch die AAD Auto-Registrierung wird echtes SSO ermöglicht und sie läuft für den User vollkommen transparent (d.h. ohne jegliche Interaktion) ab.

Aber was ist nun konkret zu tun, um die Automatische Azure AD Registrierung zu etablieren?

Voraussetzungen für die AAD Auto-Registrierung

Microsoft stellt eine Vielzahl von Anleitungen zur Verfügung wie z.B. diese oder auch jene.

In der Praxis hat sich aber gezeigt, dass es oftmals im Detail hapert – mal fehlt in der einen Anleitung dieser Punkt, mal in der anderen jener… hier eine Zusammenfassung der wichtigsten Schritte:

  1. Sofern noch nicht geschehen, AADConnect und ADFS implementieren, öffentliche Domäne in AAD registrieren, Federation herstellen, UPN der Benutzer im on-premises AD sollte gleich der SMTP-Adresse sein
  2. Alle Benutzer, die Cloud Ressourcen nutzen, müssen ins AAD synchronisiert werden
  3. Zusätzlich: Alle (relevanten) Windows 10 Computer-Objekte müssen ebenfalls ins AAD synchronisiert werden
  4. Erstellen eines Service Connection Point im on-premises AD, damit Windows 10 Computer ermitteln können, wohin sie sich wenden müssen, um zum AAD zu gelangen. Dieser SCP wird in der Configuration Partition per Skript angelegt, es sind Enterprise Admin Rechte erforderlich
  5. Aktivieren des sog. ADFS Endpoint namens „windowstransport“. Dieser wird benötigt, damit Windows 10 Computer sich bei ADFS authentifizieren können
  6. Mindestens drei neue Claim Rules (ohne „SupportMultipleDomains“) in der Relying Party Konfiguration für „Microsoft Office 365 Identity Platform“, mit denen die on-premises objectGuid, accounttype („DJ“ = domain joined) und die primarysid via ADFS an AAD übermittelt werden
  7. Aktivieren von Windows Integrated Authentication als Alternative zu MFA in der o.a. Relying Party

Ablauf der AAD Auto-Registrierung

Auf allen domain-joined Windows 10 Computern existiert ein Scheduled Task unter \Microsoft\Windows\Workplace Join namens „Automatic-Device-Join“. Dieser Task läuft im SYSTEM-Kontext und wird bei jedem Anmelden eines Benutzers gestartet. Bei Windows 10 (Build 1511) war dieser Task noch deaktiviert und musste z.B. per GPO aktiviert werden. Bei Windows 10 (Build 1607) ist er hingegen out-of-the-box aktiviert. Wenn alle o.g. Punkte erledigt sind, bewirkt der Task eine Vielzahl von Aktionen. Die genaue Beschreibung würde den Rahmen dieses Beitrags definitiv sprengen – es werden Schlüsselpaare erstellt, der TPM Chip zum Schutz der Schlüssel verwendet, Zertifikate von Azure AD ausgestellt, der Computer erstellt ein Device Object, AAD Connect korreliert dieses mit dem on-premises Computer-Objekt, etc. Genug Stoff für einen zukünftigen separaten Blog Beitrag 🙂

Hier der vereinfachte Ablauf:

  1. Computer identifiziert über den SCP den passenden AAD Tenant und baut eine dorthin Verbindung auf. Achtung: Damit dies funktionieren kann, benötigt der Computer uneingeschränkten Zugriff auf mehrere URLs!
  2. Computer wird umgeleitet zu ADFS und authentifiziert sich. Dabei erhält er von ADFS die oben erwähnten Claims
  3. Mit diesen Claims im Gepäck erstellt der Computer nun ein neues Device Object für sich in AAD. Die Werte aus den Claims werden in Attribute des neuen Objekts übertragen
  4. AAD stellt ein Zertifikat für den Computer aus, mit dem dieser sich künftig authentifiziert
  5. Das PRT findet ebenso seinen Weg auf den Computer
  6. AADConnect verknüpft das neue Device Object beim nächsten Lauf mit dem existierenden Computer-Objekt im on-premises AD. Hierdurch wird das on-premises Computer-Objekt autoritativ – d.h. wenn es z.B. gelöscht wird, wird auch das Device Object in AAD gelöscht!

Greift der Benutzer nun auf z.B. Sharepoint Online oder OneDrive for Business zu, werden mithilfe des PRT die Access Tokens beantragt. Falls Sie Kerberos kennen: Im Prinzip kann man sich das PRT ein wenig wie ein Ticket Granting Ticket vorstellen und Access Tokens wie Session Tickets.

Mithilfe der Tokens erfolgt nun die Authentifizierung bei der Zielressource.

Tipps

  • Nutzen Sie beim Erstellen der Federation (convert-MsolDomainToFederated) möglichst nicht die Option „SupportMultipleDomains“, sofern kein akuter Bedarf besteht. Hierdurch werden zusätzliche Claim Rules erforderlich und deren Konfiguration ist in diesem Fall alles andere als trivial
  • Sie wollen nicht alle Windows 10 Computerobjekte ins AAD synchronisieren? Keine Sorge, das passiert auch gar nicht. Selbst, wenn Sie keine Filter konfigurieren, erstellt AADConnect für die on-premises AD Computer-Objekte keine neuen Device Objects in AAD, sondern korreliert nur bereits existierende zwecks Life cycle management. Nicht AADConnect erstellt neue Device Objects – sondern das machen die Computer selbst während der Auto-Registrierung!
  • Achten Sie darauf, dass alle Claims auch tatsächlich in ADFS definiert sind, für die Sie Claim Rules erstellen. Eine Claim Rule macht noch keinen Claim 😉
  • Falls Sie einen Forward Proxy mit User Authentifizierung einsetzen: Machen Sie sich auf Probleme gefasst… Der Zugriff des Computers auf das AAD zwecks Registrierung erfordert Zugriff auf mindestens diese URLs:
    • enterpriseregistration.windows.net und
    • login.microsoftonline.com

Und zwar erfolgt der Zugriff im Kontext des Computerkontos, da der Scheduled Task als SYSTEM läuft. Oftmals empfiehlt es sich, den Zugriff auf diese URLs auf der Firewall (nicht authentifiziert) zu erlauben oder einen geeigneten ggf. transparenten Proxy ohne Authentifizierung zu verwenden. Das Thema Proxy & Authentifizierung holt einen übrigens spätestens beim Windows Store for Business wieder ein, soviel sei schon mal verraten.

Fazit

Wenn Sie Windows 10 und Cloud-Ressourcen wie Office 365 oder Windows Store for Business unternehmenstauglich einsetzen und verwalten wollen, dann sollten Sie definitiv die automatische Azure AD Registrierung ihrer Domain-joined Computer etablieren. Diese ist der Schlüssel zum bequemen und sicheren Zugriff auf Microsoft Online Ressourcen. Sie schaffen hierdurch die Grundlage für echtes SSO und weitere interessante Enterprise Features. Eine saubere und adäquate Einrichtung von ADFS und DirSync/AADConnect ist die Basis für SSO, die Sie entweder selber betreiben oder bei Bedarf auch als Komplettpaket bzw. Managed Service bei iteracon buchen können. Wie man unschwer erkennen kann, ist die gesamte Thematik alles andere als simpel und die Einrichtung nicht trivial. Das Ergebnis kann sich allerdings mehr als sehen lassen! Aus Sicht des Endanwenders könnte es kaum simpler sein: An Windows anmelden, auf Ressourcen Zugreifen, fertig! 🙂

Und das gilt sogar auch für die Store App mit dem Windows Store for Business. Aber dazu wie gesagt später mehr.

Viele Grüße

Alexander Zarenko

Windows 10 im Unternehmensumfeld – SSO, "Hybrid" und andere Mysterien (Teil 1)

Wenn man sich mit Windows 10 und seinem Einsatz in Enterprise-Umgebungen beschäftigt, stellen sich viele Fragen – u.a. zur Verwaltbarkeit und Cloud-Anbindung. Beim Versuch, diese Fragen zu klären, wird man mit einer Vielzahl von Begriffen konfrontiert. Vermutlich haben Sie von Azure AD Join und Workplace Join gehört. Hinzu kamen dann vermutlich recht bald Single Sign On, ADFS, DirSync/AADConnect, MDM Autoenrollment, Intune, SCCM und noch vieles mehr. Ein weites Feld…

Letzten Endes geht es darum, Windows 10 unternehmenstauglich einzusetzen und zu verwalten. Aber wie geht das und was heißt das eigentlich? Es herrscht teils große Verunsicherung, wie einige neue Entwicklungen einzuordnen sind und manche Veranstaltungen oder Kommentare von Leuten, die es eigentlich wissen sollten, schüren diese Verunsicherung noch. Wie etwa: Wird Domain Join bald abgeschafft? Heißt die Zukunft Azure AD Join? Ist die klassische Verwaltung mit Tools wie SCCM tot und läuft künftig alles über MDM wie z.B. Intune?

Ich kann sie beruhigen. Ich bin zwar kein Orakel, aber bin mir mittlerweile (das war nicht immer so!) sehr sicher, dass all diese zugegebenermaßen überspitzt formulierten Fragen für die absehbare Zukunft mit „Nein“ beantwortet werden können. Denn: Mit kleinen Einschränkungen ist alles da und es passt alles zusammen (auch das war nicht immer so!). Man muss nur die richtigen Teile miteinander kombinieren. Aber welche sind das, für welches Szenario?

Dieser und zukünftige Artikel rund um Windows 10 sollen etwas Licht ins Dunkel bringen. Zunächst greifen wir einen wichtigen Teilaspekt auf, der im Zusammenhang mit dem Thema „Cloud-Anbindung“ steht.

Ein Beispielszenario, der Aufhänger für diesen Beitrag: Ihr Unternehmen möchte gewappnet sein für etwaige Anfragen der Benutzer à la „Ich bin viel mit meinem Surface Pro 4 unterwegs und benötige für Präsentationen die PowerPoint App aus dem Windows Store“.

Eine häufige Antwort der IT-Verantwortlichen: „Windows Store? Den haben wir gesperrt. Das ist eine auf Privatpersonen zugeschnittene Geschichte, die wir im Unternehmensumfeld nicht unterstützen.“

Und das ist dann das Ende vom Lied – so war es oft mit Windows 8.1.

Nun gibt es aber seit einiger Zeit den Windows Store for Business (WSfB), mit dem sich ein unternehmensspezifischer Bereich innerhalb des Windows Store definieren lässt, der allen Mitarbeitern offen steht. Der Zugriff auf diesen „Private Store“ erfolgt mit denjenigen Anmeldedaten, mit denen die Benutzer bereits am Rechner angemeldet sind – sofern einige Voraussetzungen erfüllt sind. Welche dies konkret sind und welche Möglichkeiten WSfB bietet, ist genug Stoff für einen eigenen Blog-Beitrag… an dieser Stelle deshalb nur eine Zusammenfassung – Sie brauchen:

  • Einen konfigurierten WSfB Private Store mit den gewünschten Apps, die den Benutzern zur Verfügung stehen bzw. zur Installation angeboten werden sollen. Das Resultat sieht z.B. so aus:

2016-11-04_22h29_13

  • Eine Instanz von Dirsync (d.h. AADConnect) zur Synchronisation der Benutzerobjekte zwischen dem eigenen AD und Azure AD
  • Optional (aber in aller Regel dringend empfohlen) ADFS und eine Federation zu Microsoft, damit Anmeldedaten ihr Unternehmen nicht verlassen.

Anmerkung: Da die Mehrzahl unserer Kunden der o.a. Empfehlung folgt, liegt der Fokus dieses Beitrags auf dem Szenario inkl. ADFS und Federation zu Microsoft.

Sie kommen also zu dem Entschluss, dass der WSfB eine sehr nützliche Sache ist und beginnen mit der Einrichtung von ADFS, Dirsync und konfigurieren WSfB. Diese Einrichtung ist nicht ganz trivial, aber nach einiger Zeit haben Sie es geschafft. Ein Testzugriff auf SharePoint Online oder OneDrive for Business läuft für den Benutzer so, wie man es sich wünscht: Keine Authentifizierungsdialoge – Drin! Das war ja einfach… (kennt jemand noch den alten AOL Spot mit Boris Becker? Ein Klassiker :-)) OK, nun zum Store… Schade, wie kommt man denn nun an den Private Store? Antwort: Hierzu muss der Work Account hinzugefügt werden, was auch als „Workplace Join“ gezeichnet wird.

Standardmäßig passiert dies nicht automatisch. Was nun?

Es gibt an dieser Stelle eigentlich nur eine offensichtliche Möglichkeit:

  • Benutzer fügen Ihren Work Account selbst hinzu. Hierzu starten sie die „Einstellungen“ App, wählen dort „Auf Arbeits- oder Schulkonto zugreifen“, klicken auf „Verbinden“, geben ihren UPN (in der Regel ist dieser identisch mit der Email-Adresse) ein. Daraufhin erfolgt eine Umleitung zu ADFS. Im darauf folgenden Formular muss der Benutzer zum Abschluss noch sein Kennwort eingeben. Nun kann der Benutzer die Store App starten und sein Work Account ist bereits dort hinterlegt. Der Zugriff erfolgt also im Kontext des Work Account und der Private Store wird angezeigt. Ziel erreicht.

Aber ist das unternehmenstauglich?

Vermutlich antworten Sie reflexartig „Nein, ganz bestimmt nicht“ oder „Also bei uns nicht“ und damit sind Sie in bester Gesellschaft. Tatsächlich wird auch Microsoft dies so unterschreiben. Denn „Workplace Join“ ist nicht für Unternehmens-PCs gedacht, sondern für BYOD Szenarien. Was aber tun bei Unternehmens-PCs?

Unternehmens-PCs (Corporate owned devices) mit Windows 10 werden in 2 Klassen unterteilt:

  • Domain-joined Computer. Das sind die klassischen PCs, Notebooks, Tablets oder Hybrid-Geräte, die z.B. mit SCCM oder einem Tool ihrer Wahl aufgesetzt und verwaltet werden. Sie sind Mitglied des on-premises AD und werden üblicherweise ganz klassisch mit SCCM und Group Policies konfiguriert.
  • Azure AD-joined Computer. Für Benutzer, die hauptsächlich mit Cloud Ressourcen arbeiten und Ihren Arbeitsplatz nicht im Unternehmen haben, kann dies eine interessante Alternative sein. Azure AD-joined Computer können im Anschluss an den AAD-join automatisch in die bestehende MDM-Lösung eingebucht werden (z.B. Intune oder SCCM/Intune hybrid) und über diese verwaltet werden. Dieses Feature wird als „MDM Autoenrollment“ bezeichnet. Im Vergleich zur Verwaltung von Domain-joined Computern mit SCCM (via installiertem SCCM-Client) und Group Policies wird hier oft von „MDM Channel“ und „Lightweight Management“ gesprochen.

Nochmal zum Festhalten: Nein, Domain-join wird nicht durch Azure AD Join abgelöst. Zumindest nicht heute und auch nicht morgen. Die Zielgruppen für die Join-Arten sind verschieden. Und SCCM und GPOs sind weiterhin die Mittel der Wahl zur Verwaltung für Domain-joined Computer! Über den MDM Channel wird Lightweight Management gemacht – und zwar für Smartphones generell, für BYOD-Computer oder für heavy-Cloud-User, die ihren Computer ggf. von der Stange kaufen (Kosten übernimmt der Arbeitgeber) und via Self Service zu Azure AD hinzufügen (Azure AD Join) – dies ist ein Beispiel für den sog. COPE-Ansatz (Corporated Owned, Personally Enabled).

Wir wollen uns an dieser Stelle auf Domain-joined Computer konzentrieren, da diese für viele deutlich relevanter sind – schließlich existieren etliche Millionen davon auf der Welt. Microsoft hat seit einiger Zeit ein Verfahren etabliert, das auf Deutsch ungefähr „Automatische Azure AD Registrierung“ (Kurzform im Folgenden: „AAD Auto-Registrierung“) heißt. Hierdurch wird ermöglicht, dass Domain-joined Computer automatisch in Azure AD registriert werden. Dies bietet u.a. die folgenden Vorteile:

  • Für den Benutzer ist der Vorgang komplett transparent, es ist keinerlei Benutzer(inter)aktion notwendig
  • Die Registrierung passiert automatisch, sobald sich Benutzer an den Computer anmelden
  • Work Accounts der sich anmeldenden Benutzer werden automatisch hinzugefügt
  • Die Store App ist fertig vorkonfiguriert und zeigt den Private Store
  • „Enhanced“ SSO beim Zugriff auf Ressourcen

„Normales“ SSO versus „Enhanced“ SSO

Work Accounts werden automatisch hinzugefügt? Keinerlei Benutzerinteraktion, alles vollautomatisch… klingt schon mal super! Aber was ist mit „Enhanced“ SSO gemeint? Vorweg: Den Begriff haben wir uns selbst ausgedacht – um diese besondere Form von SSO abzugrenzen zu dem, was wir üblicherweise unter SSO verstehen. Eine Beschreibung des Ablaufs von „normalem“ SSO am Beispiel von SharePoint Online können Sie hier finden: http://iteracon.de/sso#a4

Um bei diesem Beispiel zu bleiben: Greift ein Benutzer also im LAN auf SharePoint Online zu, geschieht die „Magie“ unter Mitwirkung von ADFS normalerweise vollautomatisch im Hintergrund. Wenn der Benutzer aufmerksam die Adresszeile des Browsers beobachtet, sieht er lediglich die verschiedenen URLs durch die Umleitungen aufblitzen und ist im nächsten Moment schon authentifiziert bei der Zielressource angelangt.

Wir halten aber fest: Bei „normalem“ SSO ist zwingend ADFS involviert.

Das heißt umgekehrt auch: Wenn ADFS gerade nicht verfügbar ist (Ausfall, Wartung, etc.), ist kein Zugriff auf MS Online Ressourcen möglich!

Das ist bei „Enhanced SSO“ anders:

  • Nur beim ersten Zugriff läuft alles „normal“
  • Anschließend wird ein Primary Refresh Token (PRT) und darauf aufbauend Access Tokens zur Authentifizierung verwendet
  • ADFS wird fortan umgangen. Die Authentifizierung erfolgt mithilfe der o.a. Tokens direkt gegen Azure AD

Die Vorteile des erweiterten SSO liegen auf der Hand:

  • Der Zugriff auf MS Online Ressourcen funktioniert auch unabhängig von ADFS und dessen Verfügbarkeit
  • Es ist keine Eingabe von Anmeldedaten erforderlich, egal ob der Client im LAN steht oder im Internet
  • Die Authentifizierung erfolgt mit weniger Umwegen und läuft daher noch schneller

Einige weitere Vorteile der AAD Auto-Registrierung (Store App mit dem Work Account vorkonfiguriert, WSfB zeigt Private Store an, etc.) habe ich ja bereits oben erwähnt.

Darüber hinaus ist die AAD (Auto-)Registrierung übrigens die Grundlage für weitere interessante Features wie Windows Hello for Business, Enterprise State Roaming und Conditional Access – Details hierzu folgen in zukünftigen Blog-Einträgen.

Damit erst einmal genug für heute… In Teil 2 klären wir, welche Voraussetzungen für die AAD Auto-Registrierung erfüllt sein müssen und es gibt einen Überblick über den Ablauf. Ein paar Tipps zur Implementierung sind auch noch mit dabei, also: „Stay tuned“ 🙂

Viele Grüße

Alexander Zarenko