LoginSignup
4
3

More than 3 years have passed since last update.

@Shinya-Yamaguchi(Shinya Yamaguchi)inMicrosoft

インターネットから WAP 経由でフェデレーション サービスに接続した時にエラーでアクセスできなかった場合の確認ポイント

Posted at

はじめに

イントラネット環境から AD FS のフェデレーション サービスにアクセスした時には問題なく AD FS 経由で認証ができるのにインターネット環境から WAP 経由でアクセスした時に下記画面ショットのように「申し訳ございません。このページに到達できません」と表示され AD FS のフェデレーション認証に到達できない場合の話になります。

image.png

ほとんどの人はこのエラーではまるような事はないかと思いますが、備忘録も兼ねて記事として残します。
結論から言いますと、WAP が正常に構成できていないために起きている事象です。
私がハマったポイントは下記 2 点です。

  1. AD FS のファームレベルと WAP の OS バージョンが一致しておらず、WAP が構成できていなかった。
  2. 443 ポートが空いていなかった。 (根本原因はこっちだった)

書いてると悲しくなるくらいなんてことはないしょーもない原因だったのですが、意外と盲点なのかもしれないと思い自戒の意味も込めて経緯を記します。

参考記事一覧

国井さんの Blog
・ADFSトレーニングテキスト全文公開チャレンジ(6) – ADFSのインストール(後編)
・ADFSトレーニングテキスト全文公開チャレンジ(9) – Office365連携環境の構築ステップ

Microsoft 公開情報
・ユーザーが Office 365、Intune、または Azure にサインインしたときの AD FS エンドポイント接続の問題のトラブルシューティング方法
・Azure での Active Directory フェデレーション サービスのデプロイ
・Office 365、Azure、または Intune にサインインすると、AD FS から証明書の警告が表示される
・Azure AD Connect を使用した Active Directory フェデレーション サービスの管理とカスタマイズ
・WID データベースを使用した、Windows Server 2016 での AD FS へのアップグレード
・ハイブリッド ID で必要なポートとプロトコル

確認ポイント

まず、社内だけではなく、社外からも AD FS を利用したフェデレーション認証を実現するために WAP (Web Application Proxy) を構築しますが、構築自体は特に問題なく行えるかと思います。

ポイントとしては、グローバル IP アドレスを持った FQDN をインターネット環境でも利用するフェデレーション サービス名と一致させる必要があります。

社内からアクセスする際には社内の DNS サーバーを参照することで名前解決ができますが、社外からアクセスした時には当然社内の DNS サーバーは参照しに行けないので、
FQDN の名前解決をするためには外部 DNS サーバーを参照しに行くか、WAP サーバー内の hosts ファイルに AD FS サーバーの FQDN とローカル IP を記載することで、名前解決をさせる必要があります。

この辺りの解説は参考記事一覧にも記載している国井さんの ADFSトレーニングテキスト全文公開チャレンジ(6) – ADFSのインストール(後編) が図解付きで分かりやすく解説してくださっていますので、是非参考にしてください。

外部 DNS サーバーの A レコードに記載するのは WAP サーバーのグローバル IP アドレスとフェデレーション サービス名になりますので気を付けてください。
(AD FS サーバーのグローバル IP ではない、という意味です)

上記を踏まえてまず試したのが ユーザーが Office 365、Intune、または Azure にサインインしたときの AD FS エンドポイント接続の問題のトラブルシューティング方法 に記載されているリモート接続アナライザーです。

「https://www.testconnectivity.microsoft.com/?testid=singlesignon」 に接続すると下記画面に遷移するので、「シングル サインオンを使用して問題を特定する」をクリックします。
image.png

以下のようにテストを行いたいフェデレーション ドメインを持つ UPN などを入力し、この画面には載ってませんが一番下の「テストの実行」をクリックします。
image.png

すると接続テストが失敗した旨のメッセージが出ました。
image.png

SSL 証明書の検証に失敗、443 ポートへの接続がうまく行っていないようです。
あとから思えばこの時点でポートが空いていないことを調べればよかったのですが、WAP の構成を見直してみることにしました。
image.png

WAP の構成確認を含むフェデレーションの管理、構成は Azure AD Connect サーバーを導入している環境であれば AADC のウィザードから簡単にできるので、
AADC のウィザードで構成を確認します。
ウィザードより「フェデレーションの管理」→「サーバーを管理する」の順にクリックします。
image.png

サーバーをの管理タスクの画面で「Web アプリケーション プロキシ サーバーのデプロイ」をクリックします。
image.png

