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.

Renewal und Revocation

Tokens sind immer mit einem Verfallsdatum versehen. Das ist auch gut so, damit sich ein Anwender nach Ablauf der Zeit wieder neu anmelden muss. Allerdings bedeutet das nicht, dass nach dem Ablauf des Tokens zwingend eine neue Anmeldung erforderlich ist. Das System kann selbst ein Token erneuern.

PRT is valid for 14 days and is continuously renewed as long as the user actively uses the device.
https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#what-is-the-lifetime-of-a-prt

Das PRTG wird dann für die Anforderung weiterer Tokens mit verwendet

Azure AD WAM plugin uses the PRT to request refresh and access tokens for applications that rely on WAM for token requests.
https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#how-is-a-prt-used

Das PTG selbst erneuert sich selbst:

The CloudAP plugin renews the PRT every 4 hours during Windows sign in
An app requests WAM for an access token silently
- but there’s no refresh token available for that app. In this case, WAM uses the PRT to request a token for the app and gets back a new PRT in the response.
- but the PRT is invalid or Azure AD requires extra authorization ...WAM initiates an interactive logon .. and a new PRT is issued on successful authentication.
https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#how-is-a-prt-renewed

Bei der Verwendung einer Applikation bekommt Windows mit jeder neuen Ausstellung eines "Refresh Tokens" auch immer ein neues PRT geliefert. Wenn ein PC und der Anwender also angemeldet sind und arbeiten, dann werden mit jedem Request die Tokens ggfls. durch ein neues Token ersetzt, welches wieder die komplette Zeit gültig ist.

Refresh tokens have a longer lifetime than access tokens. The default lifetime for the refresh tokens is 24 hours for single page apps and 90 days for all other scenarios. Refresh tokens replace themselves with a fresh token upon every use
Quelle https://learn.microsoft.com/en-us/azure/active-directory/develop/refresh-tokens#refresh-token-lifetime

Das bedeutet im Regelfall, dass der Anwender sich erst erneut anmelden muss, wenn er länger als die Dauer des Renewal Token "offline" war, bzw. das entsprechende Programm nicht gelaufen ist. Wobei die 90 Tage hier schon dafür sorgen, dass die Anwender ganz selten sich neu anmelden müssen, es sei denn, das Token wird Serverseitig als ungültig erklärt. Dazu gibt es eine nette Tabelle bei Microsoft, wann das passiert.

Ein sicherer Weg ein Token ungültig zu machen, ist ein Revoke per Powershell durch den Anwender selbst oder den Administrator über "Invoke-MgInvalidateUserRefreshToken"

Damit sollte eine neue 2FA-Authentifizierung erzwungen werden.

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