Single Sign-On für Azure, Microsoft 365 und hybride Umgebungen: 3 Verfahren im Überblick


    Tags: , , ,

    Azure AD hybridDas Primary Refresh Token dient dem Single Sign-on (SSO) auf moder­nen Rechnern mit Windows 10, Server 2016 oder 2019. Es hat damit eine ähn­liche Aufgabe wie das Kerberos Ticket Granting Ticket (TGT) on-prem bei der Authenti­fizierung gegen die AD DS. Beim SSO in hybrider Struktur sieht Microsoft drei Ver­fahren vor.

    Damit Nutzer oder Geräte, die im Azure AD (hybrid) registriert sind, auf M365-Apps wie Teams zugreifen können, benötigen sie ein Zugriffstoken (Access Token). Dieses ist im Fall der Cloud-Applikationen das Primary Refresh Token (PRT) und wird für das Single Sign-On ausgestellt. Dafür gibt es drei hybride Identität-Sign-On Methoden.

    Betrachten wir zu Beginn noch einmal das lokale Active Directory und die Applikationen im Firmen­netzwerk. Auch hier ist der optimale Weg, sich mit den zentral gespeicherten Zugangsdaten aus dem AD gegenüber sämtlichen Applikationen zu authentifizieren. So wird die separate Authentifizierung an einer Vielzahl von Apps vermieden.

    Diesen Komfort möchten wir auch bei unseren Cloud-Anwendungen nutzen. Im Folgenden gehe ich auf die Möglichkeiten ein, die sich dafür bieten.

    Password Hash Synchronisation

    Hierbei synchronisieren wir mittels installiertem AAD Connect den Hash des Hash eines Benutzer-Passwortes aus den Active Directory Domain Services (AD DS) nach Azure Active Directory (AAD). Der Benutzer meldet sich dann mit seinen gewohnten Zugangsdaten aus dem lokalen AD an den Cloud-Applikationen an.

    Active Directory Federation Services (AD FS)

    Verwenden wir lokale AD FS-Server, dann authentifizieren sich die Benutzer immer on-prem. AD FS geht hierbei eine Vertrauens­stellung mit dem öffentlichen Azure AD ein. Die aufwändige Wartung der meist redundanten AD FS-Server-Infrastruktur obliegt dem Infrastruktur-Team.

    Pass-Through Authentication (PTA)

    PTA setzt auf lokal installierte Agenten, welche die Authentifizierung zwischen den lokalen AD DS und dem AAD regeln. Passwörter werden hierbei lokal vorgehalten und nicht in die Cloud synchronisiert. Der Wartungs­aufwand für die Agenten ist gegenüber AD FS vergleichsweise gering.

    Prüfung der PRT-Ausstellung

    Ob ein PRT auf einem hybrid joined Device ausgestellt wurde, lässt sich via

    DSREGCMD.exe /STATUS

    herausfinden. Das Primary Refresh Token ist ein JSON Web Token und beinhaltet Informationen zum User und Device. Es hat eine Gültigkeit von 90 Tagen, wenn es permanent in Gebrauch ist. Danach wird es neu angefordert. Liegt es 14 Tage brach, verfällt es und muss erneuert werden.

    Ändert sich ein Benutzer­passwort, dann wird das PRT außerhalb dieser Zeitfenster erneuert. Zusammen mit dem PRT wird ein Session Key generiert und in das Device-TPM importiert. Es ist somit an das Gerät gebunden und bei einem Diebstahl vor Missbrauch geschützt.

    Rechner mit einem Hybrid Azure AD Join

    Folgender Screenshot zeigt den gleichzeitigen Azure-AD-Join und AD-Join des Geräts in meine lokale Labor-Domäne.

    Zugehöriger Device State in der Ausgabe von DSREGCMD

    Öffnet man eine Applikation für einen SSO, dann wird das PRT mit einer Gültigkeitsdauer von 14 Tagen ausgestellt. Alle vier Stunden findet ein Refresh statt.

    Ausgestelltes PRT (hier noch Windows 10 20H2)

    Events rund um PRT und AAD

    Wie bereits erwähnt, ist DSREGCMD.exe das Mittel der Wahl beim Troubleshooting zum hybrid join oder PRT. Doch zusätzlich lohnt sich ein Blick auf die Events, die auch hierbei generiert werden.

    Startet man den Event Viewer, dann führt der Weg über Applications and Services Logs => Microsoft => Windows zu User Device Registration => Admin.

    Operational Event Logs, auch zum PRT

    Wie der Name schon verrät, liefert das Log Einträge zur Device Registration in AAD. Weitere Events finden sich unter Applications and Services Logs => Microsoft => Windows zur AAD => Operational.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Marcel Küppers

    Marcel Küppers arbeitet seit 25 Jahren in der IT, aktuell konzeptionell, zuvor als Consultant und Infra­structure Architect unter anderem für den japani­schen Konzern JTEKT/TOYODA mit Verant­wortung über die Europa­standorte Krefeld und Paris.
    Da­rüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Loka­tionen des Kon­zerns mit und ist spezia­lisiert auf hoch­verfügbare virtuali­sierte Microsoft-Umgebungen plus Hybrid Cloud Solutions.
    Zertifizierungen: MS Specialist und MCTS für Hyper-V/SCVMM, MCSE, MCITP, MCSA. Zusätzlich zertifiziert für PRINCE2 Projektmanagementmethode.

    // Kontakt: E-Mail, Twitter, LinkedIn //

    Ähnliche Beiträge

    Weitere Links