Vad är en primär uppdateringstoken?

En primär uppdateringstoken (PRT) är en nyckelartefakt för Azure AD autentisering på Windows 10 eller senare, Windows Server 2016 och senare versioner, iOS- och Android-enheter. Det är en JSON Web Token (JWT) som särskilt utfärdats till Token Brokers från Microsoft för att aktivera enkel inloggning (SSO) för alla program som används på dessa enheter. I den här artikeln ger vi information om hur en pull-begäran utfärdas, används och skyddas på Windows 10 eller nyare enheter. Vi rekommenderar att du använder de senaste versionerna av Windows 10, Windows 11 och Windows Server 2019+ för att få bästa möjliga SSO-upplevelse.

Den här artikeln förutsätter att du redan förstår de olika enhetstillstånd som är tillgängliga i Azure AD och hur enkel inloggning fungerar i Windows 10 eller senare. Mer information om enheter i Azure AD finns i artikeln Vad är enhetshantering i Azure Active Directory?

Nyckelterminologi och komponenter

Följande Windows-komponenter spelar en viktig roll när det gäller att begära och använda en pull-begäran:

  • Molnautentiseringsprovider (CloudAP): CloudAP är den moderna autentiseringsprovidern för Windows-inloggning som verifierar att användare loggar in på en Windows 10 eller nyare enhet. CloudAP tillhandahåller ett plugin-ramverk som identitetsprovidrar kan bygga vidare på för att aktivera autentisering till Windows med hjälp av identitetsproviderns autentiseringsuppgifter.
  • Web Account Manager (WAM): WAM är standard token broker på Windows 10 eller nyare enheter. WAM tillhandahåller också ett plugin-ramverk som identitetsprovidrar kan bygga på och aktivera enkel inloggning för sina program som förlitar sig på den identitetsprovidern.
  • Azure AD CloudAP-plugin-program: Ett Azure AD specifikt plugin-program som bygger på CloudAP-ramverket och som verifierar användarautentiseringsuppgifter med Azure AD under Windows-inloggning.
  • Azure AD WAM-pluginprogram: Ett Azure AD specifikt plugin-program som bygger på WAM-ramverket och som gör det möjligt för enkel inloggning till program som förlitar sig på Azure AD för autentisering.
  • Dsreg: En Azure AD specifik komponent på Windows 10 eller senare, som hanterar enhetsregistreringsprocessen för alla enhetstillstånd.
  • Trusted Platform Module (TPM): En TPM är en maskinvarukomponent som är inbyggd i en enhet och som tillhandahåller maskinvarubaserade säkerhetsfunktioner för användar- och enhetshemligheter. Mer information finns i artikeln Översikt över Trusted Platform Module Technology.

Vad innehåller PRT?

En PRT innehåller anspråk som vanligtvis finns i alla Azure AD uppdateringstoken. Dessutom finns det vissa enhetsspecifika anspråk som ingår i PRT. Det här är skillnaderna:

  • Enhets-ID: En PRT utfärdas till en användare på en specifik enhet. Enhets-ID-anspråket deviceID avgör vilken enhet PRT utfärdades till användaren på. Det här anspråket utfärdas senare till token som hämtas via PRT. Enhets-ID-anspråket används för att fastställa auktorisering för villkorsstyrd åtkomst baserat på enhetens tillstånd eller efterlevnad.
  • Sessionsnyckel: Sessionsnyckeln är en krypterad symmetrisk nyckel som genereras av Azure AD-autentiseringstjänsten som utfärdas som en del av PRT. Sessionsnyckeln fungerar som bevis på innehav när en pull-begäran används för att hämta token för andra program.

Kan jag se vad som finns i en pull-begäran?

En PRT är en täckande blob som skickas från Azure AD vars innehåll inte är känt för några klientkomponenter. Du kan inte se vad som finns i en pull-begäran.

Hur utfärdas en pull-begäran?

