はじめに

最近公開された下記 MS 公開情報にも記載があるとおり、Azure AD Registered でも PRT (Primary Refresh Token) は取得できます。
PRT というのは Microsoft のオリジナルのトークンなのですが、よくイメージするのは Hybrid Azure AD Join (Azure AD Join) での dsregcmd /status コマンドレットで確認できるあの PRT ですよね。

では Azure AD Registered ではどうやって PRT を取得するのでしょうか。
公開情報には下記のとおり記載があります。

-参考情報
What is a Primary Refresh Token?
URL:https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token

Azure AD registered device: A PRT is issued when a user adds a secondary work account to their Windows 10 device. Users can add an account to Windows 10 in two different ways -
Adding an account via the Use this account everywhere on this device prompt after signing in to an app (for example, Outlook)
Adding an account from Settings > Accounts > Access Work or School > Connect

つまり、「WAM 経由」で Azure AD Registered するか、「職場または学校にアクセスする」から Azure AD Registered することで取得できると記載があります。
取得のタイミングとしては、 Azure AD Join と同じで Windows 10 コンピューターにログオンしたタイミングと思われます。
Azure AD Registered の場合は、「dsregcmd /status」コマンドレットでは PRT 取得有無を確認できません。
Windows 10 コンピューターのイベントビュアーのデバッグログ (Analytic) を出力させ動作を確認してみましょう。

やってみる

まず、Windows 10 コンピューターのコマンドプロンプトにて AAD デバッグログを有効化します。
(既定では無効になっています)

AAD デバッグログの有効化

管理者権限を持つアカウントでコマンドプロンプトを開きます
次のコマンドを実行し、ログを有効にします。

wevtutil sl "Microsoft-Windows-AAD/Analytic" /e:true

以下コマンドを実行し、enabled: true となっていることを確認します。

wevtutil gl "Microsoft-Windows-AAD/Analytic" | findstr enabled

次にイベントビューアーの「表示」→「Show Analytic and Debug Logs」の順にクリックします。

Analytic ログが表示されることを確認します。

ログを出力するときは、下記のとおりデバッグログを無効化してから、任意のフォルダに出力します。

無効化コマンド
wevtutil sl "Microsoft-Windows-AAD/Analytic" /e:false

Cドライブ直下に Analyticログを出力
wevtutil epl "Microsoft-Windows-AAD/Analytic" C:%computername%-Microsoft-Windows-AAD-Analytic.evtx

Azure AD Registered する

「設定」→「アカウント」→「職場または学校にアクセスする」の順に選択し、「＋接続」をクリックします。

Azure AD ユーザーの UPN を入力し、「次へ」をクリックします。

パスワードを入力し、「サインイン」をクリックします。

準備が完了しました！と表示されれば登録完了です。「完了」ボタンをクリックします。

下記のとおり、職場または学校アカウントで Azure AD Registered できたことが確認できます。

Analytic ログを順番に見ていく

OAuth 2.0 の話がでてきます。
正直私も完全に理解しきれているわけではないので、説明が拙くて恐縮ですが、ご容赦ください。
OAuth 2.0 の基本的な動作は下記 Qiita 投稿が非常に参考になりますので是非一読ください。

一番分かりやすい OAuth の説明
URL:https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be

Device 登録開始。

デバイス登録完了。

アクセストークンエンドポイントにアクセストークンのリクエストをしている。

リクエストの完了。

リクエストが成功している。

アクセストークンがリフレッシュトークンにより更新されている。
※この時点では PRT (Primary Refresh Token) は取得できていない。

この次のステップで、 RequestPRT と記載されているとおり、 PRT を取得しに行くフローが開始されていることが分かる。
※もしかしたらこの時点ですでに PRT が取れているのかもしれない。

Code: 0x4AA5002C Initialization data downloaded.
Logged at addaccountprovisiondevicetask.cpp, line: 243, method: AddAccountProvisionDeviceTask::RequestPRT.

Request: authority: https://login.microsoftonline.com/common, client: 29d9ed98-a469-4536-ade2-f981bc1d605e, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin, resource: 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9, correlation ID (request): d1697606-4e6c-465e-97d9-fae4cc313fec

この1秒後の Analytic のログ UI Flow Started と記載があり、 URL のリンクが記載されているのでクリックしてみます。
https://login.microsoftonline.com/common/sso/final?redirect_uri=ms-appx-web://Microsoft.AAD.BrokerPlugin/FinalPage&error=0

すると、Azure AD Registered が完了した画面が表示されました。

OAuth のトークンブローカーが有効化されています。

トークンブローカーが Azure AD に対してトークンの取得のオペレーションを開始します。

