Primary Refresh Token (PRT)

Wenn Sie Office 365 oder Microsoft 365 mit Seamless Single Sign On nutzen, dann kommt das PRT ins Spiel. Anfangs hatte ich dieses Objekt auch nicht auf dem Schirm und dachte, dass mein Client einfach ein Kerberos-Ticket, welcher der KDC für das AZUREADSSOACC-Computerkonto ausgestellt hat, an die Cloud sendet. Aber das ist nur ein Teil der Lösung. Durch ein Troubleshooting bei einem Kunde mit AzureSSO ist aufgefallen, dass ein Client kein SSO nutzen konnte und letztlich war eine fehlerhafte Device Registration die Ursache.

Fehlerbild

Im dem Fall erfolgte die Anmeldung für alle Anwender noch per lokalem ADFS-Server, d.h. als federated Domain. Der Wechsel auf PTA erfolgt über die AzureAD-Funktion, ausgewählte Piloten nicht zum ADFS-Server zu senden. Das Verfahren wird von Microsoft auch "Staged Rollout" genannt.

Im dem Fall wurde der Anwender auf diesem PC aber nicht automatisch angemeldet. Er wurde aber auch nicht nach dem Anmeldenamen gefragt. Stattdessen hat der Browser in mir vorher noch nicht bekanntest Fenster gezeigt

Der Browser "kannte" den Anwender schon aber SSO hat wohl nicht funktioniert. Stattdessen durfte der Anwender nun wählen, ob er ein Kennwort eingibt, welches dann zum AzureAD gesendet wird oder er doch auf den noch installierten ADFS-Service wechseln will. Alle Kontrollen bezüglich Seamless Single Sign On haben aber keinen Fehler gezeigt, d.h. das AZUREADSSOACC-Konto war vorhanden und auch der Upload des Kerberos-Keys ist bei der Einrichtung mit ADSync erfolgt. Selbst ein KeyRollover hat funktioniert. Eigentlich hätte damit der Client im Firmennetzwerk mit einem Kerberos-Ticket eine Anmeldung erreichen müssen. Das war aber nicht der Fall und daher mussten wir weiter forschen.

Sehr schnell haben wir erkannt, dass der Client etwas anders war, denn Meldungen im Eventlog und die Ausgaben von DSREGCMD haben schnell gezeigt, dass der Computer nicht im AzureAD Mitglied war. Bislang bin ich davon ausgegangen, dass dies nicht relevant wäre aber da der Client eh im Active Directory war und Intune/MDM geplant war, sollte er ja "Hybrid Joined" sein.

Wir haben aber schnell gesehen, dass der Client eben diesen Prozess nicht sauber durchführen konnte. Der "Device State" war noch ok

Aber die Device Details lieferten einen 0x800704cf.

So richtig konnten wir den Fehler aber nicht zuordnen.

Der SSO-Status war aber auch ok:

Allerdings waren keine "Work Accounts" zu finden, die ich auf meinem PC hatte. Der PC war also "irgendwie" im AzureAD aber der darauf angemeldete Benutzer dann wieder nicht. Ein Versuch mit "DSREGCMD /LEAVE" wurde mit einer Fehlermeldung abgebrochen aber ein JOIN war auch nicht möglich. Wir haben daher im lokalen AD beim Computerkonto das "UserCertificate" entfernt und das Konto im AzureAD bereinigt und den Prozess mit DSREGCMD /JOIN dann noch mal ausgeführt. Kaum war das erfolgreich und ADSync hatte die Daten auch repliziert, funktionierte auch SSO.

Damit war klar, dass die fehlerhafte AzureAD-Registration die Nutzung von SSO verhindert hat aber wird haben nicht mehr ermitteln können, warum der Computer nicht sauber registriert war. Bei der Suche ist aber mehrfach der Begriff "Primary Refresh Token (PRT)" ins Spiel gekommen.

TGT für die Cloud?