Enhetsregistrering är en förutsättning för enhetsbaserad autentisering i Azure AD. En PRT utfärdas endast till användare på registrerade enheter. Mer detaljerad information om enhetsregistrering finns i artikeln Windows Hello för företag och Enhetsregistrering. Under enhetsregistreringen genererar dsreg-komponenten två uppsättningar kryptografiska nyckelpar:

  • Enhetsnyckel (dkpub/dkpriv)
  • Transportnyckel (tkpub/tkpriv)

De privata nycklarna är bundna till enhetens TPM om enheten har en giltig och fungerande TPM, medan de offentliga nycklarna skickas till Azure AD under enhetsregistreringsprocessen. Dessa nycklar används för att verifiera enhetens tillstånd under PRT-begäranden.

PRT utfärdas under användarautentisering på en Windows 10 eller nyare enhet i två scenarier:

  • Azure AD ansluten eller Hybrid Azure AD ansluten: En PRT utfärdas under Windows-inloggning när en användare loggar in med sina organisationsautentiseringsuppgifter. En PRT utfärdas med alla Windows 10 eller nyare autentiseringsuppgifter som stöds, till exempel lösenord och Windows Hello för företag. I det här scenariot är Azure AD CloudAP-plugin-programmet den primära utfärdaren för PRT.
  • Azure AD registrerad enhet: En PRT utfärdas när en användare lägger till ett sekundärt arbetskonto till sin Windows 10 eller senare enhet. Användare kan lägga till ett konto i Windows 10 eller senare på två olika sätt –
    • Lägga till ett konto via uppmaningen Tillåt att min organisation hanterar min enhet när jag har loggat in i en app (till exempel Outlook)
    • Lägga till ett konto från Inställningar Konton>>Åtkomst till arbete eller Skolanslutning>

I Azure AD registrerade enhetsscenarier är Azure AD WAM-plugin-programmet den primära utfärdaren för PRT eftersom Windows-inloggning inte sker med det här Azure AD kontot.

Anteckning

Identitetsprovidrar från tredje part måste ha stöd för WS-Trust protokoll för att aktivera PRT-utfärdande på Windows 10 eller nyare enheter. Utan WS-Trust kan PRT inte utfärdas till användare på Hybrid Azure AD anslutna eller Azure AD anslutna enheter. På ADFS krävs endast användarnamnmixade slutpunkter. Både adfs/services/trust/2005/windowstransport och adfs/services/trust/13/windowstransport bör endast aktiveras som intranätuppkopplade slutpunkter och får INTE exponeras som extranätsinriktade slutpunkter via Programproxy.

Anteckning

Azure AD principer för villkorsstyrd åtkomst utvärderas inte när PRT utfärdas.

Anteckning

Vi stöder inte tredjepartsleverantörer av autentiseringsuppgifter för utfärdande och förnyelse av Azure AD PRT.

Vad är livslängden för en pull-begäran?

När prt har utfärdats är den giltig i 14 dagar och förnyas kontinuerligt så länge användaren aktivt använder enheten.

Hur används en pull-begäran?

En PRT används av två viktiga komponenter i Windows:

  • Azure AD CloudAP-plugin-program: Under Windows-inloggning begär Azure AD CloudAP-plugin-programmet en PRT från Azure AD med hjälp av de autentiseringsuppgifter som användaren anger. Den cachelagrar också PRT för att aktivera cachelagrad inloggning när användaren inte har åtkomst till en Internetanslutning.
  • Azure AD WAM-pluginprogram: När användare försöker komma åt program använder Azure AD WAM-plugin-programmet PRT för att aktivera enkel inloggning på Windows 10 eller senare. Azure AD WAM-plugin-programmet använder PRT för att begära uppdaterings- och åtkomsttoken för program som förlitar sig på WAM för tokenbegäranden. Det aktiverar också enkel inloggning i webbläsare genom att mata in PRT i webbläsarbegäranden. Webbläsar-SSO i Windows 10 eller senare stöds på Microsoft Edge (internt), Chrome (via Windows 10-konton eller Office Online-tillägg) eller Mozilla Firefox v91+ (Firefox Windows SSO-inställning)

    Anteckning

    I fall där en användare har två konton från samma Azure AD klientorganisation som är inloggad i ett webbläsarprogram, tillämpas även enhetsautentiseringen som tillhandahålls av PRT för det primära kontot automatiskt på det andra kontot. Därför uppfyller det andra kontot även alla enhetsbaserade principer för villkorsstyrd åtkomst i klientorganisationen.

