みなさん、こんにちは。国井です。
先日、ADFSのトレーニングにご参加いただいた方とお話をさせていただく中で、
「Office 365のためにADFSを利用する方と、
それ以外のサービスでADFSを利用する方では、
ADFSに対する意識が全く異なる」
という意見をいただきました。
たしかに、Office 365のためにADFSを利用する場合には、
Powershellのコマンドレットをいくつか実行すれば、
必要な設定はすべて自動的に行ってくれるので、
それ以上のことを知らなくても、何とかなってしまいますが、
Google Appsと組み合わせたい、Salesforceと組み合わせたい、
などとなると、そうはいきません。
そのため、前述のトレーニングでも、様々なサービスと組み合わせて利用できるよう、ADFSの仕組みから細かく解説をさせていただいているのですが、それでもすべてをお伝えできないのがトラブルシューティングです。
トラブル事例として起こりうるものは実際に経験してみないと
なかなかお伝えできないですし、教科書的なものだけを教わっても、
実際に役に立たなければ意味がありません。
ということで、前置きが長くなりましたが、
今日はトラブルシューティング事例をひとつご紹介します。
■ ■ ■
ADFSでは様々な種類の証明書を利用しますが、
中でもトークン署名証明書は1年の有効期限が設定されており、
１年経つと証明書自体が新しいものに置き換わってしまい、
通信できなくなるという事例があります。
そのため、トークン署名証明書等で使われる自己署名証明書は
デフォルトの証明書をそのまま使うのではなく、
最初から長い期間を設定しておく運用を実装されるケースが多いです。
(このあたりの詳細はMVP渡辺さんのADFSの自己証明書の期間延長を参考にされるとよいでしょう)
そして、実際に証明書の有効期間を10年に設定し、証明書を入れ替えたものが
以下の画面になります。
Office 365での運用ですと、フェデレーションメタデータを更新すれば
完了ですが、ASP.NET + WIFで作られたWebアプリケーションだと、
以下のようなエラーが発生します。(ID4175 IssuerNameRegistryというエラーです)
なぜ、このようなエラーになるかというと、
WIFのWebアプリケーションの場合、Web.Configファイルの中に
トークン署名証明書のThumbPrintを決め打ちで入れているからなのです。
そのため、Web.Configファイルをメモ帳などのエディターで開き、
あらかじめ、Get-AdfsCertificateコマンドレットで調べたトークン署名証明書のThumbPrintに置き換えれば、出来上がり。
これで、ADFSによるトークン発行とWebアプリケーションへのアクセスが正常に動作するようになります。
