プライマリ更新トークン (PRT) について

PRT は Windows 10 以降のデバイス上でのユーザー認証中に発行され、2 つのシナリオがあります。

• Microsoft Entra 参加済み または Microsoft Entra ハイブリッド参加済み: ユーザーが組織の資格情報でサインインすると、Windows サインイン中に PRT が発行されます。 PRT は、パスワードや Windows Hello for Business など、Windows 10 以降でサポートされているすべての資格情報と共に発行されます。 このシナリオでは、Microsoft Entra CloudAP プラグインが PRT の主要な機関です
• Microsoft Entra 登録済みデバイス: ユーザーが Windows 10 以降のデバイスにセカンダリ職場アカウントを追加すると、PRT が発行されます。 ユーザーは、次の 2 つの方法で Windows 10 以降にアカウントを追加できます。
  • アプリ (Outlook など) にサインインした後で、 [組織がデバイスを管理できるようにする] プロンプトからアカウントを追加する
  • [設定]>[アカウント]>[Access Work or School](職場または学校にアクセスする)>[接続] からアカウントを追加する

Microsoft Entra 登録済みデバイス のシナリオでは、Windows サインインがこの Microsoft Entra アカウントで行われていないため、Microsoft Entra WAM プラグインは PRT の主要な機関です。

macOS Platform Single Sign-on (PSSO) は、ユーザーが Microsoft Entra ID 資格情報を使用して Mac デバイスにサインインできるようにする、Microsoft の Enterprise SSO プラグインである macOS 用プラットフォーム資格情報を搭載した新機能です。

PSSO プライマリ更新トークン (PRT) は、プラットフォーム SSO 登録を正常に完了した Entra 参加済み macOS デバイスにのみ発行されます。 この登録プロセス中に、macOS はセキュリティで保護されたエンクレーブに基づく暗号化キー ペアを生成します。1 つはデバイス署名用、もう 1 つはデバイス暗号化用です。 公開キー参照は、SSO 拡張機能と共有されます。

SSO 拡張機能では、これらのキーを使用して、Microsoft Entra ID Device Registration Service を使用してデバイスの登録を完了します。 次に、PRT 取得に必要なパラメーターを使用して Apple の loginConfiguration API を構成します。

登録が正常に完了すると、macOS はデバイス署名キーで署名されたサインイン要求を開始します。 Microsoft Entra ID は、要求、デバイス署名キー、および関連するパラメーターを検証し、PRT 応答を発行します。 macOS は、Device Encryption キーを使用してこの応答を復号化し、PRT を格納し、SSO 拡張機能で使用できるようにします。 サインイン要求は、PSSO 登録済み macOS でのユーザー認証中に送信されます。

iOS、macOS、および Android では、 ブローカーが存在する場合、Microsoft Edge の未登録 PRT と登録済み PRT の両方がサポートされます。

Linux では、ブローカーが存在する場合、Microsoft Edge の未登録 PRT と登録済み PRT の両方がサポートされます。

Windows で、PRT は 2 つの主要コンポーネントによって使用されます。

• Microsoft Entra CloudAP プラグイン:Windows サインイン時に、Microsoft Entra CloudAP プラグインは、ユーザーが入力した資格情報を使用して Microsoft Entra ID に PRT を要求します。 また、PRT をキャッシュして、ユーザーがインターネット接続にアクセスできないときのキャッシュ サインインを有効にします。
• Microsoft Entra WAM プラグイン: ユーザーがアプリケーションにアクセスしようとすると、Microsoft Entra WAM プラグインは PRT を使用して、Windows 10 以降で SSO を有効にします。 Microsoft Entra WAM プラグインは、トークン要求に WAM を使用するアプリケーションに対して、PRT を使用して更新トークンおよびアクセス トークンを要求します。 また、ブラウザーの要求に PRT を挿入して、ブラウザー上で SSO を有効にします。 Windows 10 以降のブラウザー SSO は、Microsoft Edge (ネイティブ)、Chrome ( Windows 10 アカウント 拡張機能経由)、Mozilla Firefox v91+ (Firefox Windows SSO 設定) でサポートされています。

  注

  ユーザーが同じ Microsoft Entra テナントの 2 つのアカウントでブラウザー アプリケーションにサインインしている場合、プライマリ アカウントの PRT が提供するデバイス認証は、2 つ目のアカウントにも自動的に適用されます。 その結果、2 番目のアカウントも、テナントのデバイスベースの条件付きアクセス ポリシーに適合します。