Hur förnyas en pull-begäran?

En PRT förnyas med två olika metoder:

  • Azure AD CloudAP-plugin-programmet var fjärde timme: CloudAP-plugin-programmet förnyar PRT var fjärde timme under Windows-inloggningen. Om användaren inte har någon Internetanslutning under den tiden förnyar CloudAP-plugin-programmet PRT när enheten har anslutits till Internet.
  • Azure AD WAM-plugin-program under apptokenbegäranden: WAM-plugin-programmet aktiverar enkel inloggning på Windows 10 eller nyare enheter genom att aktivera förfrågningar om tyst token för program. WAM-plugin-programmet kan förnya PRT under dessa tokenbegäranden på två olika sätt:
    • En app begär WAM för en åtkomsttoken tyst, men det finns ingen uppdateringstoken tillgänglig för den appen. I det här fallet använder WAM PRT för att begära en token för appen och hämtar tillbaka en ny pull-begäran i svaret.
    • En app begär WAM för en åtkomsttoken men PRT är ogiltig eller Azure AD kräver ytterligare auktorisering (till exempel Azure AD Multi-Factor Authentication). I det här scenariot initierar WAM en interaktiv inloggning som kräver att användaren autentiserar om eller tillhandahåller ytterligare verifiering och en ny PRT utfärdas vid lyckad autentisering.

I en ADFS-miljö krävs inte direkt siktlinje till domänkontrollanten för att förnya PRT. PRT-förnyelse kräver endast /adfs/services/trust/2005/usernamemixed och /adfs/services/trust/13/usernamemixed-slutpunkter som är aktiverade på proxyn med hjälp av WS-Trust protokoll.

Windows-transportslutpunkter krävs endast för lösenordsautentisering när ett lösenord ändras, inte för PRT-förnyelse.

Anteckning

Azure AD principer för villkorsstyrd åtkomst utvärderas inte när pull-begärandena förnyas.

Viktiga överväganden

  • En PRT utfärdas och förnyas endast under intern appautentisering. En PULL-begäran förnyas inte eller utfärdas inte under en webbläsarsession.
  • I Azure AD anslutna och hybrid Azure AD anslutna enheter är CloudAP-plugin-programmet den primära utfärdaren för prt. Om en PRT förnyas under en WAM-baserad tokenbegäran skickas PRT tillbaka till CloudAP-plugin-programmet, som verifierar giltigheten för PRT med Azure AD innan den godkänns.

Hur skyddas PRT?

En PRT skyddas genom att den binds till den enhet som användaren har loggat in på. Azure AD och Windows 10 eller senare aktiverar PRT-skydd med hjälp av följande metoder:

  • Under den första inloggningen: Under den första inloggningen utfärdas en PRT genom signeringsbegäranden med hjälp av enhetsnyckeln som genereras kryptografiskt under enhetsregistreringen. På en enhet med en giltig och fungerande TPM skyddas enhetsnyckeln av TPM som förhindrar skadlig åtkomst. En PRT utfärdas inte om motsvarande enhetsnyckelsignatur inte kan verifieras.
  • Under tokenbegäranden och förnyelse: När en pull-begäran utfärdas utfärdar Azure AD även en krypterad sessionsnyckel till enheten. Den krypteras med den kollektivtrafiknyckel (tkpub) som genereras och skickas till Azure AD som en del av enhetsregistreringen. Den här sessionsnyckeln kan bara dekrypteras av den privata transportnyckeln (tkpriv) som skyddas av TPM. Sessionsnyckeln är POP-nyckeln (Proof-of-Possession) för alla begäranden som skickas till Azure AD. Sessionsnyckeln skyddas också av TPM och ingen annan OS-komponent kan komma åt den. Tokenbegäranden eller PRT-förnyelsebegäranden signeras på ett säkert sätt av den här sessionsnyckeln via TPM och kan därför inte manipuleras. Azure AD ogiltigförklarar alla begäranden från enheten som inte är signerade av motsvarande sessionsnyckel.

