はじめに
久しぶりに、 AD FS 、 WAP 環境を起動したときに、 AD FS へのリダイレクト処理後に下記画面のようにリダイレクト処理に失敗した時の対処法を記載します。
考えられる内容
考えられる原因としては、以下のとおり。
1. AD FS サービスが落ちている
2. WAP サービスが落ちている
3. 上記両方のサービスが落ちている
4. WAP と AD FS 間の信頼関係を証明するための証明書認証に失敗している
5. DNS の名前解決に失敗している
切り分けてみる
まずは、4の事象を疑いました。
AD FS サーバーのイベントログに、下記のとおり ID 276 エラーが頻発していたからです。
ID 276 は、 WAP サーバーが送信したクライアント証明書認証に失敗したため出力されるイベントになります。
WAP サーバーの「C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SystemCertificates\My\Certificates」フォルダ配下には、以下のとおり 20 日間の有効期限の証明書が作成され、 有効期限が切れる 7 日前に、新しく 20 日間の有効期限を持った証明書が作成されます。
この動作の繰り返しを行うわけですが、まず、証明書の更新は、 AD FS サーバー、 WAP サーバーが起動していないと成功しません。
例えば、長期間サーバーが停止したままの状態、もしくはネットワークが不通の状態が続くと、証明書の更新が行えなくなり、信頼関係が構成できなくなります。その場合はWAP の再構成が必要になります。
下記画面ショットは、 AD FS サーバーの「証明書」→「AdfsTrustedDevices」フォルダにある、WAP - AD FS 間の証明書ですが、有効期限を見ると 、 2019/04/16 となっている(本blog 投稿日時は 2019/03/31) ので、有効期限は切れていないように見えます。
※結果的には、有効期限は切れていないので、証明書の問題ではなく別の問題でしたが、せっかくなので、 WAP の再構成をやってみます。
WAP の再構成手順
まずは、コマンドプロンプトにて「regedit」と実行し、レジストリ エディターを開きます。
次に、[HKEY_LOCAL_MACHINE\Software\Microsoft\ADFS] を選択します。
次に、[ProxyConfigurationStatus] をダブル クリックし、値を「2」から「1」に変更します。
※ここで「1」に変更しないと「Web アプリケーション プロキシ構成ウィザードの実行」でWAPサーバーの構成(編集)ができないので、変更する必要があります。
WAP サーバー上でスタート画面などから [リモート アクセス管理] コンソールを開きます。
次に、画面中央から [Web アプリケーション プロキシ構成ウィザードの実行] をクリックします。
AD FS サーバーのフェデレーション サービス名、資格情報を入力します。
AD FS プロキシに使用する証明書を選択します。
下記例のとおり、有効期限が切れている証明書を選択すると、警告メッセージが表示されます。
有効期限が切れていない、正しい証明書を選択し、「次へ」をクリックします。
「構成」ボタンをクリックします。
また、下記画面ショットにあるとおり、この作業は PowerShell コマンドレットで CLI で構成することも可能です。
正常に WAP の再構成に成功すると下記画面が表示されるので、「閉じる」をクリックします。
下記画面ショットとおり、 AD FS プロキシの証明書が「2セット」インポートされていることが分かります。
WAP の再構成完了後に再び Office 365 に AD FS 経由でアクセスしようとしましたが、事象が改善されませんでした。
再び AD FS イベントログを見てみると、エンド ポイントが開くことができない、と言っています。
しかしながら、対象のエンドポイントを見てみると、有効になっていました。
これは困った…
ここで、 AD FS も再インストールしてみたのですが、事象がかわらず…。
もしかして…として行き着いたのが、 DNS の名前解決。
これは Azure の罠というか「あるある」なのですが、 Azure 上の Virtual Machine を何も考えず、再起動すると、再起動するたびに、「グローバル IP」が変わります。下記割り当ての項目を「静的」にしないと、グローバル IP が固定されないのです。
そこで気づきました。
DNS レジストリに登録している、「 AD FSフェデレーション名」が再起動前のグローバル IP のままになっていたのです。下記が変更前の AD FS フェデレーション名の A レコード。
これを 13.78.12.1 に変えます。
DNS が浸透するまで待ちます…。
浸透されました。
さて、もう 1 度 Office 365 にアクセスしてみます。
お馴染みのリダイレクト後のフォーム認証画面が表示されましたが、「不明なエラーが発生しました」と表示されてしまいました。またしても立ちはだかる壁。
ここでまたしばらく悩みましたが、 「AD FS の管理」を見て気づきました。
ここに書いてあるじゃないですか…
そう、 AD FS はサービスを追加しただけでは、ダメで、信頼できる証明書利用者、つまり RP(Relying Party)との信頼関係を構成する必要があります。
AD FS サーバーで下記作業を行います。
まず、モジュールのダウンロードをします。
https://www.microsoft.com/ja-jp/download/details.aspx?id=41950
次に 、 PowerShell を管理者で立ち上げて、 install-Module MSOnline でモジュールインストールします。
Connect-MolService コマンドレットを実行すると、 Azure AD の全体管理者の資格情報を入力する画面がポップアップ表示されます。
資格情報を入力後に、 Azure AD にカスタム ドメインとして登録しているドメインを Federated ドメインとして構成します。
すると、「AD FS 管理」にて、下記のとおり、SSO 構成が可能なメッセージに変わりました。
証明書利用者信頼の項目に Office 365 との信頼関係が構成されたことが追加されました。
キター！！
と思ったのも束の間、今度は、AD FS 認証後に、 Office 365 のトップ画面に戻る、まだ AD FS で認証する、 Office 365 のトップ画面に戻る。というループに陥ります…。
またまた悩む
これはなんだろうと、思いましたが、フェデレーション先の Azure AD のテナントの Office 365 の無償期限が切れて Office 365 が使えないことに気づきました。
で、ここまでまたはまりましたが、カスタム ドメインは Azure AD 上で削除できるのですが、フェデレーション関係になっていると Azure ポータルからは削除できないのです。
当然といえば、当然ですよね。
信頼関係が構成されたドメイン間でその当該のドメインを削除するなんてことはできませんから。
そこでどうするかというと、「Federated」関係から「Managed」関係に手動で変更する必要があります。
PowerShell のコマンドレットで下記のように実行します。
Set-MsolDomainAuthentication -Authentication Managed -DomainName shyamag006.com
Get-MsolDomain コマンドレットで確認すると、「Managed」に変更されていますね。
これで shyamag007.onmicrosoft.com テナントのカスタム ドメインが削除できないか試してみます。
なんか削除できそうですね！
削除が開始されました！
shyamag007.onmicrosoft.com テナントで削除が完了したのを確認後に、あたらしいテナント(shyamag011.onmicrosoft.com )でカスタムドメイン shyamag006.com が構成できるようになりました。
再び、Connect-MolService コマンドレットを実行すると、 Azure AD の全体管理者の資格情報を入力する画面がポップアップ表示されます。今度は新しいテナントの資格情報を入力します。
新しいテナントにて、 shyamag006.com を Fedarated ドメインに変更、および変更を確認します。
再度 Office 365 にサインインを試みます。
AD FS のフォーム認証画面で資格情報を入力して…。
無事 Office 365 に SSO 成功！
※まだ ユーザーに Office 365 ライセンスを割り当てていないため、下記のような画面になります。
Office 365 のライセンスを割り当てて、インストールした後の画面です。
まとめ
今回は、WAP - AD FS 間の信頼関係の再構成を紹介するつもりでしたが、思わぬ罠にはまりつづけてしまいました。
しかしながら、 DNS の名前解決の問題、カスタム ドメインが削除できない問題などは、よくある事象だと思いますので、少しでもこの記事が同じ事象にはまってしまった人の助けになれば幸いです。