PSSO PRT は、 SSO 拡張機能 によってアプリと Web サイトに SSO を提供するために使用されます。 PRT は、トークン要求の SSO 拡張機能に依存するアプリケーションの更新トークンとアクセス トークンを要求するために使用されます。 また、ブラウザーの要求に PRT を挿入して、ブラウザー上で SSO を有効にします。

PRT は、ネイティブ アプリ用の "Microsoft Entra WAM プラグイン" の説明と同様の方法で使用されます。 ブラウザー SSO をサポートするブラウザーは、Safari、Firefox、Chrome、Microsoft Edge です。

現在統合されているネイティブ アプリは、Intune と Microsoft Edge Browser のみです。 ブラウザーのサポートでは、デバイス バインド トークンと条件付きアクセスの適用に対して Microsoft Edge Browser のみが保護されます。

Windows プラットフォーム

PRT は、次の 2 つの異なる方法で更新されます。

• Microsoft Entra CloudAP プラグインによる 4 時間ごとの更新 : CloudAP プラグインは、Windows サインイン中、4 時間ごとに PRT を更新します。 その時点でユーザーがインターネットに接続していない場合でも、デバイスがインターネットに接続されて新たに Windows にサインインすると、CloudAP プラグインが PRT を更新します。
• アプリのトークン要求時の Microsoft Entra WAM プラグインによる更新 WAM プラグインは、Windows 10 以降のデバイスでアプリケーションに対するサイレント トークン要求を可能にすることで、SSO を実現します。 WAM プラグインは、これらのトークン要求中に 2 つの異なる方法で PRT を更新できます。
  • アプリが WAM に対してサイレントにアクセス トークンを要求するが、そのアプリ用の更新トークンが存在しない場合。 この場合、WAM は PRT を使用してアプリのトークンを要求し、応答で新しい PRT を再取得します。
  • アプリが WAM にアクセス トークンを要求するが、PRT が無効であるか、Microsoft Entra ID が追加の認証 (たとえば、Microsoft Entra の多要素認証) を要求している場合。 このシナリオでは、WAM は対話型サインインを開始し、ユーザーが再認証または追加の検証を行う必要があり、認証が成功すると新しい PRT が発行されます。

ADFS 環境では、ドメイン コントローラーに直接アクセスして PRT を更新する必要はありません。 PRT の更新には、WS-Trust プロトコルを使用して、プロキシ上で /adfs/services/trust/2005/usernamemixed/adfs/services/trust/2005/usernamemixed および /adfs/services/trust/13/usernamemixed エンドポイントのみが有効になっていれば十分です。

Windows トランスポート エンドポイントは、パスワードが変更された場合にのみパスワード認証に必要であり、PRT の更新には必要ありません。

重要な考慮事項

• Microsoft Entra に参加済みおよび Microsoft Entra ハイブリッド参加済みのデバイスでは、CloudAP プラグインが PRT のプライマリ機関となります。 WAM ベースのトークン要求中に PRT が更新された場合、PRT は CloudAP プラグインに返送され、受け入れ前に Microsoft Entra ID での PRT の有効性が検証されます。

macOS では、PSSO プライマリ更新トークン (PRT) が 4 時間ごとに更新されます。SSO トークンが見つからないか、有効期限が切れている場合は、より早く更新されます。

iOS では、iOS オペレーティング システムによるリソースの割り当てに応じて、デバイスの充電中に 2 日に 1 回以上発生しない日和見的な更新もあります。 他のプラットフォームと同様に、PRT は使用されている場合は 90 日間有効です。

PRT は 90 日間有効であり、ユーザーがデバイスをアクティブに使用している場合は 4 時間ごとに更新されます。

• PRT は 90 日間有効であり、ユーザーがデバイスをアクティブに使用している限り、継続的に更新されます。
• PRT はネイティブ アプリの認証中にのみ発行および更新されます。 PRT はブラウザー セッション中は更新も発行もされません。
• デバイス登録 (Workplace Join) の必要なしに PRT を取得し、SSO を有効にすることもできます。
• デバイス登録なしで取得された PRT は、デバイスの状態やコンプライアンスに基づく条件付きアクセスの認証条件を満たすことができません。

Microsoft Entra ID と Windows 10 以降では、次の方法によって PRT 保護を有効にします。