Genom att skydda dessa nycklar med TPM förbättrar vi säkerheten för PRT från skadliga aktörer som försöker stjäla nycklarna eller spela upp PRT igen. Därför förbättrar användningen av en TPM avsevärt säkerheten för Azure AD Ansluten, Hybrid Azure AD ansluten och Azure AD registrerade enheter mot stöld av autentiseringsuppgifter. För prestanda och tillförlitlighet är TPM 2.0 den rekommenderade versionen för alla Azure AD scenarier för enhetsregistrering på Windows 10 eller senare. Från och med uppdateringen Windows 10 1903 använder Azure AD inte TPM 1.2 för någon av ovanstående nycklar på grund av tillförlitlighetsproblem.

Hur skyddas apptoken och webbläsarcookies?

Apptoken: När en app begär token via WAM utfärdar Azure AD en uppdateringstoken och en åtkomsttoken. WAM returnerar dock bara åtkomsttoken till appen och skyddar uppdateringstoken i cacheminnet genom att kryptera den med användarens DPAPI-nyckel (Data Protection Application Programming Interface). WAM använder på ett säkert sätt uppdateringstoken genom att signera begäranden med sessionsnyckeln för att utfärda ytterligare åtkomsttoken. DPAPI-nyckeln skyddas av en Azure AD baserad symmetrisk nyckel i Azure AD själv. När enheten behöver dekryptera användarprofilen med DPAPI-nyckeln tillhandahåller Azure AD DPAPI-nyckeln krypterad av sessionsnyckeln, som CloudAP-plugin-programmet begär att TPM dekrypterar. Den här funktionen säkerställer konsekvens när det gäller att skydda uppdateringstoken och undviker program som implementerar sina egna skyddsmekanismer.

Webbläsarcookies: I Windows 10 eller senare stöder Azure AD webbläsar-SSO i Internet Explorer och Microsoft Edge internt, i Google Chrome via Windows 10-kontotillägget och i Mozilla Firefox v91+ via en webbläsarinställning. Säkerheten är skapad inte bara för att skydda cookies utan även de slutpunkter som cookies skickas till. Webbläsarcookies skyddas på samma sätt som en PRT genom att använda sessionsnyckeln för att signera och skydda cookies.

När en användare initierar en webbläsarinteraktion anropar webbläsaren (eller tillägget) en COM-intern klientvärd. Den interna klientvärden ser till att sidan kommer från en av de tillåtna domänerna. Webbläsaren kan skicka andra parametrar till den interna klientvärden, inklusive en nonce, men den interna klientvärden garanterar validering av värdnamnet. Den interna klientvärden begär en PRT-cookie från CloudAP-plugin-programmet, som skapar och signerar den med den TPM-skyddade sessionsnyckeln. Eftersom PRT-cookien signeras av sessionsnyckeln är det mycket svårt att manipulera. Denna PRT-cookie ingår i begärandehuvudet för Azure AD för att verifiera enheten den kommer från. Om du använder Webbläsaren Chrome kan endast tillägget som uttryckligen definierats i den inbyggda klientvärdens manifest anropa det så att godtyckliga tillägg inte kan göra dessa begäranden. När Azure AD verifierar PRT-cookien utfärdar den en sessionscookie till webbläsaren. Den här sessionscookien innehåller också samma sessionsnyckel som utfärdats med en PRT. Under efterföljande begäranden valideras sessionsnyckeln som effektivt binder cookien till enheten och förhindrar repriser från någon annanstans.