再度、アクセストークンエンドポイントにアクセストークンのリクエストをしている。

リクエスト処理が正常に完了しています。

次の下記段階でトークンが PRT (Primary refresh Token) 更新されていることが分かります。

Code: 0x4AA90055 Renew token by the primary refresh token success.
Logged at refreshtokenrequest.cpp, line: 96, method: RefreshTokenRequest::AcquireToken.

Request: authority: https://login.microsoftonline.com/common, client: {6F7E0F60-9401-4F5b-98E2-CF15BD5Fd5E3}, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/{6F7E0F60-9401-4F5b-98E2-CF15BD5Fd5E3}, resource: https://cs.dds.microsoft.com, correlation ID (request): f2118e9b-6f30-4f2e-9798-9ab6abd04380

ここからは企業秘密なのですが弊社のとあるツールで、「correlation ID (request): f2118e9b-6f30-4f2e-9798-9ab6abd04380」の中身を解析したところ、やはり間違いなく PRT は取得できていました。また、発行された時間は、2019/06/08 22時58分17秒でした。(有効期限は既定の14日間)

つまり、「もしかしたらこの時点 PRT を取得できているかもしれない」、と記載した下記フローの時点で PRT が取得できていました。

Code: 0x4AA5002C Initialization data downloaded.
Logged at addaccountprovisiondevicetask.cpp, line: 243, method: AddAccountProvisionDeviceTask::RequestPRT.

Request: authority: https://login.microsoftonline.com/common, client: 29d9ed98-a469-4536-ade2-f981bc1d605e, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin, resource: 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9, correlation ID (request): d1697606-4e6c-465e-97d9-fae4cc313fe

おまけ

ちなみブラウザアクセスしてみたら、下記のとおり Office 365 にシングルサインオンできました。(資格情報入力する必要なし)
また、その際の Fiddler を取ってみましたが、下記のとおり Bearer Token が Azure AD に提示されていました。
ベアラートークンをデコードした中身です。

{
  "typ": "JWT",
  "nonce": "AQABAAAAAADCoMpjJXrxTq9VG9te-7FXaVG83oYkMmzaZjvzOvcP5NFecaTglx12rreooPZtOPMYJH5JlvEucvActlbvUHR53k8tkar1JecsZzNHysoWHCAA",
  "alg": "RS256",
  "x5t": "CtfQC8Le-8NsC7oC2zQkZpcrfOc",
  "kid": "CtfQC8Le-8NsC7oC2zQkZpcrfOc"
}

{
  "aud": "https://substrate.office.com",
  "iss": "https://sts.windows.net/ca90ee67-329e-4615-b7a1-b2e158252733/",
  "iat": 1560008182,
  "nbf": 1560008182,
  "exp": 1560012381,
  "acr": "1",
  "aio": "42ZgYMjUO6xT0iK1bT+jdApPt/6i43ISK9i6Cy/lrOhXcv/1bgUA",
  "amr": [
    "pwd",
    "rsa"
  ],
  "appid": "4345a7b9-9a63-4910-a426-35363201d503",
  "appidacr": "2",
  "deviceid": "cd7599a8-ef42-45e9-8ed8-15c962578242",
  "ipaddr": "13.78.30.222",
  "name": "test001@shyamag015.onmicrosoft.com",
  "oid": "a85ac278-86e3-41b2-8a6e-30c1c5aa0a5d",
  "puid": "100320004BD93391",
  "scp": "Files.Read OfficeFeed-Internal.ReadWrite PeoplePredictions-Internal.Read SubstrateSearch-Internal.ReadWrite",
  "sub": "62p0hO3lZLX-PUBl35wQU2vLofLRrhEZV-lFT7EfcYs",
  "tid": "ca90ee67-329e-4615-b7a1-b2e158252733",
  "unique_name": "test001@shyamag015.onmicrosoft.com",
  "upn": "test001@shyamag015.onmicrosoft.com",
  "uti": "5rhR4kSDVkCVF86YfOiZAA",
  "ver": "1.0"
}

きちんと Azure AD Registered した時の UPN (test001@shyamag015.onmicrosoft.com) の情報が渡されていますね！

https://jwt.io/ はベアラートークンを貼り付けるだけで一発デコードしてくれる便利なサイトなので活用しましょう。

おわりに

今回の収穫は、 Azure AD Registered した時点ですでに PRT が取得できている、ということ。
また、流れとしては、OAuth 2.0 のトークンエンドポイントにアクセストークンを取得して、そのあとに、 PRT の取得依頼のフローに入っているという事が分かりました。

dsregcmd /status コマンドレットでは PRT の取得の確認はできませんが、内部的にきちんと PRT は取得できていますので安心してご利用ください。