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

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

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

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

参考記事一覧

国井さんの Blog
・ADFSトレーニングテキスト全文公開チャレンジ(6) – ADFSのインストール(後編)
・[ADFSトレーニングテキスト全文公開チャレンジ(9) – Office365連携環境の構築ステップ](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」に接続すると下記画面に遷移するので、「シングルサインオンを使用して問題を特定する」をクリックします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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