När får en PRT ett MFA-anspråk?

En PRT kan få ett MFA-anspråk (multifaktorautentisering) i specifika scenarier. När en MFA-baserad PRT används för att begära token för program överförs MFA-anspråket till dessa apptoken. Den här funktionen ger användarna en sömlös upplevelse genom att förhindra MFA-utmaningar för varje app som kräver det. En PRT kan få ett MFA-anspråk på följande sätt:

  • Logga in med Windows Hello för företag: Windows Hello för företag ersätter lösenord och använder kryptografiska nycklar för att tillhandahålla stark tvåfaktorautentisering. Windows Hello för företag är specifikt för en användare på en enhet och kräver själv att MFA etableras. När en användare loggar in med Windows Hello för företag får användarens PRT ett MFA-anspråk. Det här scenariot gäller även för användare som loggar in med smartkort om smartkortautentisering genererar ett MFA-anspråk från ADFS.
    • Eftersom Windows Hello för företag betraktas som multifaktorautentisering uppdateras MFA-anspråket när själva PRT:en uppdateras, så MFA-varaktigheten utökas kontinuerligt när användarna loggar in med Windows Hello för företag.
  • MFA under interaktiv WAM-inloggning: Under en tokenbegäran via WAM, om en användare måste göra MFA för att komma åt appen, präglas PRT som förnyas under den här interaktionen med ett MFA-anspråk.
    • I det här fallet uppdateras inte MFA-anspråket kontinuerligt, så MFA-varaktigheten baseras på den livslängd som angetts i katalogen.
    • När en tidigare befintlig PRT och RT används för åtkomst till en app betraktas PRT och RT som det första autentiseringsbeviset. En ny AT krävs med ett andra bevis och ett präglat MFA-anspråk. Detta kommer också att utfärda en ny PRT och RT.

Windows 10 eller senare underhåller du en partitionerad lista med PRT för varje autentiseringsuppgift. Så det finns en PRT för var och en av Windows Hello för företag, lösenord eller smartkort. Den här partitioneringen säkerställer att MFA-anspråk isoleras baserat på de autentiseringsuppgifter som används och inte blandas ihop under tokenbegäranden.

Hur ogiltigförklaras en PRT?

En PRT är ogiltig i följande scenarier:

  • Ogiltig användare: Om en användare tas bort eller inaktiveras i Azure AD är deras PRT ogiltig och kan inte användas för att hämta token för program. Om en borttagen eller inaktiverad användare redan har loggat in på en enhet tidigare loggar cachelagrad inloggning in dem tills CloudAP är medvetet om deras ogiltiga tillstånd. När CloudAP har fastställt att användaren är ogiltig blockerar den efterföljande inloggningar. En ogiltig användare blockeras automatiskt från att logga in på nya enheter som inte har cachelagrat sina autentiseringsuppgifter.
  • Ogiltig enhet: Om en enhet tas bort eller inaktiveras i Azure AD är den PRT som hämtas på enheten ogiltig och kan inte användas för att hämta token för andra program. Om en användare redan är inloggad på en ogiltig enhet kan de fortsätta att göra det. Men alla token på enheten är ogiltiga och användaren har inte enkel inloggning till några resurser från den enheten.
  • Lösenordsändring: När en användare har ändrat sitt lösenord ogiltigförklaras den PRT som erhållits med det tidigare lösenordet av Azure AD. Lösenordsändring resulterar i att användaren får en ny PRT. Den här ogiltigförklaringen kan ske på två olika sätt:
    • Om användaren loggar in på Windows med sitt nya lösenord tar CloudAP bort den gamla PRT:en och begär Azure AD att utfärda en ny PRT med sitt nya lösenord. Om användaren inte har någon Internetanslutning kan det nya lösenordet inte verifieras. Windows kan kräva att användaren anger sitt gamla lösenord.
    • Om en användare har loggat in med sitt gamla lösenord eller ändrat sitt lösenord efter att ha loggat in i Windows används den gamla PRT:n för wam-baserade tokenbegäranden. I det här scenariot uppmanas användaren att autentisera igen under WAM-tokenbegäran och en ny PRT utfärdas.
  • TPM-problem: Ibland kan en enhets TPM vackla eller misslyckas, vilket leder till otillgänglighet för nycklar som skyddas av TPM. I det här fallet kan enheten inte hämta en PRT eller begära token med hjälp av en befintlig PRT eftersom den inte kan bevisa innehav av kryptografiska nycklar. Därför ogiltigförklaras alla befintliga PRT av Azure AD. När Windows 10 identifierar ett fel initieras ett återställningsflöde för att registrera enheten igen med nya kryptografiska nycklar. Med Hybrid Azure Ad-anslutning, precis som den första registreringen, sker återställningen tyst utan användarindata. För Azure AD anslutna eller Azure AD registrerade enheter måste återställningen utföras av en användare som har administratörsbehörighet på enheten. I det här scenariot initieras återställningsflödet av en Windows-prompt som hjälper användaren att återställa enheten.

