ADFS自己署名証明書の入替時の注意点 – WIFアプリケーション編

みなさん、こんにちは。国井です。

先日、ADFSのトレーニングにご参加いただいた方とお話をさせていただく中で、
Office 365のためにADFSを利用する方と、
それ以外のサービスでADFSを利用する方では、
ADFSに対する意識が全く異なる
という意見をいただきました。

たしかに、Office 365のためにADFSを利用する場合には、
Powershellのコマンドレットをいくつか実行すれば、
必要な設定はすべて自動的に行ってくれるので、
それ以上のことを知らなくても、何とかなってしまいますが、
Google Appsと組み合わせたい、Salesforceと組み合わせたい、
などとなると、そうはいきません。

そのため、前述のトレーニングでも、様々なサービスと組み合わせて利用できるよう、ADFSの仕組みから細かく解説をさせていただいているのですが、それでもすべてをお伝えできないのがトラブルシューティングです。

トラブル事例として起こりうるものは実際に経験してみないと
なかなかお伝えできないですし、教科書的なものだけを教わっても、
実際に役に立たなければ意味がありません。

ということで、前置きが長くなりましたが、
今日はトラブルシューティング事例をひとつご紹介します。

■ ■ ■

ADFSでは様々な種類の証明書を利用しますが、
中でもトークン署名証明書は1年の有効期限が設定されており、
1年経つと証明書自体が新しいものに置き換わってしまい、
通信できなくなるという事例があります。
そのため、トークン署名証明書等で使われる自己署名証明書は
デフォルトの証明書をそのまま使うのではなく、
最初から長い期間を設定しておく運用を実装されるケースが多いです。
(このあたりの詳細はMVP渡辺さんのADFSの自己証明書の期間延長を参考にされるとよいでしょう)
そして、実際に証明書の有効期間を10年に設定し、証明書を入れ替えたものが
以下の画面になります。

image

Office 365での運用ですと、フェデレーションメタデータを更新すれば
完了ですが、ASP.NET + WIFで作られたWebアプリケーションだと、
以下のようなエラーが発生します。(ID4175 IssuerNameRegistryというエラーです)

image

なぜ、このようなエラーになるかというと、
WIFのWebアプリケーションの場合、Web.Configファイルの中に
トークン署名証明書のThumbPrintを決め打ちで入れているからなのです。

image

そのため、Web.Configファイルをメモ帳などのエディターで開き、

image

あらかじめ、Get-AdfsCertificateコマンドレットで調べたトークン署名証明書のThumbPrintに置き換えれば、出来上がり。

image

これで、ADFSによるトークン発行とWebアプリケーションへのアクセスが正常に動作するようになります。