• 初回サインイン中: 初回サインイン中、暗号化形式でデバイス登録中に生成されたデバイス キーを使用して要求に署名することによって PRT が発行されます。 TPM が有効に動作しているデバイスでは、デバイス キーは TPM によってセキュリティで保護され、悪意のあるアクセスを防ぎます。 対応するデバイス キーの署名を検証できない場合、PRT は発行されません。
• トークンの要求および更新中: PRT が発行されると、Microsoft Entra ID は暗号化されたセッション キーもデバイスに発行します。 それは生成されたパブリック トランスポート キー (tkpub) を使用して暗号化され、デバイス登録の一環として Microsoft Entra ID に送信されます。 このセッション キーは、TPM によってセキュリティで保護されたプライベート トランスポート キー (tkpriv) によってのみ復号化できます。 セッション キーは、Microsoft Entra ID に送信されるすべての要求に対しての所有証明 (POP) キーです。 セッション キーも TPM によって保護され、他の OS コンポーネントからアクセスできません。 トークン要求または PRT 更新要求は、TPM を使用してこのセッション キーによって安全に署名されるため、改ざんできません。 Microsoft Entra では、対応するセッション キーによって署名されていないデバイスからの要求が無効になります。

これらのキーを TPM で保護することで、キーの窃取や PRT のリプレイを試みる悪意のある攻撃者から PRT のセキュリティを強化できます。 そのため、TPM を使用することで、Microsoft Entra 参加済みデバイス、Microsoft Entra hybrid 参加済みデバイス、および Microsoft Entra 登録デバイスの認証情報窃取に対するセキュリティが大幅に向上します。 パフォーマンスと信頼性の観点から、Windows 10 以降のすべての Microsoft Entra デバイス登録シナリオでは、TPM 2.0 の使用が推奨されています。 Windows 10、1903 の更新後、Microsoft Entra ID では、信頼性の問題のため、上記のキーに TPM 1.2 は使用されません。

プライマリ更新トークン (PRT) は、ユーザーがサインインするデバイスに安全にバインドされます。 Microsoft Entra ID と macOS では、いくつかのメカニズムによってこの保護が適用されます。

PRT は、セキュリティで保護されたエンクレーブに基づくデバイス署名キーを使用して要求が署名された後にのみ発行されます。これは、デバイスの登録時に暗号化によって生成されます。 このキーの署名を検証できない場合、PRT は発行されません。

• アプリが WAM を介してトークンを要求すると、Microsoft Entra ID はアクセス トークンを発行し、一部の種類の要求では更新トークンを発行します。 ただし、WAM はアクセス トークンのみをアプリに返し、更新トークンをセキュリティで保護します。
  • SSO ユーザーの更新トークンである場合、この更新トークンは、セッション キー (PRT と同じ) またはデバイス キーを使用してデバイスにバインドされます。
  • SSO 以外のユーザーの更新トークンである場合、この更新トークンはデバイスにバインドされません。
• すべての更新トークンは DPAPI によって暗号化されます。

• iOS アンマネージド: MDM SSO 拡張機能プロファイルがないデバイスでは、ブローカーはアクセス トークンと更新トークンの両方を呼び出し元アプリに返します。 呼び出し元のアプリは、後続の更新に更新トークンを使用し、その更新トークンは保護されません。
• macOS/iOS マネージド: MDM SSO 拡張機能プロファイルを持つデバイスでは、ブローカーは呼び出し元アプリにアクセス トークンのみを返します。 ブローカーは後続のトークン更新に PRT を使用し、保護されていない更新トークンは使用しません。 この構成は、追加の保護が提供されるため、アンマネージド構成よりも使用することをお勧めします。

• ブローカーは、呼び出し元のアプリにのみアクセス トークンを返し、マネージド デバイスとアンマネージド デバイスの両方のアプリ更新トークンをローカルに格納します。

• Linux では、ブローカーは呼び出し元アプリにのみアクセス トークンを返し、マネージド デバイスとアンマネージド デバイスの両方の更新トークンをローカルに格納します。
• ローカルに格納された更新トークンは、UNIX ユーザーのサインイン キーリングに格納されている暗号化キーで暗号化されます。

