Windows Server 2016 AD FS 証明書認証を代替ホスト名でバインドする

皆さんこんにちは、Miyaです。

先日、Windows Server 2016のAD FS3.0で気になる記事を見かけました。
Title:AD FS の証明書認証用の代替ホスト名バインドのサポートします。

要約すると、AD FSの証明書認証に従来は単一ホスト名に対しての通信のみサポートしてましたが、代替ホスト名のバインドをサポートしますよ。って話だと私は理解しています。

上述のサポート内容に一体何のメリットがあるのかというと、証明書認証に49443/TCPを開放する必要がなくなる、が在ります。

AD FSのポート要件として、443/TCPの他に証明書認証をする場合は同一ホスト名に対して49443/TCPも開放しなさいよ。でした。
Title:AD FS の要件 – ネットワークの要件
クライアントは証明書情報をAD FS、WAPに投げる際に49443/TCPを使用していました。

そのため、DMZに配置しているWAPに対しても、ダイナミックポートである49443/TCPを開放する必要があるため、インフラとしてはあまり好ましくありませんでした。
また、動的ポートですので監視システムなどの他システムと競合する恐れもあります。

そこで、SANsの証明書をAD FSにバインドすることで、証明書認証にも443/TCPでアクセスさせる構成を実現してみました。

スポンサーリンク:

SANsのバインド方法

大体の手順は冒頭で紹介したリンク先の流れで構いません。

フェデレーションサービス名とcertauth.<フェデレーションサービス名>のサブジェクト名を持つSANs証明書をAD FSとWAPにインポートしておきましょう。

代替アクセス名

AD FSで下記コマンドを実行しましょう。
MemberオプションはバインドするAD FSサーバー名になります。ファームを構成している場合は、Member指定してあげると1台のAD FSサーバーからリモートでバインド設定可能です。

⇒拇印が分からない場合は、Get-ChildItem Cert:\LocalMachine\My | flコマンドで拇印をコピっておきましょう。

Set-AdfsAlternateTlsClientBinding

以上でバインドは完了です。すごく簡単ですね。
内部・外部DNSにはcertauth.***.*****.***のCNAMEレコードを書いておきましょう。

試しにGet-ADFSPropertiesコマンドのTlsClientPortを確認してみると、443に変更されているのが確認できます。

Set-AdfsAlternateTlsClientBinding

証明書認証対象のクライアントから接続してみます。
一発目のフォーム認証画面は従来のフェデレーション名であるsts.***.***に接続しています。
Set-AdfsAlternateTlsClientBinding
続いて、証明書認証によるポップアップが表示されました。ここで証明書を選択するとAD FS、WAPに対して49443/TCPで通信するのですが、先の手順でバインドしたホスト名に対して443/TCPで通信します。
Set-AdfsAlternateTlsClientBinding

正しい証明書を選択するとURLが一瞬で変更されるため、あえて間違えてみました。

Set-AdfsAlternateTlsClientBinding

URL部分をよく見てみると、certauth.sts.****.***へのアクセスになっていることが分かります。

F/Wのログを見ると、49443のアクセスログは見られませんでした。SANsを購入する必要があるのが面倒ですが、443/TCPだけで証明書認証が構成出来るのは有り難いですね。

海外のコミュニティを見ていると、「error ‘The specified SSL certificate with thumbprint ‘‘ does not meet the requirements for configuring alternate Tls Client binding.」、要件を満たしていませんよ~、とはじかれるケースがよくあるみたいです。
Title:ADFS configure Set-ADFSAlternateTlsClientBinding

詳しい要件が記述されているページを見つけることは出来ませんでしたが、フェデレーションサービス名と”certauth”+フェデレーションサービス名のサブジェクト名を持ったSANsもしくはワイルドカード(?)を使用すればスーッといけるような気がします。

外部公開しているサービスには49443などの動的ポートを開放するのは好ましくないので、証明書認証を利用している環境ではなるべく本構成を取り入れてみはいかがでしょうか。

それでは、良いOffice365ライフをっ♪

スポンサーリンク