そのまま次へをクリックします。
image.png

AD FS サーバー上の管理者資格情報を入力して「次へ」をクリックします。
image.png

既に WAP サーバーに SSL 証明書はインポート済みなので対象の SSL 証明書に設定しているパスワードを入力します。
image.png

「パスワードの入力」をクリックすると入力画面が表示されるので、パスワードを入力し「OK」をクリックします。
image.png

サブジェクト名、フェデレーション サービス名が表示されるので「次へ」をクリックします。
image.png

構築済みの WAP サーバーを検索、指定します。
image.png

「追加」をクリックしましたが、この WAP サーバーは構築済みの AD FS ファームではサポートされていないと怒られて追加ができませんでした。
image.png

AD FS サーバー上で 「Get-AdfsFarmInformation」コマンドレットを実行するとファーム レベルが4であることが確認できます。
image.png

WID データベースを使用した、Windows Server 2016 での AD FS へのアップグレード に記載されていますが、ファームレベル 4 は Windows Server 2019 で構成した場合のファーム レベルになります。
image.png

WAP サーバーを見ると Windows Server 2016 でした。
image.png

AD FS のファーム レベルに合わせないと WAP サーバーを追加できないという事なので、Azure VM を Windows Server 2019 OS でデプロイし直して再構築しました。
image.png

再び AADC サーバーのウィザードから新規に構築した Windows Server 2019 OS の WAP サーバーを選択します。
image.png

今度は追加ができました。そのまま「次へ」をクリックします。
image.png

確認画面が表示されるので「構成」をクリックします。
image.png

構成後にイントラネット、インターネットそれぞれの接続確認ができるので、チェックボックスにチェックを入れて「確認」をクリックします。
image.png

それぞれ検証の確認ができました。(イントラネットは IPv6 を無効にしているので警告が出てますが意図的に無効化していますので無視します)
インターネット側も検証に成功していますが、40 から始まるグローバル IP は Windows 2016 Server のグローバル IP なので修正する必要があります。
(このままだと Windows 2016 Server の WAP を参照しに行ってしまうためです)
image.png

新しく構築した Windows 2019 Server のグローバル IP は 20 から始まる IP なのでこちらの IP に修正します。
image.png

外部 DNS サーバーの A レコードを以下の要に修正、反映させます。
image.png

再度 AADC ウィザードから検証するとインターネットのフェデレーション サービス名が 20 から始まるグローバル IP として解決されていることが確認できました。
image.png

これで再度リモート接続アナライザーからテストしてみましたが同じエラーとなり、当然ですが WAP 経由で「申し訳ございません。このページに到達できません」の表示のままでした。
次に疑ったのが 443 ポートが WAP サーバーで空いているかどうか、という問題でした。

結果としては Azure VM を素の状態でデプロイすると 443 ポートは空いていませんでした。

ポートが空いているかどうかはコマンドプロンプトで netstat -ano | find "443" と実行すると確認できます。
netstat

また、Windows Server 側で 443 ポートを開けるためには、Windows Defender ファイアウオールで設定します。
設定すると言っても既定のポリシーを有効化するだけなので非常にシンプルです。

「Windows 管理ツール」→「セキュリティが強化された Windows Defender ファイアウオール」の順にクリックし、
「受信の規則」をクリックします。
image.png

受信の規則の一覧から「AD FS HTTPS サービス (TCP 受信)」を右クリックし「規則の有効化」をクリックし、この規則を有効化します。
この規則が 443 ポートでセッションを待ち受けるために必要な規則だった、という訳です。
image.png

この規則を有効化した後に、インターネット経由でフェデレーション関係にある Office 365 ポータルにアクセスしてみます。
以下は有効化する前です。

最初に載せたメッセージが出ますね。
image.png

「AD FS HTTPS サービス (TCP 受信)」を有効化した後に画面を更新します。
image.png

パスワードを入力してサインインします。
image.png

無事 test003 ユーザーで Office 365 ポータルにフェデレーション認証でサインインできました。
image.png

image.png

ちなみにリモート接続アナライザーでも確認してみると一部証明書の警告が出ますが、AD FS サーバーからセキュリティ トークンを正常に取得できたことが確認できました。
image.png

おわりに

今回は実際に構築過程でハマってしまった WAP サーバー経由でアクセスした際にフェデレーション認証ができない事象で対処した内容を記載しました。
終わってみればなんてことはない、単純に 443 (https) ポートが空いていなかっただけという事象でしたが、
皆さんがつまらないポイントで時間を浪費しないよう、この記事が少しでも参考になれば幸いです。

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
3