こんにちは、富士榮です。
これまでもWindows Server 2016にインストールして使ってしまっていたAzure AD Connectですが、11月版の更新（ビルド1.1.343.0）でやっと正式にWindows Server 2016への対応をしました。
Azure AD Connect version history
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-aadconnect-version-history
細かいバグフィックスと同時に、SQL Server 2016への対応、およびAD FS 2016の管理についてもサポートする様になったので、新しい環境に導入する場合はこのバージョンを使っていきましょう。
2016年11月25日金曜日
2016年9月28日水曜日
Windows Server 2016のリリースとハイブリッドID基盤
こんにちは、富士榮です。
アトランタで開催中のIgniteのタイミングに合わせてWindows Server 2016が正式にリリースされました。
公式ブログでのアナウンス
https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-windows-server-2016/
9月28日現在、評価版のダウンロードが先行して可能になっていますが、正式版の提供は10月に入ってからの様ですね。
と、いうことでとりあえず評価版をダウンロードしてセットアップし、ハイブリッドID基盤の構成を確認してみました。
以前Windows Server 2012R2のドメインコントローラとAzure AD、Windows 10を使って構成した構成ですね。
[Windows 10/Azure AD]ハイブリッド環境におけるドメイン参加とシングルサインオン①
http://idmlab.eidentity.jp/2016/01/windows-10azure-ad.html
結論から言うと特に変化点はありません。
以下のシナリオでいわゆるDesktop SSO（PCへのサインイン～ブラウザアプリケーションへのサインインがシームレスに行える）が実現できます。
- Windows 10へのサインインはPINで行われる
- ファイル共有へは従来通りKerberosで認証が行われる
- AD FSに関連づけられたアプリケーションへもKerberosで認証が行われる
- Azure ADに関連づけられたアプリケーションへはMicrosoft Passportで認証が行われる
軽く動画を撮ってみました。
ちなみに、このシナリオの中で1点Technical Preview 5のころのAD FSと異なるところは、ブラウザにEdgeを使ってもAD FSへのWindows統合認証ができるようになっているところです。
単純にWIASupportedUserAgentsにEdgeなどがデフォルトで追加されているだけですけどね。
そして、Technical Previewから変わらずに残念だったのが、AD FSの認証方式にMicrosoft Passportが選択できるにも関わらず、ブラウザアプリケーションでのSSOシナリオでは相変わらず使えないところです。
ここは別途、もう少し詳しく状況を解説したいと思いますので、とりあえずPINでログインしてもAD FSに関連づけられたアプリケーションへはMicrosoft Passport認証ではなく、Windows統合認証でSSOするしか現状は無い、ということだけ覚えておいてください。
設定関係も簡単に動画に撮っています。
そのうちもう少し細かく解説を加えて、Channel 9の別館の方にもアップしたいと思います。
アトランタで開催中のIgniteのタイミングに合わせてWindows Server 2016が正式にリリースされました。
公式ブログでのアナウンス
https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-windows-server-2016/
9月28日現在、評価版のダウンロードが先行して可能になっていますが、正式版の提供は10月に入ってからの様ですね。
と、いうことでとりあえず評価版をダウンロードしてセットアップし、ハイブリッドID基盤の構成を確認してみました。
以前Windows Server 2012R2のドメインコントローラとAzure AD、Windows 10を使って構成した構成ですね。
[Windows 10/Azure AD]ハイブリッド環境におけるドメイン参加とシングルサインオン①
http://idmlab.eidentity.jp/2016/01/windows-10azure-ad.html
結論から言うと特に変化点はありません。
以下のシナリオでいわゆるDesktop SSO（PCへのサインイン～ブラウザアプリケーションへのサインインがシームレスに行える）が実現できます。
- Windows 10へのサインインはPINで行われる
- ファイル共有へは従来通りKerberosで認証が行われる
- AD FSに関連づけられたアプリケーションへもKerberosで認証が行われる
- Azure ADに関連づけられたアプリケーションへはMicrosoft Passportで認証が行われる
軽く動画を撮ってみました。
ちなみに、このシナリオの中で1点Technical Preview 5のころのAD FSと異なるところは、ブラウザにEdgeを使ってもAD FSへのWindows統合認証ができるようになっているところです。
単純にWIASupportedUserAgentsにEdgeなどがデフォルトで追加されているだけですけどね。
PS C:\Users\Administrator> $a = (Get-AdfsProperties).WIASupportedUserAgents
PS C:\Users\Administrator> $a
MSAuthHost/1.0/In-Domain
MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Trident/7.0
MSIPC
Windows Rights Management Client
MS_WorkFoldersClient
=~Windows\s*NT.*Edge
そして、Technical Previewから変わらずに残念だったのが、AD FSの認証方式にMicrosoft Passportが選択できるにも関わらず、ブラウザアプリケーションでのSSOシナリオでは相変わらず使えないところです。
ここは別途、もう少し詳しく状況を解説したいと思いますので、とりあえずPINでログインしてもAD FSに関連づけられたアプリケーションへはMicrosoft Passport認証ではなく、Windows統合認証でSSOするしか現状は無い、ということだけ覚えておいてください。
設定関係も簡単に動画に撮っています。
そのうちもう少し細かく解説を加えて、Channel 9の別館の方にもアップしたいと思います。
2016年5月8日日曜日
[Azure AD]トラブルシューティングに見るAzure AD参加の裏側
こんにちは、富士榮です。
ゴールデンウィークも終わりですね。
と、いうことで今回は今年の私のゴールデンウィークの7割を奪ったAzure Active Directory（Azure AD）へのデバイス登録時のトラブルと、トラブルシューティングの中で見えてきたAzure AD DRS（Device Registration Service）の裏側の仕組みの話です。
こんなエラーが出ます。
どうやらみなさん困っていたようで、各所に情報が出始めていました。
(未解決) PIN setup on Azure AD joined machine fails.が、現在も発生
Error 0x801c03ed during PIN create/change
エラーコードだけを見ているとデバイス参加時に多要素認証が必要な設定になっているにも関わらず、多要素認証を実施しなかった等が原因で対策としては一旦Azure ADから切り離して再参加する、と書いてあるのですが、多要素認証を要求する設定をしていないにもかかわらずこのエラーがでたり、多要素認証を実施してもエラーがでたり、そもそも再参加しても状況が改善しない、という状態でした。
エラー時のリファレンス
Microsoft Passport errors during PIN creation
１．イベントログを確認する
ユーザがデバイスを登録する際、クライアント側のイベントログに様々な情報が記録されます。関連するのは、主にUser Device Registrationで、必要に応じてAADについても見ることになります。（両方とも、アプリケーションとサービスログ->Microsoft->Windowsの配下にあります）
エラーが発生しているときは、User Device RegistrationのAdminログにID:301のエラーが発生していました。
NGC KeyをAzure DRSへ登録する際にInsufficient privilegesが出ていますので、先の多要素認証が正常に実行されていない時と同じエラーだと判断されたようです。
この前後のログを見ると、Azure DRSへNGCを登録する際の動きを推測することが出来ます。
流れは、
１．Azure DRSのエンドポイントを検出する
２．対象ユーザが関連付けされているデバイスをAzure ADディレクトリから探し出す
３．クライアントで生成した鍵ペアより公開鍵を登録する
となっています。
（細かくは省きますが、OOBEでのセットアップ時（WinPE）かどうか判別したり、レジストリからNGC関連の情報を読み取ろうとしたり、と前処理では他にも色々とやっています）
順番に見ていきます。
１のAzure DRSのエンドポイントの検出です。ここは障害が発生している間もうまく動いていました。検出は以下の2つのXMLドキュメントを使ってクライアント・コンフィグレーションをAzureから取得するところからスタートします。
https://clientconfig.microsoftonline-p.net/FPURL.xml
https://clientconfig.microsoftonline-p.net/fplist.xml
ここで主にやっているのは、通常のテナント（MicrosoftOnline.com）なのか、中国用テナント（partnet.microsoftonline.com）なのかの判別をして、必要なIdPのURLを取得するところです。
この後、ユーザのドメイン名からDRSや関連するエンドポイントを検出し、その結果がイベントログに記録されます。
DRSのエンドポイントと、Azure AD上でのリソースURI、OAuth関連のエンドポイントが検出されています。
２のAzure ADに登録されたデバイスとの関連付けについてはイベントログには現れませんが、前段でAzure ADへの参加をした時にAzure AD上に登録されたデバイスからのNGC登録要求でないとAzure DRSは受付けません。デバイスの登録状態はAzure ADのPowerShellコマンドレッド（新しい奴）もしくはGraph APIで状態の確認ができます。
Get-MsolDevice -Allで一覧を取得した結果はこんな感じです。このDeviceTrustTypeに「Azure AD Joined」とあるのがAzure AD参加したデバイスです。※ちなみにオンプレADに参加したデバイスをAzure ADへ同期すると「Domain Joined」となります。また、Intuneで管理されている状態だとDeviceTrustLevelがCompliantに、単純にデバイスが登録されただけの状態だとAuthenticatedになります。
最後にクライアント側で生成した鍵をAzure ADへ登録するところで先ほどは「Insufficient privilege」と言われてエラーになっていましたが、正常に登録できると「Microsoft Passport key was successfully registered」というメッセージが出ます。
なお、今回トラブルシューティングをする上では、さらに細かい情報を取得する必要があったため、User Device Registrationのデバッグログを有効にしました。
有効にするには、イベントログのデバッグおよびトレースを有効化した上で、User Device RegistrationのDebugログを有効にします。
デバッグログを有効化することで膨大なログ（PIN登録部分だけで1000件近く）が出ますが、より細かい状態を把握できます。
今回のケースだとID：502で以下の3つのエラーが記録されていました。
・XMLのパースエラー（エンドポイントのディスカバリ時のエラー）
・NGCコンテナの作成エラー
・NGC登録時にサーバーエラー（400）
後半2つは最初のエラーに起因するものだと思われるので、一番の原因はディスカバリだった、ということですね。ちなみに事象が解消した現在でもfplist.xmlにDRS要素はないので、fplist.xmlのパース処理自体に問題があった、ということだと思います。
イベントログはこんな感じです。
２．Azure ADへのクライアント登録の状態からWindows 10とAzure ADの関連を知る
これは今回のトラブル解消には全く関係ありませんでしたが、イベントログを見て行く過程でAADのイベントログにこんな情報が出ていました。（User Device Registrationではなく、AAD側のログ）
この辺りを見ると、Azure ADの共通テナント（https://login.microsoftonline.com/common）上にAAD.BrokerPlugin用のクライアントがマルチテナント構成で登録されていることがわかります。
※この画面では、クライアントID「dd762716-544d-4aeb-a526-687b73838a22」が見えますが、他にも「a40d7d7d-59aa-447e-a655-679a4107e548」などが登録されています。
仕組みとしては、Windows 10のネイティブアプリケーションであるMicrosoft.AAD.BrokerPluginがAzure ADの情報にアクセスするために、共通のクライアントがAzure AD上に登録されており、そのクライアントを使ってAzure ADとやり取りをしているようです。Edgeを使ったデバイス->ブラウザのシングルサインオンにおけるPRT（Primary Refresh Token）からアクセストークンの取得でも活用されているので、知っておいて損はありません。
実際の動きはFiddlerでも見ることが出来ますが、無理やりブラウザを使ってリクエストを投げてみるとクライアントがどのような名前で登録されているか、くらいはわかります。
例えば、DRSへのアクセストークンを取得したい場合は、
https://login.microsoftonline.com/common/oauth2/authorize?
response_type=code%20token&
client_id=dd762716-544d-4aeb-a526-687b73838a22&
redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2Fdd762716-544d-4aeb-a526-687b73838a22&
resource=urn:ms-drs:enterpriseregistration.windows.net
を投げるとクライアントのDisplayNameは空白で、多要素認証を要求していることがわかります。
（実際は多要素認証に回答してもそのまま固まりますが）
同様にアカウント設定画面での操作は、
https://login.microsoftonline.com/common/oauth2/authorize?
response_type=code%20token&
client_id=a40d7d7d-59aa-447e-a655-679a4107e548&
redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2Fa40d7d7d-59aa-447e-a655-679a4107e548&
resource=https%3A%2F%2F<ドメイン名>
を投げるとクライアントが「Accounts Control UI」という名前で登録されていることがわかります。
（こちらはBad Requestになります）
このあたりはトラブルシューティングにはあんまり役に立ちませんが、内部の動きを知っておくのは良いことだと思います。
３．PIN生成時の通信をFilddlerでキャプチャする
この辺りも基本的なところなので、押さえておきたいところです。
Jairoのblog（翻訳版はこちら）を見ると、PIN登録時に「https://account.live.com/aadngc」へアクセスする、とありますが実際の動きはどうなっているのかを確認してみましょう。
Fiddlerのセットアップや基本的な操作方法については割愛しますが、ポイントは以下の2点です。
・ブラウザ以外のセッションもキャプチャする
・HTTPSの復号を有効にする
特にポイントになるのは、Windowsアプリケーションからの通信をキャプチャするという部分で、具体的にはFiddlerの左上のWinConfigをクリックして必要なアプリケーションを選択して保存を行います。
画面の中にアカウントや職場または学校アカウントなどが関連するのでチェックが入っているか確認しておきましょう。
この状態でPINのセットアップを行うと、以下のようなキャプチャが取得できます。
＜リクエスト＞
GET https://account.live.com/aadngc?uiflavor=win10&mkt=ja-JP&hasngc=0&platform=Windows10&scid=4&ctc=0&uiflavor=Win10 HTTP/1.1
Accept: text/html, application/xhtml+xml, image/jxr, */*
Accept-Language: ja
cxh-osVersionInfo: {"platformId":0,"majorVersion":10,"minorVersion":0,"buildNumber":14332}
hostApp: CloudExperienceHost
client-request-id: 872a9ff6-a81d-0000-0cad-2d871da8d101
cxh-protocol: ms-cxh
cxh-cxid: NGC
cxh-preferredLanguage: ja
cxh-correlationId: 872a9ff6-a81d-0000-0cad-2d871da8d101
cxh-source: ms-cxh://NTHAADNGCONLY/
cxh-osPlatform: CloudExperienceHost.Platform.DESKTOP
cxh-platform: CloudExperienceHost.Platform.DESKTOP
cxh-isRTL: false
cxh-colors: themeAccent=#0078d7;themeAccentLight1=#429ce3;themeAccentLight2=#76b9ed;themeAccentLight3=#a6d8ff;themeAccentDark1=#005a9e;themeAccentDark2=#004275;themeAccentDark3=#002642;themeTextApplication=#000000;themeTextSystem=#ffffff;
cxh-host: NTHAADNGCONLY
cxh-hostAppVersion: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; MSAppHost/3.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82 Safari/537.36 Edge/14.14332
Accept-Encoding: gzip, deflate
Host: account.live.com
Connection: Keep-Alive
Cookie: mkt=ja-JP; DID=5737
こうやって見ると、CXH（Cloud eXperience Host）が内部的には健在なことがわかりますね。レスポンスはHTMLが返ってきているので、CXH内での画面表示はHTMLであることがわかります。
その後、https://auth.gfx.msへのアクセスが続いた後、最終的にhttps://account.live.com/API/ReportClientEventへ以下のJSONがPOSTされます。
{
"pageApiId":"Account_AAD_NGC_Provisioning",
"clientDetails":[],
"userAction":"",
"source":"PageView",
"clientTelemetryData":{
"category":"PageLoad",
"pageName":"Account_AAD_NGC_Provisioning",
"eventInfo":{
"timestamp":1462676178361,
"perceivedPlt":2641,
"networkLatency":1874,
"networkType":null,
"precaching":null,
"bundleVersion":null,
"appVersion":null,
"deviceYear":null,
"isMaster":null,
"bundleHits":null,
"bundleMisses":null
}
},
"uiflvr":13,
"uaid":"872a9ff6a81d00000cad2d871da8d101",
"scid":100185,
"hpgid":"Account_AAD_NGC_Provisioning"
}
そして、最後に
https://enterpriseregistration.windows.net/EnrollmentServer/key/?api-version=1.0
に対して公開鍵をPOSTします。
{
"kngc":"UlNBMQAI...snip...tFNEC+U/BbJ+WU0pKD1tAOINB2w==",
"ak":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
}
こんな感じです。
尚、同様にFiddlerを使ってAzure ADへ参加する際の通信の流れやMicrosoft Passportの流れもキャプチャすることが出来ます。
例えば、Azure ADへ参加する時は、
このあたりの細かい話は別途まとめてお話ししたいですね。
４．NGC（Next Generation Credential）のプロビジョニング状態を確認する
デバイスがAzure ADやオンプレミスのADへ参加しているかどうか、MDMでの管理状態はどうなっているのか、およびNGCがプロビジョニングされているかどうかを簡単にチェックするにはdsregcmd.exeを使います。
使い方としては、dsregcmd /statusとたたくだけです。
出力結果は2つのパートに分かれており、デバイスの状態およびユーザの状態を示します。（Windows 10 1511.10586.xxxの場合。14332だともっと項目が増えています）
特徴的なのは、Workplace Joinはあくまでユーザ単位なので、User State側に分類されているところでしょうか。
例えば、オンプレミスADへドメイン参加した状態でデバイス情報をAzure ADへ同期するとAzureAdJoinedおよびDomainJoinedの両方がYesになります。
参考）Build 14332系でのdsregcmd /statusの結果
Device StateにEnterpriseJoinedという謎の項目が増えていたり、DRS関係の情報が出てきます。
User Stateこちらはあんまり変わりません。
５．TPMをクリアする
これは、TPMが搭載されているマシンを使っている場合に限りますが、キーペアがTPM上に保存される以上、Azure AD DRS上に登録された公開鍵とTPMコンテナ内の秘密鍵の紐づけがおかしくなってしまったらTPMをクリアするのも一つの手になるかも知れません。（根拠はありません。そういう事態に陥ったことはないので）
とりあえず手順だけを書いておくと、ファイル名を指定して実行（Windowsキー＋R）で「tpm.msc」を実行してTPMのクリアを選択して実行するだけです。
再起動が要求されます。
ここで再起動すると起動画面でTPMのクリアが行われます。（手順はデバイスによって異なります）
ちなみにAcerのPCではボリュームUPボタンを押すとクリアされました。
注）ここでTPMをクリアすると当然のことながらマイクロソフトアカウントやローカルアカウントでのログイン時のPINがすべて使えなくなります。パスワードがわからないとPCへログインすらできなくなりますので、慎重に実施する必要があります。同じく、EFSやBitLockerなどに関しても要注意です。
まぁ、色々と書きましたが、トラブルシュートの基本は状態の把握だと思うので、イベントログや通信のキャプチャなどは覚えておいて損はないですね。
おまけ）
ちなみにPIN設定をキャンセルしようとすると以下の画面が出て、頑張って設定させようとしてきます。一旦キャプチャしたいのでスキップしたかったんですけどね。。こういう場合はあえてエラー状態を作っておくと先に進めます。（メッセージの焦った感じがウケます）
ゴールデンウィークも終わりですね。
と、いうことで今回は今年の私のゴールデンウィークの7割を奪ったAzure Active Directory（Azure AD）へのデバイス登録時のトラブルと、トラブルシューティングの中で見えてきたAzure AD DRS（Device Registration Service）の裏側の仕組みの話です。
◆何が起きていたのか？
4月の終わりから5月の頭にかけてAzure AD DRSの一部機能で障害が発生しており、
Windows 10デバイスをAzure ADへ参加させた後のサインイン時のPIN作成でエラー 0x801c03ed が出る
という状況になっていました。
どうやらみなさん困っていたようで、各所に情報が出始めていました。
(未解決) PIN setup on Azure AD joined machine fails.が、現在も発生
Error 0x801c03ed during PIN create/change
エラーコードだけを見ているとデバイス参加時に多要素認証が必要な設定になっているにも関わらず、多要素認証を実施しなかった等が原因で対策としては一旦Azure ADから切り離して再参加する、と書いてあるのですが、多要素認証を要求する設定をしていないにもかかわらずこのエラーがでたり、多要素認証を実施してもエラーがでたり、そもそも再参加しても状況が改善しない、という状態でした。
エラー時のリファレンス
Microsoft Passport errors during PIN creation
◆トラブルシューティングとして何をする／したのか
先に書いたように今回はトラブルシューティングをしても一向に解決しなかったので、中の人に泣きついた結果障害が発覚して収束したんですが、トラブルシューティングの過程を残しておくことも今後の役に立つと思ったので少し残しておきます。１．イベントログを確認する
ユーザがデバイスを登録する際、クライアント側のイベントログに様々な情報が記録されます。関連するのは、主にUser Device Registrationで、必要に応じてAADについても見ることになります。（両方とも、アプリケーションとサービスログ->Microsoft->Windowsの配下にあります）
エラーが発生しているときは、User Device RegistrationのAdminログにID:301のエラーが発生していました。
NGC KeyをAzure DRSへ登録する際にInsufficient privilegesが出ていますので、先の多要素認証が正常に実行されていない時と同じエラーだと判断されたようです。
この前後のログを見ると、Azure DRSへNGCを登録する際の動きを推測することが出来ます。
流れは、
１．Azure DRSのエンドポイントを検出する
２．対象ユーザが関連付けされているデバイスをAzure ADディレクトリから探し出す
３．クライアントで生成した鍵ペアより公開鍵を登録する
となっています。
（細かくは省きますが、OOBEでのセットアップ時（WinPE）かどうか判別したり、レジストリからNGC関連の情報を読み取ろうとしたり、と前処理では他にも色々とやっています）
順番に見ていきます。
１のAzure DRSのエンドポイントの検出です。ここは障害が発生している間もうまく動いていました。検出は以下の2つのXMLドキュメントを使ってクライアント・コンフィグレーションをAzureから取得するところからスタートします。
https://clientconfig.microsoftonline-p.net/FPURL.xml
https://clientconfig.microsoftonline-p.net/fplist.xml
ここで主にやっているのは、通常のテナント（MicrosoftOnline.com）なのか、中国用テナント（partnet.microsoftonline.com）なのかの判別をして、必要なIdPのURLを取得するところです。
この後、ユーザのドメイン名からDRSや関連するエンドポイントを検出し、その結果がイベントログに記録されます。
DRSのエンドポイントと、Azure AD上でのリソースURI、OAuth関連のエンドポイントが検出されています。
２のAzure ADに登録されたデバイスとの関連付けについてはイベントログには現れませんが、前段でAzure ADへの参加をした時にAzure AD上に登録されたデバイスからのNGC登録要求でないとAzure DRSは受付けません。デバイスの登録状態はAzure ADのPowerShellコマンドレッド（新しい奴）もしくはGraph APIで状態の確認ができます。
Get-MsolDevice -Allで一覧を取得した結果はこんな感じです。このDeviceTrustTypeに「Azure AD Joined」とあるのがAzure AD参加したデバイスです。※ちなみにオンプレADに参加したデバイスをAzure ADへ同期すると「Domain Joined」となります。また、Intuneで管理されている状態だとDeviceTrustLevelがCompliantに、単純にデバイスが登録されただけの状態だとAuthenticatedになります。
最後にクライアント側で生成した鍵をAzure ADへ登録するところで先ほどは「Insufficient privilege」と言われてエラーになっていましたが、正常に登録できると「Microsoft Passport key was successfully registered」というメッセージが出ます。
なお、今回トラブルシューティングをする上では、さらに細かい情報を取得する必要があったため、User Device Registrationのデバッグログを有効にしました。
有効にするには、イベントログのデバッグおよびトレースを有効化した上で、User Device RegistrationのDebugログを有効にします。
デバッグログを有効化することで膨大なログ（PIN登録部分だけで1000件近く）が出ますが、より細かい状態を把握できます。
今回のケースだとID：502で以下の3つのエラーが記録されていました。
・XMLのパースエラー（エンドポイントのディスカバリ時のエラー）
・NGCコンテナの作成エラー
・NGC登録時にサーバーエラー（400）
後半2つは最初のエラーに起因するものだと思われるので、一番の原因はディスカバリだった、ということですね。ちなみに事象が解消した現在でもfplist.xmlにDRS要素はないので、fplist.xmlのパース処理自体に問題があった、ということだと思います。
イベントログはこんな感じです。
２．Azure ADへのクライアント登録の状態からWindows 10とAzure ADの関連を知る
これは今回のトラブル解消には全く関係ありませんでしたが、イベントログを見て行く過程でAADのイベントログにこんな情報が出ていました。（User Device Registrationではなく、AAD側のログ）
この辺りを見ると、Azure ADの共通テナント（https://login.microsoftonline.com/common）上にAAD.BrokerPlugin用のクライアントがマルチテナント構成で登録されていることがわかります。
※この画面では、クライアントID「dd762716-544d-4aeb-a526-687b73838a22」が見えますが、他にも「a40d7d7d-59aa-447e-a655-679a4107e548」などが登録されています。
仕組みとしては、Windows 10のネイティブアプリケーションであるMicrosoft.AAD.BrokerPluginがAzure ADの情報にアクセスするために、共通のクライアントがAzure AD上に登録されており、そのクライアントを使ってAzure ADとやり取りをしているようです。Edgeを使ったデバイス->ブラウザのシングルサインオンにおけるPRT（Primary Refresh Token）からアクセストークンの取得でも活用されているので、知っておいて損はありません。
実際の動きはFiddlerでも見ることが出来ますが、無理やりブラウザを使ってリクエストを投げてみるとクライアントがどのような名前で登録されているか、くらいはわかります。
例えば、DRSへのアクセストークンを取得したい場合は、
https://login.microsoftonline.com/common/oauth2/authorize?
response_type=code%20token&
client_id=dd762716-544d-4aeb-a526-687b73838a22&
redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2Fdd762716-544d-4aeb-a526-687b73838a22&
resource=urn:ms-drs:enterpriseregistration.windows.net
を投げるとクライアントのDisplayNameは空白で、多要素認証を要求していることがわかります。
（実際は多要素認証に回答してもそのまま固まりますが）
同様にアカウント設定画面での操作は、
https://login.microsoftonline.com/common/oauth2/authorize?
response_type=code%20token&
client_id=a40d7d7d-59aa-447e-a655-679a4107e548&
redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2Fa40d7d7d-59aa-447e-a655-679a4107e548&
resource=https%3A%2F%2F<ドメイン名>
を投げるとクライアントが「Accounts Control UI」という名前で登録されていることがわかります。
（こちらはBad Requestになります）
このあたりはトラブルシューティングにはあんまり役に立ちませんが、内部の動きを知っておくのは良いことだと思います。
３．PIN生成時の通信をFilddlerでキャプチャする
この辺りも基本的なところなので、押さえておきたいところです。
Jairoのblog（翻訳版はこちら）を見ると、PIN登録時に「https://account.live.com/aadngc」へアクセスする、とありますが実際の動きはどうなっているのかを確認してみましょう。
Fiddlerのセットアップや基本的な操作方法については割愛しますが、ポイントは以下の2点です。
・ブラウザ以外のセッションもキャプチャする
・HTTPSの復号を有効にする
特にポイントになるのは、Windowsアプリケーションからの通信をキャプチャするという部分で、具体的にはFiddlerの左上のWinConfigをクリックして必要なアプリケーションを選択して保存を行います。
画面の中にアカウントや職場または学校アカウントなどが関連するのでチェックが入っているか確認しておきましょう。
この状態でPINのセットアップを行うと、以下のようなキャプチャが取得できます。
＜リクエスト＞
GET https://account.live.com/aadngc?uiflavor=win10&mkt=ja-JP&hasngc=0&platform=Windows10&scid=4&ctc=0&uiflavor=Win10 HTTP/1.1
Accept: text/html, application/xhtml+xml, image/jxr, */*
Accept-Language: ja
cxh-osVersionInfo: {"platformId":0,"majorVersion":10,"minorVersion":0,"buildNumber":14332}
hostApp: CloudExperienceHost
client-request-id: 872a9ff6-a81d-0000-0cad-2d871da8d101
cxh-protocol: ms-cxh
cxh-cxid: NGC
cxh-preferredLanguage: ja
cxh-correlationId: 872a9ff6-a81d-0000-0cad-2d871da8d101
cxh-source: ms-cxh://NTHAADNGCONLY/
cxh-osPlatform: CloudExperienceHost.Platform.DESKTOP
cxh-platform: CloudExperienceHost.Platform.DESKTOP
cxh-isRTL: false
cxh-colors: themeAccent=#0078d7;themeAccentLight1=#429ce3;themeAccentLight2=#76b9ed;themeAccentLight3=#a6d8ff;themeAccentDark1=#005a9e;themeAccentDark2=#004275;themeAccentDark3=#002642;themeTextApplication=#000000;themeTextSystem=#ffffff;
cxh-host: NTHAADNGCONLY
cxh-hostAppVersion: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; MSAppHost/3.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82 Safari/537.36 Edge/14.14332
Accept-Encoding: gzip, deflate
Host: account.live.com
Connection: Keep-Alive
Cookie: mkt=ja-JP; DID=5737
こうやって見ると、CXH（Cloud eXperience Host）が内部的には健在なことがわかりますね。レスポンスはHTMLが返ってきているので、CXH内での画面表示はHTMLであることがわかります。
その後、https://auth.gfx.msへのアクセスが続いた後、最終的にhttps://account.live.com/API/ReportClientEventへ以下のJSONがPOSTされます。
{
"pageApiId":"Account_AAD_NGC_Provisioning",
"clientDetails":[],
"userAction":"",
"source":"PageView",
"clientTelemetryData":{
"category":"PageLoad",
"pageName":"Account_AAD_NGC_Provisioning",
"eventInfo":{
"timestamp":1462676178361,
"perceivedPlt":2641,
"networkLatency":1874,
"networkType":null,
"precaching":null,
"bundleVersion":null,
"appVersion":null,
"deviceYear":null,
"isMaster":null,
"bundleHits":null,
"bundleMisses":null
}
},
"uiflvr":13,
"uaid":"872a9ff6a81d00000cad2d871da8d101",
"scid":100185,
"hpgid":"Account_AAD_NGC_Provisioning"
}
そして、最後に
https://enterpriseregistration.windows.net/EnrollmentServer/key/?api-version=1.0
に対して公開鍵をPOSTします。
{
"kngc":"UlNBMQAI...snip...tFNEC+U/BbJ+WU0pKD1tAOINB2w==",
"ak":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
}
こんな感じです。
尚、同様にFiddlerを使ってAzure ADへ参加する際の通信の流れやMicrosoft Passportの流れもキャプチャすることが出来ます。
例えば、Azure ADへ参加する時は、
- https://login.microsoftonline.com/WebApp/CloudDomainJoin/4へGET
- https://login.microsoftonline.com/common/.well-known/openid-configurationでOAuth関連のエンドポイント取得
- https://login.microsoftonline.com/common/oauth2/authorizeへclient_id：01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9で認可要求
という流れになります。
このあたりの細かい話は別途まとめてお話ししたいですね。
４．NGC（Next Generation Credential）のプロビジョニング状態を確認する
デバイスがAzure ADやオンプレミスのADへ参加しているかどうか、MDMでの管理状態はどうなっているのか、およびNGCがプロビジョニングされているかどうかを簡単にチェックするにはdsregcmd.exeを使います。
使い方としては、dsregcmd /statusとたたくだけです。
出力結果は2つのパートに分かれており、デバイスの状態およびユーザの状態を示します。（Windows 10 1511.10586.xxxの場合。14332だともっと項目が増えています）
| セクション | 項目 | 説明 |
|---|---|---|
| Device State | AzureAdJoined | Azure ADに参加しているかどうか |
| AzureAdDeviceId | Azure ADに登録されているデバイスのID | |
| AzureAdThumprint | Azure ADに登録されているデバイス証明書の拇印 | |
| AzureAdIdP | Azure ADのIdP | |
| AzureAdTenantId | Azure ADのテナントID | |
| AzureAdTenantName | Azure ADのテナント名 | |
| AzureAdMdmUrl | IntuneのURL | |
| AzureAdSettingsUrl | IntuneのURL | |
| DomainJoined | オンプレADドメインに参加しているかどうか | |
| DomainName | オンプレADドメイン名 | |
| User State | NgcSet | NGCがプロビジョニングされているかどうか |
| NgcKeyId | NGCのキーID | |
| WorkplaceJoined | ワークプレイスジョインしているかどうか | |
| WamDefaultSet | WebSSOに関する状態 | |
| WamDefaultAuthority | デフォルトで利用されるWebSSOのオーソリティ | |
| WamDefalutId | デフォルトで利用されるWebSSOのID | |
| WamDefalutGUID | デフォルトで利用されるWebSSOのGUID |
特徴的なのは、Workplace Joinはあくまでユーザ単位なので、User State側に分類されているところでしょうか。
例えば、オンプレミスADへドメイン参加した状態でデバイス情報をAzure ADへ同期するとAzureAdJoinedおよびDomainJoinedの両方がYesになります。
参考）Build 14332系でのdsregcmd /statusの結果
Device StateにEnterpriseJoinedという謎の項目が増えていたり、DRS関係の情報が出てきます。
User Stateこちらはあんまり変わりません。
５．TPMをクリアする
これは、TPMが搭載されているマシンを使っている場合に限りますが、キーペアがTPM上に保存される以上、Azure AD DRS上に登録された公開鍵とTPMコンテナ内の秘密鍵の紐づけがおかしくなってしまったらTPMをクリアするのも一つの手になるかも知れません。（根拠はありません。そういう事態に陥ったことはないので）
とりあえず手順だけを書いておくと、ファイル名を指定して実行（Windowsキー＋R）で「tpm.msc」を実行してTPMのクリアを選択して実行するだけです。
再起動が要求されます。
ここで再起動すると起動画面でTPMのクリアが行われます。（手順はデバイスによって異なります）
ちなみにAcerのPCではボリュームUPボタンを押すとクリアされました。
注）ここでTPMをクリアすると当然のことながらマイクロソフトアカウントやローカルアカウントでのログイン時のPINがすべて使えなくなります。パスワードがわからないとPCへログインすらできなくなりますので、慎重に実施する必要があります。同じく、EFSやBitLockerなどに関しても要注意です。
まぁ、色々と書きましたが、トラブルシュートの基本は状態の把握だと思うので、イベントログや通信のキャプチャなどは覚えておいて損はないですね。
おまけ）
ちなみにPIN設定をキャンセルしようとすると以下の画面が出て、頑張って設定させようとしてきます。一旦キャプチャしたいのでスキップしたかったんですけどね。。こういう場合はあえてエラー状態を作っておくと先に進めます。（メッセージの焦った感じがウケます）
2016年4月28日木曜日
[AD FS/Windows Server 2016]Microsoft Passportがやってきた
こんにちは、富士榮です。
昨日よりWindows Server 2016の新しいプレビュー版のTechnical Preview 5が公開されていますので、早速AD FS周りを見てみました。
（今回は触りだけです）
一番の変更点は「認証方法にMicrosoft Passportが選択できるようになっている！！」ことです。
これで、ようやくハイブリッド構成においてもMicrosoft Passportを使ったデバイス・ブラウザ間のシングルサインオンが実現できるようになります。
このイメージ+Federation構成ですね。（MVP Comcampで使った資料より）
http://www.slideshare.net/naohiro.fujie/azure-adwindows-10
取り敢えず今回は画面だけ紹介です。
認証方法の設定です。
初期状態でIntranetもExtranetもMicrosoft Passportが選択されています。
Editをクリックして詳細を見てみます。
これを使えば、これまでの社内からは統合Windows認証によるデバイス・ブラウザ間のSSO、社外からはフォーム認証（SSOなし）という使い分けではなく、社内・社外に問わないユーザ・エクスペリエンスが提供できるようになるので、非常に便利ですね。
昨日よりWindows Server 2016の新しいプレビュー版のTechnical Preview 5が公開されていますので、早速AD FS周りを見てみました。
（今回は触りだけです）
一番の変更点は「認証方法にMicrosoft Passportが選択できるようになっている！！」ことです。
これで、ようやくハイブリッド構成においてもMicrosoft Passportを使ったデバイス・ブラウザ間のシングルサインオンが実現できるようになります。
このイメージ+Federation構成ですね。（MVP Comcampで使った資料より）
http://www.slideshare.net/naohiro.fujie/azure-adwindows-10
取り敢えず今回は画面だけ紹介です。
認証方法の設定です。
初期状態でIntranetもExtranetもMicrosoft Passportが選択されています。
Editをクリックして詳細を見てみます。
これを使えば、これまでの社内からは統合Windows認証によるデバイス・ブラウザ間のSSO、社外からはフォーム認証（SSOなし）という使い分けではなく、社内・社外に問わないユーザ・エクスペリエンスが提供できるようになるので、非常に便利ですね。
2015年11月28日土曜日
[AD FS]Windows Server 2016 Technical Preview 4／TokenエンドポイントのBASIC認証
こんにちは、富士榮です。
先日Windows Server 2016のTechnical Preview 4が出たので、AD FSがどうなったのかを見ていきたいと思います。
まずOpenID ConnectのRP（Relying Party）を作る上で個人的に一番気になっていたTokenエンドポイントのクライアント認証を見てみました。
一般的なRPの開発ドキュメントを見ているとOAuth2.0のCode Flowを使う際、code取得後にTokenエンドポイントへのPOST時のクライアント認証はBASIC認証で実装されていることが多いですし、RFCのサンプルもそうなっているのですが、Azure Active DirectoryやAD FSのTokenエンドポイントはBASIC認証をサポートしていませんでした。
Windows Server 2016ではこのあたりが改修されることになっており、前回のTechnical Preview 3の.well-known/openid-configurationを見ると以下のようにclient_secret_basicもサポートされていることがわかります。
しかし、Technical Preview 3で実際にTokenエンドポイントでBASIC認証を使おうとすると、invalid_clientと言われてHTTP 400が返ってきてしまいました。
ということで、今回出たTechnical Preview 4ではどこまで治ったのかを見てみます。
codeを取得した後、TokenエンドポイントへのPOST時のAuthorizationヘッダにclient_idとclient_secretを":"で接続してbase64エンコードした文字列をBasicに続けて設定します。
結果、いけました！
これでこれまで他のOpenID Provider向けに作ったクライアントをAD FS用に変更する必要がなくなりましたね。
ただ、現状までAzure ADはまだclient_secret_postとprivate_key_jwtしかサポートしていないみたいです。今後に期待ですね。。
先日Windows Server 2016のTechnical Preview 4が出たので、AD FSがどうなったのかを見ていきたいと思います。
まずOpenID ConnectのRP（Relying Party）を作る上で個人的に一番気になっていたTokenエンドポイントのクライアント認証を見てみました。
一般的なRPの開発ドキュメントを見ているとOAuth2.0のCode Flowを使う際、code取得後にTokenエンドポイントへのPOST時のクライアント認証はBASIC認証で実装されていることが多いですし、RFCのサンプルもそうなっているのですが、Azure Active DirectoryやAD FSのTokenエンドポイントはBASIC認証をサポートしていませんでした。
Windows Server 2016ではこのあたりが改修されることになっており、前回のTechnical Preview 3の.well-known/openid-configurationを見ると以下のようにclient_secret_basicもサポートされていることがわかります。
"token_endpoint_auth_methods_supported":["client_secret_post","client_secret_basic","private_key_jwt","windows_client_authentication"],
しかし、Technical Preview 3で実際にTokenエンドポイントでBASIC認証を使おうとすると、invalid_clientと言われてHTTP 400が返ってきてしまいました。
ということで、今回出たTechnical Preview 4ではどこまで治ったのかを見てみます。
codeを取得した後、TokenエンドポイントへのPOST時のAuthorizationヘッダにclient_idとclient_secretを":"で接続してbase64エンコードした文字列をBasicに続けて設定します。
結果、いけました！
これでこれまで他のOpenID Provider向けに作ったクライアントをAD FS用に変更する必要がなくなりましたね。
ただ、現状までAzure ADはまだclient_secret_postとprivate_key_jwtしかサポートしていないみたいです。今後に期待ですね。。
2015年11月13日金曜日
[Windows 10]TH2新機能 - BYOD（WorkPlace Join）でMicrosoft Passportを使う
こんにちは、富士榮です。
Windows 10初の大型アップデートである「Threshold 2」が公開されましたので、早速新機能を順番に見ていきたいと思います。
なんといってもアイデンティティ屋さんにとっての一番大きなアップデートはBYODシナリオにおけるMicrosoft Passportのサポートです。
これまではAzure AD JoinのシナリオでしかMicrosoft Passportが使えず、職場のアカウントを追加（WorkPlace Join）してもOffice 365などへのシングルサインオンはできませんでしたが、今回のビルドからはMicrosoft Passportが使えるようになったので、BYODシナリオでもしっかりシングルサインオンしてくれます。
では、早速設定してみます。
今回は、ローカルアカウントを使ってPCにログインしていますが、その状態でアカウントの設定を開き、職場のアクセスメニューを開くと、これまでのビルドとは大きく異なるメニュー構成となっていますので、Azure ADにサインインをしてみます。
すると、なぜかメールとアカウントの画面に飛ばされるので、「他のアプリで使われるアカウント」から「職場または学校アカウントを追加」をクリックします。
お決まりのAzure ADへのログイン画面が出てくるのでサインインしていきます。
多要素認証が必要なので、通知が飛ばされます。
ポリシーが適用されていきます。
このあたりのポリシーの中身はIntuneなんかで設定します。
作業PINの作成が要求されます。
作業PINなのか職場用PINなのかいまいちわかりませんが、気にせずPINを登録します。
作成が終わると準備完了！と言われます。
アカウントが追加されていることが確認できます。
さて、ここまでで準備は完了ですので、早速ログインしてみます。
そのままブラウザを起動し、アクセスパネルなどAzure ADと連携しているアプリケーションを立ち上げると、Microsoft Passportが有効になり、シングルサインオンされます。
なお、Azure AD上に登録されたデバイスを確認してみると、WorkPlace Join端末であることがわかります。
今後、Windows Server 2016も出てきますので、Microsoft Passportの適用範囲もさらに広がってくると思いますので、非常に楽しみな分野です！
Windows 10初の大型アップデートである「Threshold 2」が公開されましたので、早速新機能を順番に見ていきたいと思います。
なんといってもアイデンティティ屋さんにとっての一番大きなアップデートはBYODシナリオにおけるMicrosoft Passportのサポートです。
これまではAzure AD JoinのシナリオでしかMicrosoft Passportが使えず、職場のアカウントを追加（WorkPlace Join）してもOffice 365などへのシングルサインオンはできませんでしたが、今回のビルドからはMicrosoft Passportが使えるようになったので、BYODシナリオでもしっかりシングルサインオンしてくれます。
では、早速設定してみます。
今回は、ローカルアカウントを使ってPCにログインしていますが、その状態でアカウントの設定を開き、職場のアクセスメニューを開くと、これまでのビルドとは大きく異なるメニュー構成となっていますので、Azure ADにサインインをしてみます。
すると、なぜかメールとアカウントの画面に飛ばされるので、「他のアプリで使われるアカウント」から「職場または学校アカウントを追加」をクリックします。
お決まりのAzure ADへのログイン画面が出てくるのでサインインしていきます。
多要素認証が必要なので、通知が飛ばされます。
ポリシーが適用されていきます。
このあたりのポリシーの中身はIntuneなんかで設定します。
作業PINの作成が要求されます。
作業PINなのか職場用PINなのかいまいちわかりませんが、気にせずPINを登録します。
作成が終わると準備完了！と言われます。
アカウントが追加されていることが確認できます。
さて、ここまでで準備は完了ですので、早速ログインしてみます。
そのままブラウザを起動し、アクセスパネルなどAzure ADと連携しているアプリケーションを立ち上げると、Microsoft Passportが有効になり、シングルサインオンされます。
なお、Azure AD上に登録されたデバイスを確認してみると、WorkPlace Join端末であることがわかります。
今後、Windows Server 2016も出てきますので、Microsoft Passportの適用範囲もさらに広がってくると思いますので、非常に楽しみな分野です！
2015年9月26日土曜日
[AD FS]OpenID Connectに対応した次期AD FSを試す（UserInfo編）
こんにちは、富士榮です。
先月のポストでは、Windows Server 2016のTechnical Preview 3に搭載される新AD FSのOpenID Connectへの対応の概要を紹介しました。
[AD FS]OpenID Connectに対応した次期AD FSを試す
http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html
また、同じく既にOpenID Connectに対応しているAzure Active Directory（Azure AD）について、userinfoエンドポイントを使ってユーザ情報を取得する方法についても紹介しました。
[Azure AD]OpenID ConnectのUserInfoエンドポイントを使ってユーザ情報を取得する
http://idmlab.eidentity.jp/2015/08/azure-adopenid-connectuserinfo.html
と、いうことで今回は新AD FSのUserInfoエンドポイントよりユーザ情報を取得できるかどうか確認して見たいと思います。
◆エンドポイントを確認する
前回同様、/adfs/.well-known/openid-configurationをGETして各種エンドポイントの情報を確認すると、UserInfoエンドポイントは
"userinfo_endpoint":"https://adfs.example.com/adfs/userinfo"
であることがわかります。
別の方法としては、AD FSの管理コンソールから登録されているエンドポイント一覧を確認することもできるので、コンソールアクセスできる場合はそちらから確認しても大丈夫です。
◆クライアント登録する
次に、UserInfoを取得するクライアントを登録します。
新しいAD FSでは、「Application Groups」メニューよりアプリケーション・グループを作成し、その中にアプリケーション（クライアント）を登録します。
今回はダミークライアントでOKなので、以下のパラメータで登録しました。
・Template：Standalone applications - Server application or Website
・Redirect URI：http://localhost
・Application Credentials：Generate a shared secret
以下、登録ウィザードの画面です。
◆UserInfoへアクセスするためのアクセストークンを取得する
code flowでアクセストークンを取得していきますので、まずは認可エンドポイントへアクセスし、認可コードを取得します。
UserInfoエンドポイントからプロファイル情報やメールアドレスなどの情報も取得したいので、scopeにはopenid profile emailを指定します。
結果、Redirect URIに指定したアドレスにクエリパラメータとして認可コードが返ってきます。
このcode=xxxの部分が認可コードです。
次に取得した認可コードをトークンエンドポイントにPOSTしてアクセストークンを取得します。
すると、アクセストークン、リフレッシュトークン、IDトークンが返ってきます。
ん？なぜかscopeがopenidのみになってしまっていますね。。。
いやな予感しかしません。
◆UserInfoエンドポイントへアクセスする
取得したアクセストークンをAuthorizationヘッダに入れてGETします。
やはりsubしか返ってきません。profileとかemailがscopeから消えてしまっているからですかね。。
AD FSの管理コンソールから定義されているscope一覧を見るとちゃんとprofileやemailもあるんですけどね。
まだTechnical Preview版なので、こんなものなのかも知れません。今後の進化に期待ですね。
先月のポストでは、Windows Server 2016のTechnical Preview 3に搭載される新AD FSのOpenID Connectへの対応の概要を紹介しました。
[AD FS]OpenID Connectに対応した次期AD FSを試す
http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html
また、同じく既にOpenID Connectに対応しているAzure Active Directory（Azure AD）について、userinfoエンドポイントを使ってユーザ情報を取得する方法についても紹介しました。
[Azure AD]OpenID ConnectのUserInfoエンドポイントを使ってユーザ情報を取得する
http://idmlab.eidentity.jp/2015/08/azure-adopenid-connectuserinfo.html
と、いうことで今回は新AD FSのUserInfoエンドポイントよりユーザ情報を取得できるかどうか確認して見たいと思います。
◆エンドポイントを確認する
前回同様、/adfs/.well-known/openid-configurationをGETして各種エンドポイントの情報を確認すると、UserInfoエンドポイントは
"userinfo_endpoint":"https://adfs.example.com/adfs/userinfo"
であることがわかります。
別の方法としては、AD FSの管理コンソールから登録されているエンドポイント一覧を確認することもできるので、コンソールアクセスできる場合はそちらから確認しても大丈夫です。
◆クライアント登録する
次に、UserInfoを取得するクライアントを登録します。
新しいAD FSでは、「Application Groups」メニューよりアプリケーション・グループを作成し、その中にアプリケーション（クライアント）を登録します。
今回はダミークライアントでOKなので、以下のパラメータで登録しました。
・Template：Standalone applications - Server application or Website
・Redirect URI：http://localhost
・Application Credentials：Generate a shared secret
以下、登録ウィザードの画面です。
◆UserInfoへアクセスするためのアクセストークンを取得する
code flowでアクセストークンを取得していきますので、まずは認可エンドポイントへアクセスし、認可コードを取得します。
UserInfoエンドポイントからプロファイル情報やメールアドレスなどの情報も取得したいので、scopeにはopenid profile emailを指定します。
https://adfs.example.com/adfs/oauth2/authorize/
client_id=2155e727-7560-4e2f-985d-274a91691af9&
response_type=code&
redirect_uri=http%3A%2F%2Flocalhost&
scope=openid%20profile%20email&
state=12345
結果、Redirect URIに指定したアドレスにクエリパラメータとして認可コードが返ってきます。
http://localhost/?
code=fcCKuMdQjUmSBo8l1mZWFA.XE6TFE7G0ggOAPXOTd4Eag7n30A.ENQ1pomEwEqzzWB_-q3HhwKX0pYq0mAuN-o_6qa4JAiMD8lWIbvaxThqlbkE8SAkZ4Ik0RfbuzdqHfzEjXSj_U513DgjLyq5VmPt34nLmcs9BhpoBjZJY84b-0rmiWmCe8lbHZHb1ENQy7KbytmDwC7j_fRjzXDkAcr9ReeFkQPl6PCe7mSOTvGOEpi04YrzDeY6tk_YKMPpRv8d2YnKd4R3qMAUKCfeNfhgOdua8xTcVDj0d-9bDVIW5GKD6Agydu1xsnTv3Mzm_UirAWMTpRQtpbtRJZUt3fdNSQAxpgst3H7qbG3Iy7bmfYb2FpxmP02BMHikr36vS09tTk6KnA&
state=12345
このcode=xxxの部分が認可コードです。
次に取得した認可コードをトークンエンドポイントにPOSTしてアクセストークンを取得します。
https://adfs.example.com/adfs/oauth2/token
grant_type: authorization_code
client_id: 2155e727-7560-4e2f-985d-274a91691af9
code: fcCKuMdQjUmSBo8l1mZWFA.XE6TFE7G0ggOAPXOTd4Eag7n30A.ENQ1pomEwEqzzWB_-q3HhwKX0pYq0mAuN-o_6qa4JAiMD8lWIbvaxThqlbkE8SAkZ4Ik0RfbuzdqHfzEjXSj_U513DgjLyq5VmPt34nLmcs9BhpoBjZJY84b-0rmiWmCe8lbHZHb1ENQy7KbytmDwC7j_fRjzXDkAcr9ReeFkQPl6PCe7mSOTvGOEpi04YrzDeY6tk_YKMPpRv8d2YnKd4R3qMAUKCfeNfhgOdua8xTcVDj0d-9bDVIW5GKD6Agydu1xsnTv3Mzm_UirAWMTpRQtpbtRJZUt3fdNSQAxpgst3H7qbG3Iy7bmfYb2FpxmP02BMHikr36vS09tTk6KnA
redirect_uri: http://localhost
client_secret: 6MsbJZTFr2ZEC-BNb8c6rRdIolxCm_c1HgA5hHFQ
すると、アクセストークン、リフレッシュトークン、IDトークンが返ってきます。
{
"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCJ9.eyJhdWQiOiJ1cm46bWljcm9zb2Z0OnVzZXJpbmZvIiwiaXNzIjoiaHR0cDovL3RwMy5hZGZzMjAubmV0L2FkZnMvc2VydmljZXMvdHJ1c3QiLCJpYXQiOjE0NDMyNTY4MDYsImV4cCI6MTQ0MzI2MDQwNiwiYXBwdHlwZSI6IkNvbmZpZGVudGlhbCIsImFwcGlkIjoiYTgyNDg4NWItYzVkOS00ZDNhLWI2OWEtN2M4OTZiODBhZjhkIiwiYXV0aG1ldGhvZCI6InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0IiwiYXV0aF90aW1lIjoiMjAxNS0wOS0yNlQwODo0MDowNi41NjRaIiwidmVyIjoiMS4wIiwic2NwIjoib3BlbmlkIiwic3ViIjoiajhtMUZBT3hVWE5ZeFpxZHMwYkVNZG9MM1gybTZLcFA2Wkt4elZQYW42TT0ifQ.fNmEOEARGbWURRoRazcW36jgtw0a3h4i7Z5--UC9nLB0mFFjZVxcJe4-1hhaCQExn04oUD9-HXXI4BFKkbctWNJJKUo8kT4kAn_Uj8J10INYUAJA5veKis1MdUIZ7glpEfMzEvzjrTGnMhN4v4y_CEzziU0LB1nGogozOkDOD3Y6gfaUJbrOv4V8lbmjm9cuMNDRs6ZEwGf5aqc2ChAbWw2icqW3XBwTnUR_X0je2LKmwjcljY145-fybEgUbFANbAnSSC8WOcS-KGOKzlqIbf3AxQ1PaetMGAb02N25KM36b24I9yzDPDs8EmKgL4mSfjTPHxnUWCu7UB4wMcfvIw",
"token_type":"bearer",
"expires_in":3600,
"resource":"urn:microsoft:userinfo",
"refresh_token":"5dC-njXY426ezdn5gD3F0I303XUf7otp3hxwUTfPuXgAAQAAknmNeJNokXbBjoJ8_0szNQ6IyCQ0jM7VerjRPZl-fnpGzMz7eT6p6CZ2IUh2o_uv09DZZkLCKemeEdZakCQ84goI6drbRYXuCGCgjeZ4OXXJWshjLrO94qWD7hLeVxScBna7ZKDik2zU5ep4yQxljkIGcHzH4csh9cumG_Yr_SntMDdvXYGkVhT3DDf68hKn_fqWTCYygN5cRol3OjlX5ipVL-8x73ndaaqdrYfNVtacjIJmdgqm4qmfOi89kjajlt3VLXAqWfkdwRupLbmvQ4uXunriR9tYq-67zJcok2SD1m4Us9qeS9PEKLdjIeKzQusUKaO8rH0yYp4D3sZamHAFAABfIdD674BFeJV6xPKn3Rk7NmrZeSPKi5GY70mzUy0qjIwx93kKGV83INvNgkB608h5ZR4m-VrNMjxUZjIF6cCtxcrz85cjcCqj99W0pxXm_5-GzfBN1lUxhejAuWZxX-3LK05yTiWoSvSoqJUYDE2tyHQ4kX42dWqWv1QerfOo54QZQ72H8DWNNvxhAslDFrnQlJr9Y-h5ppaPpU2F9ViBKlJx6d0R8gIZs6ZJfgkgMG4X8Lw0K3OuM4vHBfVmBSSEAqCNMm8SLwI4i0Y6hb9G-WXGjd2c0SvgsOBWNvptWEdD571ggr2RUgyYqPHP5Aj3368mwKoHiWfdDR07YCIlk889lLhnA3kD2LItaYGgTuJ65N2kpiPoyc6EaTo-Nr961ERjxz9ajZijD69Ck6z6VRkqbphfhNXEVMop2ZJLW5dkXDiFoBMuM0oV95hjuwgBOHwUfTfM0RkjjEauARSN4DjV3enuWfIUKTCGFo-meI_Jt2c5mQ80U-7Fxfy2RxhbuJgXRa37I4YEtbeMBptu_o_vSvSqF__Z9fgpuWXYLJfpTfi0VI5k9GfJvmZm7zisyyRsEh1mWlDJdgE9hwl6GCIaoAd2kjrJmPnnNJrguOvwAXLCZVsY6IQxk8OsUjnZQ9a1OgdrAgHE3W0LRMPi6qEvNkKKlQxIoV4K0gyXrWnx752_7LCHfpGmKBG6Ot0FhVrw5z1JcAClBSv_4gWuKpkvXu6x8Ne4Km6dzmsVWsN7GyX3M9GUsW05CDASJ9KAbGbKNPeQpp8FBFdnooULAcb0KqGtPBDIu4dazZtpFMK2l9le2kfvaJOB87S1wod5CsR2ms5A6EDKcMOaXVmMl1H5MR_Mdae1057KulOze0HtQoebKRZHJHZL5DWE0r7qKUtINxz1LQ2eMAitcslcJCpD_j09YtOpkZIIhJzjx7kyisgv5yEoIh_qOTvMAr97wnewU63ZgYAHUdGPVBgOFKKuew_I0bIOIj4ZKk3qpXFdzdpYVXewy9VIffOkISlszUyjhL6xnU_W26M0YfWu4KDOpysTSF_rvPJXfix4eRc0CdeARCiYx4SJHzz8IzDEkCZwdy9zcpfufGphEfM3Pixey00xT5v0pACNMhvfBFD4-jY26iZbjMdiXr9hLlH1-GkOzkuNartjNiCN-vms3ris4Ywau3POuSoKCfmxLCzGORCw5t2K7AhQ85dVb6b8dqqcXD4-LsNOxgYWfGD4r064X1ZEOzhVZBBmttp0dipuV84ZQnc6gkc7AugipBYGv_T-UMsU8jyw99Y-hPCx0ZpQRB97T_LZz9yVqDqPGFFM1-72RMhJK6yK_smFXvd8rTXuKFewRhaRNa0I5ezBTcxm--DoHjBmyOycrd9O_3NddIMoVAXGQt9IS6QmoHyJGxF2rMFXlAidew2Ws_BojU6XSRBbRh91o-y5oZ94PvviDqxI6DtJFZpKNrNKBwlbUregs8cmHsZiTj3MgplzDJOf02aygRJ8is-XvQB--UWS4lMLrUIV7c40BlpsTuC2KDQUPx-LKcoUG0TqGcqG4bj2T4uzxr9oY5ZH5n8YSW2ZVnVXhvh-CyP-uVdfRULx9ZCBDGT4QD4h_r5dw1rSU72_XBCDzVGcWOEGx1Rfnm3v4uyjHCr0NZQtznOWf1-gBdQ_4GhUsiJsU8Wdev6J7Ul3733hm8o78I7GSbfr1rRtT9_UjX7cmrViHMPZr5uzGge7y4EAMf-bV6gse91mx_0z-sCriEjr8Ull7rsQedN5hlTbuDOHkc_jVp0jvcK7vlGVtJmSfsUZeMrGKxqGKkEYzb3Xn4OweYiCwGhx1ATCV-xAPTBHAGtyMX4e47Q.YEBU6-rJ4Ah-VZXWpoXirCIynU_JT2Ox5UMvD1CZnV1y7MuCib2uKFmwymSnk2iJe5FY4CfG-4AIK9Di4l9n82viNxRvcXh5mKD6wOd4xvh92N3_odYry72HXe6PtJa42gp5zdTDgoLkyXmJkyO04oguyuUhvbDK7VDoJQmAolCOG4IOM7LqvrvKRPs34uzFUrMlko0dLOCgECTT1XvzIigEb23HNQpOBJybwHw6zcpfkvNH-Lqa-70qbo9Rkjb3G9A9hb1G_IojZie3vaYGmwVKNwXKg9Y7p7wzgrnwWEyDKt1JdoMcVCXho7bvx-SpAGgdqWWMR11zDtR5OR4e8g",
"refresh_token_expires_in":28799,
"scope":"openid",
"id_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCIsImtpZCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCJ9.eyJhdWQiOiJhODI0ODg1Yi1jNWQ5LTRkM2EtYjY5YS03Yzg5NmI4MGFmOGQiLCJpc3MiOiJodHRwczovL3RwMy5hZGZzMjAubmV0L2FkZnMiLCJpYXQiOjE0NDMyNTY4MDYsImV4cCI6MTQ0MzI2MDQwNiwiYXV0aF90aW1lIjoxNDQzMjU2ODA2LCJzdWIiOiJqOG0xRkFPeFVYTll4WnFkczBiRU1kb0wzWDJtNktwUDZaS3h6VlBhbjZNPSIsInVwbiI6Im5mdWppZUB0cDMuYWRmczIwLm5ldCIsInVuaXF1ZV9uYW1lIjoiVFAzXFxuZnVqaWUiLCJwd2RfZXhwIjoiNTE5ODk5In0.iCRZlDKci_QxsCEY-m_AwKeZCO1wj95SRSZNyxslaQheMt2oOG9gh8cueFBowOeGRxg76vUbjqt8qIpH5JkV1iFBevTLmD8m_JggTdkL_n2WO-zGzVLKV48li6zL2y2VnakNwgERKaH9ccv_A3p81oPZf9coPJtphA0Z8CjM5xMTOJNpK3Oi_E7PtSw0ft8s1WBPKvA-TEvDqRVbiBwTuucazjF4rDdoIvAAMvr2PZfP3Rz-DzdEfprN7DLrKGtawQIzr3G2vhYIKaCZjC4kX4ys-MBK7dVJKZ4w2fT86iYVrOrkem6e4OCCiZFhgbDKLoo9y5VZAYt5eYoVDzNDvQ"
}
ん？なぜかscopeがopenidのみになってしまっていますね。。。
いやな予感しかしません。
◆UserInfoエンドポイントへアクセスする
取得したアクセストークンをAuthorizationヘッダに入れてGETします。
https://adfs.example.com/adfs/userinfo
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlFsOVdvTDVNQ1FCZTdlSzZjdjc4T2RLTzFpMCJ9.eyJhdWQiOiJ1cm46bWljcm9zb2Z0OnVzZXJpbmZvIiwiaXNzIjoiaHR0cDovL3RwMy5hZGZzMjAubmV0L2FkZnMvc2VydmljZXMvdHJ1c3QiLCJpYXQiOjE0NDMyNTY4MDYsImV4cCI6MTQ0MzI2MDQwNiwiYXBwdHlwZSI6IkNvbmZpZGVudGlhbCIsImFwcGlkIjoiYTgyNDg4NWItYzVkOS00ZDNhLWI2OWEtN2M4OTZiODBhZjhkIiwiYXV0aG1ldGhvZCI6InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0IiwiYXV0aF90aW1lIjoiMjAxNS0wOS0yNlQwODo0MDowNi41NjRaIiwidmVyIjoiMS4wIiwic2NwIjoib3BlbmlkIiwic3ViIjoiajhtMUZBT3hVWE5ZeFpxZHMwYkVNZG9MM1gybTZLcFA2Wkt4elZQYW42TT0ifQ.fNmEOEARGbWURRoRazcW36jgtw0a3h4i7Z5--UC9nLB0mFFjZVxcJe4-1hhaCQExn04oUD9-HXXI4BFKkbctWNJJKUo8kT4kAn_Uj8J10INYUAJA5veKis1MdUIZ7glpEfMzEvzjrTGnMhN4v4y_CEzziU0LB1nGogozOkDOD3Y6gfaUJbrOv4V8lbmjm9cuMNDRs6ZEwGf5aqc2ChAbWw2icqW3XBwTnUR_X0je2LKmwjcljY145-fybEgUbFANbAnSSC8WOcS-KGOKzlqIbf3AxQ1PaetMGAb02N25KM36b24I9yzDPDs8EmKgL4mSfjTPHxnUWCu7UB4wMcfvIw
やはりsubしか返ってきません。profileとかemailがscopeから消えてしまっているからですかね。。
{"sub":"j8m1FAOxUXNYxZqds0bEMdoL3X2m6KpP6ZKxzVPan6M="}
AD FSの管理コンソールから定義されているscope一覧を見るとちゃんとprofileやemailもあるんですけどね。
まだTechnical Preview版なので、こんなものなのかも知れません。今後の進化に期待ですね。
登録:
投稿 (Atom)
投稿