• Windows 10 以降では、Microsoft Entra ID は、ネイティブサポートまたは 拡張機能 を介して Google Chrome で、ブラウザー設定を介して Mozilla Firefox v91+ で、Microsoft Edge でブラウザー SSO をネイティブにサポートしています。 Cookie だけでなく Cookie が送信されるエンドポイントも保護するようにセキュリティが構築されています。
• ユーザーがブラウザーの対話を開始すると、ブラウザー (または拡張機能) によって プラットフォーム API が呼び出されます。 拡張機能は、ネイティブ メッセージング ホストを介してこの API を呼び出します。 API は、ページが許可されているドメインの 1 つからのものであることを確認します。 ブラウザーは、nonce を含む完全なクエリ文字列を送信します。 プラットフォーム API は、TPM で保護されたキーで署名された PRT およびデバイス ヘッダーを作成します。 PRT ヘッダーはセッション キーによって署名され、デバイス ヘッダーはデバイス キーによって署名されるため、改ざんが困難です。 これらのヘッダーは、送信元のデバイスとユーザーを検証するための Microsoft Entra ID のすべての要求に含まれます。 Microsoft Entra ID は、これらのヘッダーを検証すると、ブラウザーにセッション Cookie を発行します。 このセッション Cookie には、要求の署名に使用したのと同じセッションまたはデバイス キーも含まれています。 後続の要求の間、セッション キーが検証されます。このとき、Cookie は事実上デバイスにバインドされ、他の場所からの再生を防ぎます。

SSO 拡張機能プロファイルを使用する Safari と Microsoft Edge には、PRT セッション キーによって保護された Cookie が含まれます。 Microsoft Edge では、ユーザーが Microsoft Edge プロファイルにログインしている必要があります。 COOKIE は、SSO 拡張機能プロファイルなしでは保護されません。

対話型サインイン中に、ブラウザーの SSO Cookie が生成されます (Android アカウントのマネージド ストレージにある PRT とセッション キーを使用)。 Microsoft Edge ブラウザーにのみ適用され、ユーザーはサインインする必要があります。

Microsoft Edge on Linux では、ブラウザーの SSO Cookie をブローカーに要求して、Microsoft Edge で SSO を有効にすることができます。 ブローカーは、生成された Cookie を Microsoft Edge に返すために、それぞれユーザーとデバイス ブローカーのコンテキストに格納されている PRT とセッション キーを使用して SSO Cookie を生成します。 Microsoft Edge では、ユーザーがプロファイルにログインしている必要があります。 理論的には、Linux プラットフォームにはアプリ ID がないため、Microsoft Edge 以外のアプリでもこの Cookie をブローカーに要求できます。 OS のセキュリティ境界は UNIX ユーザーの周囲にあり、同じユーザー コンテキスト内のアプリのみが、そのコンテキストでユーザーの SSO Cookie を取得できます。

• Windows Hello for Business を使用してサインイン: Windows Hello for Business は、パスワードを置き換え、暗号化キーを使用して強力な 2 要素認証を提供します。 Windows Hello for Business はデバイス上のユーザーに固有であり、それ自体がプロビジョニングのために MFA を必要とします。 ユーザーが Windows Hello for Business を使用してログインすると、ユーザーの PRT が MFA 要求を取得します。 このシナリオは、スマート カード認証が ADFS から MFA 要求を生成する場合に、スマート カードを使用してログインするユーザーにも適用されます。
  • Windows Hello for Business は多要素認証と見なされ、PRT 自体が更新されると MFA 要求が更新されるため、ユーザーが Windows Hello for Business を使用してサインインすると MFA の期間は継続的に延長されます。
• WAM 対話型サインイン中の MFA: WAM を通じたトークン要求中に、ユーザーがアプリにアクセスするために MFA を実行する必要がある場合、この対話中に更新される PRT には MFA 要求が刻印されます。
  • この場合、MFA 要求は継続的に更新されないため、MFA 期間はディレクトリで設定された有効期間に基づきます。
  • 以前の既存の PRT と RT がアプリへのアクセスに使用されている場合、PRT と RT は最初の認証の証明と見なされます。 2 番目の証明と刻印された MFA 要求で、新しい RT が必要になります。 このプロセスにより、新しい PRT と RT も発行されます。
• Windows 10 以降では、PRT のパーティション分割されたリストを資格情報ごとに保持します。 したがって、Windows Hello for Business、パスワード、またはスマート カードのそれぞれに PRT があります。 このパーティション分割により、使用する資格情報に基づいて MFA 要求が分離され、トークン要求中に混同されないことが保証されます。

CA ポリシーが管理者によって設定されている場合、ユーザーは MFA を実行する必要があります。 このような場合、PRT はアップグレードされ、MFA 要求が取得されます。 要求の期間は、ディレクトリに設定された有効期間に基づいています。