皆さんこんにちは。国井です。
いよいよADFSテキスト全文公開チャレンジも最終回になりました。
最終回はトラブルシューティングについて解説します。
■ ■ ■
ADFS では、設定項目が多岐にわたるため、設定を誤るなどしてトラブルが発生すると、トラブルシューティングが難しくなります。そこで、ここではトラブルシューティングを効率よく行うために利用可能なツールを紹介します。
■イベントログ
ADFS で発生したアクティビティーは Windows イベント ログに記録されます。ADFS関連のイベントログには、ADFS Admin ログ、ADFS Debug ログ、セキュリティ ログがあります。
■パフォーマンスモニター
パフォーマンスモニターでは、ADFS へのアクセス数などをリアルタイムで確認できます。
ADFS サーバーで行われたアクティビティーのうち、サービスの開始・停止やトラブルが発生した特定のアクティビティーについてはADFS Admin ログから、その内容を確認できます。
特に、ADFS の構成が問題で、Web アプリケーションによる ID 連携に失敗する場合、エラーを示す Web ページに 参照番号 (Activity ID) が表示されます。参照番号は、イベントログにも同様の ID が表示されるため、Web アプリケーションにアクセスしたときに発生したトラブルがどのイベントログによって表されているか確認できます。
一方、膨大なイベントログの中から特定の参照番号を持つログを探し出す場合には、フィルターを使用してください。イベントビューアーのフィルター機能では、XPath 形式のクエリーを記述することができるため、以下のようなクエリーを記述することで、特定の 参照番号を持つログを容易に探し出すことができるようになります。
<QueryList>
<Query Id=”0” Path=”AD FS/Admin”>
<Select Path=”AD FS/Admin”>
*[System[Correlation[@ActivityID=”{ActivityID}”]]]
</Select>
</Query>
</QueryList>
ADFS Debug ログは、ADFS に関わるアクティビティーを追跡するために利用できるログです。ADFS Admin ログとは異なり、トラブルの有無に関わりなく記録されるため、有効にすると膨大なログが記録されます。そのため、トラブルシューティングを行うなど、明確な目的があるときだけ利用します。
既定では、Debug ログは無効になっているため、利用する場合には次の方法で有効にします。
■ADFS Admin ログから [分析およびデバッグ ログの表示] を有効にする
Admin ログを右クリックし、[表示] – [分析およびデバッグ ログの表示] をクリックすると、項目が表示されます。
■ADFS debug ログから [ログの有効化] を実行する
Debug ログを右クリックし、[ログの有効化] をクリックするとトレースログが有効になります。Debugログは Admin ログに比べて多くのログを出力するため、トラブルシューティングなどの目的で記録したいときだけ有効にしてください。Debug ログを無効にするときは Debug ログを右クリックし、[ログの無効化] をクリックします。
Debug ログは最大ログサイズが 50MB に設定されており、また 50MB に達しても古いログを上書きしません。50MB 以上のログを記録できるようにするためには、debug ログのプロパティから最大ログサイズを変更します。
ADFS を利用した ID 連携でトラブルが発生した場合、トラブルの原因が ADFS にあれば、ほとんどのケースにおいて Admin ログにトラブルの内容が記録されます。ここでは、Admin ログに記録された内容を中心にトラブルシューティングを行う方法について解説します。
■イベント ID 364 が記録された。
イベント ID 364 はパッシブ プロファイルを利用してクレーム ベース認証を行おうとしたときに、発生したエラーを表します。このエラーが発生するときには、イベント ID 133 が続けて記録されますが、根本的な問題の原因はイベント ID 364 にあります。このエラーが発生した場合、以下のトラブルの可能性があります。
・ADFS サーバーに証明書がインストールされていない
・証明書として、コンピューター用証明書ではなく、ユーザー用証明書がインストールされている
・プライベートキーを含む証明書に対する ADFS サービス アカウントのアクセス許可がない
・証明書が失効していることを確認するための CRL にアクセスできない
・証明書の CN や SAN で示される名前が適切ではない
など
■イベント ID 342 が記録された。(1)
イベント ID 342 はトークンの検証に失敗したことを表します。トークンの検証に失敗する原因として、証明書の正当性の問題が考えられます。特にイベント ID 364 が一緒に生成される場合は証明書関連の問題であることが高いです。その場合には、証明書のプロパティを開き、証明書に記載されている名前 (CN など)に誤りがないか、証明書に記載されている CRL にアクセスできるか、などを確認してください。
■イベント ID 342 が記録された。(2)
イベント ID 342 はトークンの検証に失敗したことを表します。トークンの検証に失敗する原因として、Windows認証の失敗が考えられます。特に、ドメイン名\ユーザー名の形式でユーザー名を入力しなければならないのに、ドメイン名を入力していない、入力すべきドメイン名を間違えているなどを確認してください。
■イベント ID 278 が記録された。
イベント ID 278 は SAML アーティファクト プロファイルをサポートするサーバー構成でないときに記録されます。SAML アーティファクト プロファイルは ADFS サーバーのデータベースに SQL Server を利用していることが前提となるため、組み込みのデータベースで ADFS サーバーをインストールしている場合は必ず出力されます。SAML アーティファクト プロファイルを利用しない限り、問題にはなりませんので、無視してください。
■イベント ID 415 が記録された。
イベント ID 415 は Workplace Join 機能を利用して、ADFS サーバー経由でデバイス登録を行うために必要な構成ではないときに記録されます。ADFS サーバーでデバイス登録を行うためには ADFS サーバーに実装された証明書の SAN に enterpriseregistration～で始まる名前が含まれている必要がありますが、実際に実装されている証明書には含まれていないことが原因です。ただし、ADFS サーバー経由でデバイス登録を行う必要がない場合は問題にはなりませんので、無視してください。
■イベント ID 184 が記録された。
イベント ID 184 は証明書に関するエラーを表します。このエラーが発生するときの特徴は、ブラウザーからアクセスしたときに、ブラウザー画面にX.509 Certificateに関するエラー画面が表示されることと、イベント ID 364 が後続するエラーログとして記録される点です。このエラーが発生するときは、証明書の発行方法に問題があると考えられますので、証明書のインストールを再設定してください。また、認証局がADFS サーバーの信頼されたルート証明機関に登録されていることも同時に確認してください。
■イベント ID 102 が記録された。
イベント ID 102 はサービス起動に関するエラーを表します。原因は様々ですが、実装直後に考えられる原因としては ADFS サーバーに対応するファイアウォールルールが構成されていないことが原因でエンドポイントの有効化に失敗することが考えられます。ADFS サーバーは起動時にファイアウォールルールを構成するので、サービスを再起動してファイアウォールルールが作成されることを確認するとよいでしょう。
■イベント ID 133 が記録された。
イベント ID 133 はトークンにアクセスできないエラーを表します。ただし、実態は証明書に関連するトラブルがほとんどです。このエラーが発生するときには、イベント ID 102 と 364 が続けて記録されますが、根本的な問題の原因はイベント ID 133 にあります。このエラーが発生した場合、以下のトラブルの可能性があります。
・プライベートキーを含む証明書に対する ADFS サービス アカウントのアクセス許可がない
・証明書として、コンピューター用証明書ではなく、ユーザー用証明書がインストールされている
・プライベートキーを含む証明書に対する ADFS サービス アカウントのアクセス許可がない
・証明書として、pfx ファイルではなく、cer ファイルがインポートされた
■イベント ID 325 が記録された。
イベント ID 325 は RP の認可に失敗したことを表すログです。認可に関しては [発行承認規則] で定義されているので、この規則で許可されないクレームをトークン内に持っている場合に認可に失敗します。そのほか、発行承認規則で認可の基準となる情報をクレームで持っていない場合 (emailaddress属性をもとに認可を行うのに、トークンにはemailaddress属性が含まれていないなど) にも同様のエラーとなります。そのため、イベント ID 325 が記録された時には、後続のログにイベント ID 501 が記録されるので、イベント ID 501 のログから発行されたトークンの内容を確認し、発行承認規則で必要とする属性がトークンとして CP で発行されているか確認してください。
■イベント ID 315 が記録された。
イベント ID 315 はトークン証明証明書で使われる証明書チェーンの検証に失敗したことを表します。異なる組織間で ID 連携を展開する場合、RP の組織から CP の組織で展開する認証局へのアクセス (CDP と AIA) が必須になります。CP の組織の認証局がイントラネット内で展開され、外部からのアクセスが許可されていない場合には、Set-ADFSClaimsProviderTrust コマンドレットで、検証を行わないように設定してください。
■イベント ID 218/276/394 が記録された。
イベント ID 218/276/394/422 は Web アプリケーション プロキシが ADFS フェデレーション サーバーとの信頼関係が確認できなかったときに、Web アプリケーションプロキシのイベント ビューア―で記録されます。原因はどのようなイベント ID が記録されるかによって分類することができます。
イベント ID 218 が記録される場合、ADFS サーバーで入れ替えた証明書が Web アプリケーション プロキシに実装されていないことによるトラブルや、ADFS サーバーと Web アプリケーション プロキシの時刻がずれていることが考えられます。特に、時刻がずれている場合には Web アプリケーション プロキシを再構成することも検討してください。
イベント ID 276 が記録される場合、ADFS サーバーで Web アプリケーションプロキシとの信頼が失効したことを表します。この場合には Web アプリケーション プロキシの再構成が必須になります。なお、信頼が失効している場合、Web アプリケーション プロキシ側からはイベント ID 422 で確認できます。
イベント ID 422 が記録される場合、ADFS サーバーと Web アプリケーションプロキシの間で物理的に接続できないことが考えられます。このイベントが表示された場合にはまず物理的な接続が確立されていることや DNS や Hosts ファイルによる名前解決が正しく行えていることを確認してください。ADFS サーバーと Web アプリケーション プロキシの間での同期は 1 分おきに行われるため、最初のエラーログを参照することで、トラブルが始まった、おおよその日時を特定することも可能です。
対処方法としては Install-WebApplicationProxyコマンドレットを実行し、改めて ADFS サーバーと Web アプリケーションプロキシの間で信頼関係を設定してください。
また、以上のトラブルが ADFS 2.x サーバーで発生する場合、イベント ID 394 で確認できます。
■イベント ID 376 が記録された。
イベント ID 376 は 属性ストアとして、Active Directory 以外のものを利用している際、要求規則に記載されている情報に基づいて正しいデータを取得できない際に記録されます。このイベント ID では、属性ストアの SQL 接続文字列の問題、SQL 属性ストアに接続できない、データベースとクエリーの正当性の問題、のいずれかが原因です。イベント ID 376 では、ログ内に詳細なエラー関連情報が記録されるので、イベントログの内容を確認するのは、とても有効な手段です。
■イベント ID 377 が記録された。
イベント ID 377 は 要求規則に記述されたクレーム ルールの内容に問題があるときに記録されます。このイベント ID が記録された時には、クレームルールの内容を再確認してください。
■アプリケーションログ : イベント ID 1309 が記録された。
イベント ID 1309 はASP.NETの処理でエラーが発生したときに記録されるログです。この場合、ASP.NET の処理をつかさどるプロセスである w3wp.exe を強制終了してください。また、ログの詳細メッセージで「例外メッセージ ID3206 SignInResponseメッセージは、現在の Web アプリケーション内でのみリダイレクトされます」と表示される場合には、URL の最後に / (スラッシュ) が抜けていることが原因として考えられますので、クライアントコンピューターのブラウザー画面で、URL を確認してください。
ADFS の処理に関して、その他のイベント ID が記録され、エラーが発生する場合、マイクロソフト TechNet Web サイトを参照してください。
ADFS では、パフォーマンスモニターを利用してADFSによるトークン発行のアクティビティーをリアルタイムで確認できます。トークン発行に関わるパフォーマンスを確認する場合や、トラブルシューティングを行うときに役立てることが可能です。
ADFS では、実装するために行わなければならない項目が多いため、設定ミスによりトラブルが発生することがあります。こうしたトラブルが発生したときには、一般的なトラブルシューティングと同じく、トラブルの切り分けを行うことが重要になります。
SAML Tracer ツールは、Firefox のアドオンプログラムで、HTTP のヘッダーをリアルタイムで表示します。ヘッダーの内容を参照しながら通信中に送受信される SAML トークンの内容を確認することで、トラブルシューティングをしやすくし、トラブルの原因を見つけやすくする効果があります。
SAML Tracer ツールはインストールすると、メニューから [SAML Tracer] アイコンをクリックすることで、別ウィンドウが表示され、ウィンドウ内で Firefox 内での通信の様子を確認できます。
また、HTTP ヘッダー内に表示されるフェデレーション プロトコルの内容は [Parameters] タブをクリックして確認できます。
SAML Tracer で HTTP ヘッダーの追跡を行い、トラブルシューティングを行うためには、まず正常な通信で発生するヘッダーについて知る必要があります。ここでは、Office 365へブラウザーからシングルサインオンアクセスする際に発生する、HTTP ヘッダーについて確認します。
① GET /
Office 365 のサイトにアクセスします。このとき、アクセストークンを持たない状態でアクセスしているため、Azure AD サイトにリダイレクトされます。
② GET /login.srf?wa=wsignin1.0&…
Azure AD サイトにリダイレクトされたときに最初にアクセスするページが login.srf ページです。この後、ブラウザー画面では、サインインページが表示されます。
③ GET /common/userrealm/?user=…
サインインページで、ユーザー名を入力すると、そのサインインユーザーがシングルサインオン用ドメインを利用していることを確認し、ADFS サーバーへリダイレクトします。この URL はユーザー名を入力した後に最初にアクセスする URL です。
④ GET /adfs/ls/wia?lc=1041&username=…&wa=wsignin1.0&wtrealm=urn…
ADFS サーバーにアクセスすると、トークン発行のためのやり取りが始まります。この URL ではサインインページで入力したユーザー名 (username=部分) を ADFS サーバーに引き渡して、トークン発行処理を開始しています。なお、ユーザー名がブラウザーでキャッシュされているときなどは、この URL にアクセスしない場合があります。
⑤ POST /login.srf
ADFS サーバーでトークンが発行されると、Azure AD にトークンを持ってアクセスします。そのときに最初にアクセスするページが login.srf ページです。login.srf ページではトークンを Azure AD に引き渡すため、POST メソッドを使ってアクセスしています。
⑥ POST /landing.aspx?target=%2fdefault.aspx&wa=wsignin1.0
Azure AD での認可プロセスが完了すると、Office 365 にアクセスするためのトークンが発行されます。アクセストークンを持って Office365にアクセスする際に利用するページが landing.aspx ページです。
以上のページ以外にも実際の通信では様々なパケットが送受信されます。しかし、以上のおおまかな流れを理解しておくことで、トラブルが発生した際にどこまでの通信ができているかを把握し、次に行うべきアクションをご自身で判断できるようになります。
SAML Tracer アドオンから参照可能な HTTP ヘッダーには、？以降の部分に様々なパラメーターが記述されています。これらのパラメーターはフェデレーションプロトコルで定義されたものを記述しており、プロトコル種類によって記述すべき項目は異なります。ここでは、それぞれのプロトコルで使用する、主なパラメーターについて解説します。
■WS-Federation：wa=
wa= はアクションを表します。例えば、wsignin=1.0 と記述されている場合、これからサインインを行うことを表します。
■WS-Federation：wtrealm=
wtrealm= はレルムを表します。レルムは STS 信頼を結ぶ相手を表しますので、Office365にアクセスしている場合では、レルムとして Azure AD を表す情報 (urn:federation:MicrosoftOnline) が記述されています。
■WS-Federation：wctx=
wctx= は相手の STS に伝える URL などのセッション情報が入ります。
■WS-Federation：wct=
wct= は時刻の情報が入ります。
■SAML：SAMLRequest=
SAMLRequest= には SAML トークンの情報が Base64 形式でエンコードされた形で入ります。エンコードされたデータは SAML Debugger サイトなどを通じてデコードし、参照することができます。
■SAML：RelayState=
RelayState= には相手の STS に伝えるセッション情報が入ります。
■SAML：SigAlg=
SigAlg= には後続のデータで格納される署名データの署名アルゴリズムの情報が入ります。
■SAML：Signature=
Signature= には SAMLRequest のデジタル署名が入ります。
Office 2016 および Office 2013 では ADAL (Active Directory Authentication Library) に対応し、Office アプリケーションからでも多要素認証が利用できるようになりました。しかし、一部のバージョンのOffice 2013 では ADAL から利用する Windows 統合認証に WS-Trust 1.3の
/adfs/services/trust/13/windowstransport エンドポイントを利用します (通常は WS-Trust 2005 のエンドポイントを使用)。このエンドポイントは ADFS サーバー既定の設定で無効になっており、このことが原因で社内から ADAL アプリを利用して認証を行うとエラーになる場合があります。このようなケースでは、/adfs/services/trust/13/windowstransport エンドポイントを有効化し、ADAL アプリからも認証・認可ができるように構成してください。
iPhone や Android などのドメイン参加を行わないデバイスは、Office 365 へのサインインにユーザー名/パスワードを入力する認証を必要とします。しかし、既定では Web アプリケーションプロキシを経由しない認証にはフォーム認証ではなく、Windows 統合認証を利用するため、Windows 統合認証をサポートしないiPhone や Android などのデバイスが社内ネットワークから認証しようとするとエラーになります。
この場合、社内ネットワークからでもフォーム認証が利用できるよう、ADFS 管理ツールから [認証ポリシー] を右クリックし、[グローバル プライマリ認証の編集] をクリックして、[イントラネット] 欄の [フォーム認証] を有効にしてください。
ADFS サーバーでは、Active Directory の認証情報をベースにトークンを発行します。そのため、認証・認可に関わるサーバーが Kerberos の仕様に基づいて動作しなければなりません。中でも注意しなければならない点は Kerberos の時刻に関する仕様です。
Active Directory (Kerberos) では、既定で ドメインコントローラーとコンピューターの間で 5分以上の時刻のズレがあると、Kerberos 認証・認可を行うのにふさわしくない相手と判断し、処理が中止します。ドメイン参加しているコンピューターの場合には Active Directory の機能により、ドメインコントローラーと自動的に時刻を同期しますが、Web アプリケーション プロキシのように、DMZ にサーバーが配置されている場合にはドメイン参加していないことが多いため、時刻のズレが発生する可能性があります。
もし、内部ネットワークからのシングルサインオンは成功するにもかかわらず、外部ネットワークからのシングルサインオンに失敗する場合には、Web アプリケーションプロキシの時刻を確認してください。
ADFS サーバーでは、Active Directory で認証したユーザーの情報を LSA にキャッシュします。具体的には、ユーザーの名前と SID のマッピング情報をキャッシュし、SID に対応する名前を毎回 Active Directory を参照しなくてもよいようにしています。
しかし、Active Directory でユーザーの名前 (sAMAccountName または UPN) が変更しても、キャッシュにはその変更がしばらくの間、反映されません。そのため、名前を変更しても変更前の名前がクレームにセットされてしまいます。このような問題を解決するには、以下の方法で対処します。
■ADFS サービスを再起動する
ADFS サービスを再起動することによって、キャッシュはすべて削除され、ADFS サーバーは新しくユーザーの名前を取得します。
■キャッシュサイズを変更する
キャッシュはレジストリで定義されています。レジストリの設定を直接編集することで、キャッシュしないように設定することが可能です。
レジストリ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA の
LsaLookupCacheMaxSize (DWORD値) の値を 0 に設定することで、キャッシュされないように定義できます。
編集後記
ついに341ページあったテキストをすべて公開完了しました。
「ADFSを知ってもらいたい」という一心で採算とか度外視でテキストの開発には多くの時間を費やしてきました。
2012年からこのトレーニングを始めて現在はAzure ADのトレーニングに引き継がれるまで、
8年にわたってシングルサインオンの話をし続けたわけですが、
結果的にこういった主張をあちこちで見かけるようになったことは
(自分がSAMLを流行らせたわけでも全くないけど)本当にうれしく思います。
■なぜWebサービスの選定においてSAML/SSOが重要なのか
https://oka-lab.jp/importance-of-saml-sso-in-web-services
ADFSのテキスト自体は減価償却も終わったし、今でも誰かの役に立つならと思い、公開することにしました。このテキスト公開は私にとってADFSからの卒業みたいなもので、卒業していったい何わかるというのかわからないけど、知っていることは全部書いときました。だからADFSの質問はもう私にしないでくださいw
おわり
