sidebarIdM実験室いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。後は、関連するニュースなどを徒然と。AD参加の裏側こんにちは、富士榮です。ゴールデンウィークも終わりですね。Service)の裏側の仕組みの話です。出るという状況になっていました。こんなエラーが出ます。みなさん困っていたようで、各所に情報が出始めていました。ADから切り離して再参加する、と書いてあるのですが、多要素認証を要求する設定をしていないにもかかわらずこのエラーがでたり、多要素認証を実施してもエラーがでたり、そもそも再参加しても状況が改善しない、という状態でした。creation◆トラブルシューティングとして何をする/したのか先に書いたように今回はトラブルシューティングをしても一向に解決しなかったので、中の人に泣きついた結果障害が発覚して収束したんですが、トラブルシューティングの過程を残しておくことも今後の役に立つと思ったので少し残しておきます。1.イベントログを確認するユーザがデバイスを登録する際、クライアント側のイベントログに様々な情報が記録されます。Registrationで、必要に応じてAADについても見ることになります。RegistrationのAdminログにID:301のエラーが発生していました。privilegesが出ていますので、先の多要素認証が正常に実行されていない時と同じエラーだと判断されたようです。DRSへNGCを登録する際の動きを推測することが出来ます。ADディレクトリから探し出す3.クライアントで生成した鍵ペアより公開鍵を登録するとなっています。(細かくは省きますが、OOBEでのセットアップ時(WinPE)かどうか判別したり、レジストリからNGC関連の情報を読み取ろうとしたり、と前処理では他にも色々とやっています)順番に見ていきます。DRSのエンドポイントの検出です。ここは障害が発生している間もうまく動いていました。検出は以下の2つのXMLドキュメントを使ってクライアント・コンフィグレーションをAzureから取得するところからスタートします。https://clientconfig.microsoftonline-p.net/FPURL.xmlhttps://clientconfig.microsoftonline-p.net/fplist.xmlここで主にやっているのは、通常のテナント(MicrosoftOnline.com)なのか、中国用テナント(partnet.microsoftonline.com)なのかの判別をして、必要なIdPのURLを取得するところです。この後、ユーザのドメイン名からDRSや関連するエンドポイントを検出し、その結果がイベントログに記録されます。AD上でのリソースURI、OAuth関連のエンドポイントが検出されています。DRSは受付けません。APIで状態の確認ができます。-Allで一覧を取得した結果はこんな感じです。AD参加したデバイスです。Joined」となります。Intuneで管理されている状態だとDeviceTrustLevelがCompliantに、単純にデバイスが登録されただけの状態だとAuthenticatedになります。registered」というメッセージが出ます。Registrationのデバッグログを有効にしました。RegistrationのDebugログを有効にします。デバッグログを有効化することで膨大なログ(PIN登録部分だけで1000件近く)が出ますが、より細かい状態を把握できます。今回のケースだとID:502で以下の3つのエラーが記録されていました。・NGC登録時にサーバーエラー(400)後半2つは最初のエラーに起因するものだと思われるので、一番の原因はディスカバリだった、ということですね。ちなみに事象が解消した現在でもfplist.xmlにDRS要素はないので、fplist.xmlのパース処理自体に問題があった、ということだと思います。イベントログはこんな感じです。ADの関連を知るこれは今回のトラブル解消には全く関係ありませんでしたが、イベントログを見て行く過程でAADのイベントログにこんな情報が出ていました。ADの共通テナント(https://login.microsoftonline.com/common)上にAAD.BrokerPlugin用のクライアントがマルチテナント構成で登録されていることがわかります。※この画面では、クライアントID「dd762716-544d-4aeb-a526-687b73838a22」が見えますが、他にも「a40d7d7d-59aa-447e-a655-679a4107e548」などが登録されています。ADとやり取りをしているようです。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は空白で、多要素認証を要求していることがわかります。UI」という名前で登録されていることがわかります。Requestになります)このあたりはトラブルシューティングにはあんまり役に立ちませんが、内部の動きを知っておくのは良いことだと思います。3.PIN生成時の通信をFilddlerでキャプチャするこの辺りも基本的なところなので、押さえておきたいところです。Jairoのblog(翻訳版はこちら)を見ると、PIN登録時に「https://account.live.com/aadngc」へアクセスする、とありますが実際の動きはどうなっているのかを確認してみましょう。Fiddlerのセットアップや基本的な操作方法については割愛しますが、ポイントは以下の2点です。・ブラウザ以外のセッションもキャプチャする・HTTPSの復号を有効にする特にポイントになるのは、Windowsアプリケーションからの通信をキャプチャするという部分で、具体的にはFiddlerの左上のWinConfigをクリックして必要なアプリケーションを選択して保存を行います。画面の中にアカウントや職場または学校アカウントなどが関連するのでチェックが入っているか確認しておきましょう。この状態でPINのセットアップを行うと、以下のようなキャプチャが取得できます。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"}こんな感じです。Passportの流れもキャプチャすることが出来ます。ADへ参加する時は、https://login.microsoftonline.com/WebApp/CloudDomainJoin/4へGEThttps://login.microsoftonline.com/common/.well-known/openid-configurationでOAuth関連のエンドポイント取得https://login.microsoftonline.com/common/oauth2/authorizeへclient_id:01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9で認可要求という流れになります。このあたりの細かい話は別途まとめてお話ししたいですね。ADやオンプレミスのADへ参加しているかどうか、MDMでの管理状態はどうなっているのか、およびNGCがプロビジョニングされているかどうかを簡単にチェックするにはdsregcmd.exeを使います。/statusとたたくだけです。出力結果は2つのパートに分かれており、デバイスの状態およびユーザの状態を示します。1511.10586.xxxの場合。State側に分類されているところでしょうか。ADへ同期するとAzureAdJoinedおよびDomainJoinedの両方がYesになります。StateにEnterpriseJoinedという謎の項目が増えていたり、DRS関係の情報が出てきます。Stateこちらはあんまり変わりません。DRS上に登録された公開鍵とTPMコンテナ内の秘密鍵の紐づけがおかしくなってしまったらTPMをクリアするのも一つの手になるかも知れません。いう事態に陥ったことはないので)とりあえず手順だけを書いておくと、ファイル名を指定して実行(Windowsキー+R)で「tpm.msc」を実行してTPMのクリアを選択して実行するだけです。再起動が要求されます。ここで再起動すると起動画面でTPMのクリアが行われます。(手順はデバイスによって異なります)ちなみにAcerのPCではボリュームUPボタンを押すとクリアされました。注)ここでTPMをクリアすると当然のことながらマイクロソフトアカウントやローカルアカウントでのログイン時のPINがすべて使えなくなります。パスワードがわからないとPCへログインすらできなくなりますので、慎重に実施する必要があります。EFSやBitLockerなどに関しても要注意です。書きましたが、トラブルシュートの基本は状態の把握だと思うので、イベントログや通信のキャプチャなどは覚えておいて損はないですね。おまけ)ちなみにPIN設定をキャンセルしようとすると以下の画面が出て、頑張って設定させようとしてきます。キャプチャしたいのでスキップしたかったんですけどね。いう場合はあえてエラー状態を作っておくと先に進めます。よりアクセス解析を行っています。品質向上のみを目的とし、個人の特定などを目的とはしておりません。中で公開されることはあります。問い合わせ不明点等は管理人までご連絡ください。本プライバシーポリシーは予告なく変更/削除することがあります。プライバシーに関するトラブルについては一切の責任を負いかねますのでご了承ください。