Detaljerade flöden

Följande diagram illustrerar den underliggande informationen när du utfärdar, förnyar och använder en PRT för att begära en åtkomsttoken för ett program. De här stegen beskriver också hur ovan nämnda säkerhetsmekanismer tillämpas under dessa interaktioner.

PRT-utfärdande vid första inloggningen

PRT-utfärdande vid första inloggningen i ett detaljerat flöde

Anteckning

I Azure AD anslutna enheter sker Azure AD PRT-utfärdande (steg A-F) synkront innan användaren kan logga in på Windows. I hybrid Azure AD anslutna enheter är lokal Active Directory den primära utfärdaren. Så användaren kan logga in hybrid Azure AD anslutna Windows när de kan hämta en TGT för att logga in, medan PRT-utfärdandet sker asynkront. Det här scenariot gäller inte för Azure AD registrerade enheter eftersom inloggning inte använder Azure AD autentiseringsuppgifter.

Steg Description
A Användaren anger sitt lösenord i inloggningsgränssnittet. Inloggningsgränssnittet skickar autentiseringsuppgifterna i en autentiseringsbuffert till LSA, som i sin tur skickar dem internt till CloudAP. CloudAP vidarebefordrar den här begäran till CloudAP-plugin-programmet.
B CloudAP-plugin-programmet initierar en begäran om sfäridentifiering för att identifiera identitetsprovidern för användaren. Om användarens klientorganisation har en federationsproviderkonfiguration returnerar Azure AD federationsproviderns MEX-slutpunkt (Metadata Exchange Endpoint). Annars returnerar Azure AD att användaren hanteras som anger att användaren kan autentisera med Azure AD.
C Om användaren hanteras får CloudAP nonce från Azure AD. Om användaren är federerad begär CloudAP-plugin-programmet en SAML-token från federationsprovidern med användarens autentiseringsuppgifter. Nonce begärs innan SAML-token skickas till Azure AD.
D CloudAP-plugin-programmet skapar autentiseringsbegäran med användarens autentiseringsuppgifter, nonce och ett asynkront omfång, signerar begäran med enhetsnyckeln (dkpriv) och skickar den till Azure AD. I en federerad miljö använder CloudAP-plugin-programmet SAML-token som returneras av federationsprovidern i stället för användarens autentiseringsuppgifter.
E Azure AD verifierar användarens autentiseringsuppgifter, nonce och enhetssignatur, verifierar att enheten är giltig i klientorganisationen och utfärdar krypterad PRT. Tillsammans med PRT utfärdar Azure AD också en symmetrisk nyckel, som kallas sessionsnyckeln krypterad av Azure AD med hjälp av transportnyckeln (tkpub). Dessutom är sessionsnyckeln också inbäddad i PRT. Den här sessionsnyckeln fungerar som PoP-nyckel (Proof-of-possession) för efterföljande begäranden med PRT.
F CloudAP-plugin-programmet skickar den krypterade PRT- och sessionsnyckeln till CloudAP. CloudAP begär att TPM dekrypterar sessionsnyckeln med hjälp av transportnyckeln (tkpriv) och krypterar om den med hjälp av TPM:s egen nyckel. CloudAP lagrar den krypterade sessionsnyckeln i cacheminnet tillsammans med PRT.