Wenn Sie die Microsoft Beschreibung lesen, dann sehen Sie Analogien zum "Ticket Granting Ticket TGT" bei Kerberos im LAN. Nach einer erstmaligen Anmeldung erhält der Client ein "Master-Ticket", mit dem sich der Client dann für nachfolgende Authentifizierungen bei verschiedenen Diensten ein servicespezifisches Token besorgen kann

A Primary Refresh Token (PRT) is a key artifact of Azure AD authentication on Windows 10, Windows Server 2016 and later versions, iOS, and Android devices. It is a JSON Web Token (JWT) specially issued to Microsoft first party token brokers to enable single sign-on (SSO) across the applications used on those devices.
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token

In dem Artikel gibt es noch einige weitere Kernaussagen:

  • ... A PRT is an opaque blob sent from Azure AD whose contents are not known to any client components
  • ... A PRT is issued to users only on registered devices
  • .. a PRT is valid for 90 days and is continuously renewed as long as the user actively uses the device…

Damit war der Verdacht schon mal erhärtet, dass ohne eine AzureAD-Registrierung das Gerät und der Benutzer kein PRT bekommt.

Wo kann ich das Token finden?

Bei der Fehlersuche wollte ich natürlich wissen, ob der Client ein Token anfordert und wo es gespeichert wird. Ganz so einfach ist das aber nicht denn dann wäre es ja ein begehrtes Ziel für einen Angreifer oder eine Malware, dieses Token anderweitig zu verwenden. Einen einfachen Weg gibt es leider nicht. Mit DSREGCMD können Sie zumindest sehr leicht prüfen, ob der Client ein SSO-Token hat.

A PRT is an opaque blob sent from Azure AD whose contents are not known to any client components. You cannot see what’s inside a PRT.
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token

Aber die Aussage von Microsoft kann man natürlich so nicht stehen lassen, wenn man Administrator auf dem PC ist. Letztlich kann ich mit Fiddler und anderen Werkzeugen den HTTPS-Traffic analysieren und letztlich alle Daten irgendwie betrachten. Allerdings wird das PRT auch mit TPM gekoppelt, so dass das Übertragen zu einem anderen PC schon einmal erschwert wird. Genauer habe ich mir das aber nicht angeschaut. Es gibt aber natürlich schon einige tiefergehende Analysen des PRT.

PRT und weitere Tenants

Wenn ich alles richtig verstanden habe, dann ist das PRT an das Device und den Benutzer gebunden. Wenn ich mit als Gast in einem anderen Tenant anmelde, dann nutze ich aber weiterhin meine lokalen Anmeldedaten. Der Benutzer "Frank Carius (Net at Work)" kann durchaus in den Microsoft Tenant wechseln. Ich bin dort aber nicht "Frank Carius (Microsoft)" sondern weiterhin der Net at Work User. Dennoch bekomme ich von dort wohl ein PRT und natürlich Token , damit ich beim Wechseln nicht immer wieder meine Anmeldedaten eingeben muss. Mein Windows Desktop wird dann mit den anderen Tenants und Konten verknüpft und im Extremfall auch mit Policies versehen

Als Administrator kann ich über einen lokalen Eintrag in der Registrierung diese Verhalten unterbinden. Siehe dazu auch Teams Device Management

Einschätzung

Ich habe mich noch nicht eingehender mit dem PRT beschäftigt und mit Ausnahme dieses einen Kunden-Tickets hatte ich auch noch nie Probleme mit Computern und Anwender beim Einsatz von Seamless Single Sign On in Verbindung mit Pass Through Authentifizierung (PTA) oder Password Hash Sync (PHS). Meine Computer haben sich immer schön brav im AzureAD registriert und mit der richtigen ADSync-Einstellungen wurden Sie dann in der Device Registration als "Hybrid AzureAD-Joined" aufgeführt. In diesem Fall hat aber die Suche mit "DSREGCMD" aber so viele Hinweise gebracht, dass wir den Computer letztlich "richtig" aufnehmen konnten, ohne die eigentliche Ursache in der Vergangenheit klären zu können. Manchmal muss man aber nicht alles wissen, wenn eine Lösung gefunden wurde.

Weitere Links