PRT-förnyelse i efterföljande inloggningar

PRT-förnyelse i efterföljande inloggningar

Steg Description
A Användaren anger sitt lösenord i inloggningsgränssnittet. Inloggningsgränssnittet skickar autentiseringsuppgifterna i en autentiseringsbuffert till LSA, som i sin tur skickar dem internt till CloudAP. CloudAP vidarebefordrar den här begäran till CloudAP-plugin-programmet.
B Om användaren tidigare har loggat in på användaren initierar Windows cachelagrad inloggning och validerar autentiseringsuppgifter för att logga in användaren. Var fjärde timme initierar CloudAP-plugin-programmet PRT-förnyelse asynkront.
C CloudAP-plugin-programmet initierar en begäran om sfäridentifiering för att identifiera identitetsprovidern för användaren. Om användarens klientorganisation har en federationsproviderkonfiguration returnerar Azure AD federationsproviderns MEX-slutpunkt (Metadata Exchange Endpoint). Annars returnerar Azure AD att användaren hanteras som anger att användaren kan autentisera med Azure AD.
D Om användaren är federerad begär CloudAP-plugin-programmet en SAML-token från federationsprovidern med användarens autentiseringsuppgifter. Nonce begärs innan SAML-token skickas till Azure AD. Om användaren hanteras får CloudAP direkt nonce från Azure AD.
E CloudAP-plugin-programmet skapar autentiseringsbegäran med användarens autentiseringsuppgifter, nonce och befintlig PRT, signerar begäran med sessionsnyckeln och skickar den till Azure AD. I en federerad miljö använder CloudAP-plugin-programmet SAML-token som returneras av federationsprovidern i stället för användarens autentiseringsuppgifter.
F Azure AD verifierar signaturen för sessionsnyckeln genom att jämföra den med sessionsnyckeln som är inbäddad i PRT, verifierar nonce och verifierar att enheten är giltig i klientorganisationen och utfärdar en ny PRT. Som vi sett tidigare åtföljs PRT igen med sessionsnyckeln krypterad av transportnyckeln (tkpub).
G CloudAP-plugin-programmet skickar den krypterade PRT- och sessionsnyckeln till CloudAP. CloudAP begär att TPM dekrypterar sessionsnyckeln med hjälp av transportnyckeln (tkpriv) och krypterar om den med hjälp av TPM:s egen nyckel. CloudAP lagrar den krypterade sessionsnyckeln i cacheminnet tillsammans med PRT.

Anteckning

En PRT kan förnyas externt utan behov av en VPN-anslutning när användarnamnblandade slutpunkter aktiveras externt.

PRT-användning vid begäranden om apptoken

PRT-användning vid begäranden om apptoken

Steg Description
A Ett program (till exempel Outlook, OneNote osv.) initierar en tokenbegäran till WAM. WAM ber i sin tur Azure AD WAM-plugin-programmet att betjäna tokenbegäran.
B Om en uppdateringstoken för programmet redan är tillgänglig använder Azure AD WAM-plugin-programmet den för att begära en åtkomsttoken. För att tillhandahålla bevis på enhetsbindning signerar WAM-plugin-programmet begäran med sessionsnyckeln. Azure AD verifierar sessionsnyckeln och utfärdar en åtkomsttoken och en ny uppdateringstoken för appen, krypterad av sessionsnyckeln. WAM-plugin-programmet begär att CloudAP-plugin-programmet dekrypterar token, vilket i sin tur begär att TPM dekrypterar med hjälp av sessionsnyckeln, vilket resulterar i att WAM-plugin-programmet hämtar båda token. Därefter tillhandahåller WAM-plugin-programmet endast åtkomsttoken till programmet, medan det krypterar om uppdateringstoken med DPAPI och lagrar den i sin egen cache
C Om en uppdateringstoken för programmet inte är tillgänglig använder Azure AD WAM-plugin-programmet PRT för att begära en åtkomsttoken. För att tillhandahålla bevis på innehav signerar WAM-plugin-programmet begäran som innehåller PRT med sessionsnyckeln. Azure AD verifierar signaturen för sessionsnyckeln genom att jämföra den med sessionsnyckeln som är inbäddad i PRT, verifierar att enheten är giltig och utfärdar en åtkomsttoken och en uppdateringstoken för programmet. Dessutom kan Azure AD utfärda en ny PRT (baserat på uppdateringscykel), som alla krypteras av sessionsnyckeln.
D WAM-plugin-programmet begär att CloudAP-plugin-programmet dekrypterar token, vilket i sin tur begär att TPM dekrypterar med hjälp av sessionsnyckeln, vilket resulterar i att WAM-plugin-programmet hämtar båda token. Därefter tillhandahåller WAM-plugin-programmet endast åtkomsttoken till programmet, medan det krypterar om uppdateringstoken med DPAPI och lagrar den i sin egen cache. WAM-plugin-programmet använder uppdateringstoken framöver för det här programmet. WAM-plugin-programmet ger också tillbaka den nya PRT till CloudAP-plugin-programmet, som validerar PRT med Azure AD innan den uppdateras i sin egen cache. CloudAP-plugin-programmet använder den nya PRT:n framöver.
E WAM tillhandahåller den nyligen utfärdade åtkomsttoken till WAM, som i sin tur ger tillbaka den till det anropande programmet

Enkel inloggning i webbläsare med PRT

Enkel inloggning i webbläsare med PRT

Steg Description
A Användaren loggar in i Windows med sina autentiseringsuppgifter för att få en PRT. När användaren öppnar webbläsaren läser webbläsaren (eller tillägget) in URL:erna från registret.
B När en användare öppnar en Azure AD inloggnings-URL verifierar webbläsaren eller tillägget URL:en med de som hämtas från registret. Om de matchar anropar webbläsaren den interna klientvärden för att hämta en token.
C Den interna klientvärden verifierar att URL:erna tillhör Microsofts identitetsprovidrar (Microsoft-konto eller Azure AD), extraherar en nonce som skickas från URL:en och anropar CloudAP-plugin-programmet för att hämta en PRT-cookie.
D CloudAP-plugin-programmet skapar PRT-cookien, loggar in med den TPM-bundna sessionsnyckeln och skickar tillbaka den till den interna klientvärden.
E Den interna klientvärden returnerar den här PRT-cookien till webbläsaren, som inkluderar den som en del av begärandehuvudet x-ms-RefreshTokenCredential och begär token från Azure AD.
F Azure AD verifierar signaturen för sessionsnyckeln på PRT-cookien, verifierar nonce, verifierar att enheten är giltig i klientorganisationen och utfärdar en ID-token för webbsidan och en krypterad sessionscookie för webbläsaren.

Anteckning

Flödet för enkel inloggning i webbläsare som beskrivs i stegen ovan gäller inte för sessioner i privata lägen som InPrivate i Microsoft Edge, Incognito i Google Chrome (när du använder Microsoft-konton eller Office Online-tillägg) eller i privat läge i Mozilla Firefox v91+

Nästa steg

Mer information om hur du felsöker PRT-relaterade problem finns i artikeln Felsöka Azure Active Directory-hybridanslutningar Windows 10 eller nyare och Windows Server 2016 enheter.