AWS Magaged Microsoft AD環境に作ったADFS WAPサーバーを冗長化する

AWS Magaged Microsoft AD環境に作ったADFS WAPサーバーを冗長化する

Clock Icon2019.10.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。
前回前々回はAWS Magaged Microsoft AD(以後Micorosft AD)環境のADFSサーバーを冗長化しましたが、本記事は最後にADFS WAPサーバーを冗長化してみます。

検証環境

検証環境は下図の通りで、前回の構成にADFS WAPサーバー1台と公開ELBを追加しています。

通信要件は前回と同様にELBのヘルスチェック(HTTPプローブ)のためにTCP 80(HTTP)の通信を許可しておく必要があります。
ADFS WAPサーバー間での通信要件も見つけることが出来なかったのでこれも前回同様全ての通信を許可しておけば問題ないでしょう。

その他詳細は以下。

ADFS WAPサーバー

項目 設定値 備考
インスタンスタイプ t3.medium
OS 日本語版 Windows Server 2016 AMI : ami-0b26f62143241dc18
コンピューター名 WAP02
ドメイン corp.shibata.tech に参加 ADFS WAPはドメイン参加必須ではない
Windows Firewall 無効に変更 通信制御はセキュリティグループで実施

ADFS WAPサーバーは前々回同様の構成で、必須ではないのですがドメインに参加しているところも合わせてあります。

2台目のADFS WAPサーバーの追加

ADFS WAPの追加手順は2台目以降でも1台目と変わりません。
機能を追加してWAPとして構成してやるだけです。

前準備1 : HOSTSファイルの設定

ADFS WAPサーバーのHOSTSファイルに設定しているsts.shibata.techの向き先をELBのIPアドレスに変更してやります。

<同一AZにあるELBのIP> sts.shibata.tech

前準備2 : 証明書のインポート

次に前々回同様にサーバー証明書をインポートしておきます。

# エクスポートした証明書が C:\temp\adfs.pfx にある前提
$params = @{
    FilePath = 'C:\temp\adfs.pfx'
    CertStoreLocation = 'cert:\localMachine\my'
    Password = (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force)
}
Import-PfxCertificate @params

また、この証明書を信頼済み扱いするために「信頼されたルート証明機関」にもインポートしておいてください。

1. 2台目のADFS WAPサーバーの構築 (機能の追加)

はじめにInstall-WindowsFeatureコマンドレットを使い「Web アプリケーション プロキシ」の機能を追加します。

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

2. 2台目のADFS WAPサーバーの構築 (WAPの構成)

続けてWebApplicationProxyモジュールInstall-WebApplicationProxyコマンドレットでWAPを構成します。

# ローカル管理者権限を持つユーザーの認証情報
$localAdminCred = Get-Credential 'corp\admin'
$params = @{
    FederationServiceName = 'sts.shibata.tech'
    CertificateThumbprint = (Get-ChildItem Cert:\LocalMachine\My\ | Where-Object { $_.Subject -eq 'CN=sts.shibata.tech' }).Thumbprint
    FederationServiceTrustCredential = $localAdminCred
}
Install-WebApplicationProxy @params

インストールに問題なければ下図の様になります。

以上で完了です。

ELB (Classic Load Balancer) の追加

続けて公開ELBを追加します。
前回同様こちらもClassic Load Balancer(CLB)で構築します。

パブリックなサーバー証明書があればELBをApplication Load Balancer(ALB)で構築しHTTPSで受けつつADFS WAPもHTTPSを使うといった通信ができそうな気もするのですが、検証できないので本記事ではCLBで構築していきます。
(ちなみにACMから別途sts.shibata.techのサーバー証明書を取得してALBに配置して試した限りでは上手くいきませんでした...)

前回同様CLBをマネジメントコンソールから作る想定で紹介します。
(今回は力尽きてNLBでの検証はしていません...たぶん動作すると思います)

まずロードバランサーの基本設定としてプロトコルをTCP 443およびTCP 49443にしてそのままインスタンスに分散させます。

  • ロードバランサーのプロトコル → インスタンスのプロトコル
  • TCP 443 → TCP 443
  • TCP 49443 → TCP 49443

サブネットはパブリックサブネットを選択します。

セキュリティグループは外部からTCP 443/TCP 49443を受信可能なものを選択します。

セキュリティ設定はスキップして、

ヘルスチェックはADFSサーバーと同様にHTTPで/adfs/probeに対して行います。

  • pingプロトコル/ポート : HTTP 80
  • pingパス : /adfs/probe

インスタンスにADFS WAPサーバー2台を選択し、

あとはよしなに作成すればOKです。

これでELBの設定は完了です。

最後に

これでADFS WAP、ADFSサーバー両方を冗長構成にできました。

必要なこととはいえ率直に言って非常に手間がかかります。
また、ADFSでは証明書をロードバランサーで終端させる事ができないためCLBを使わざるを得ない点やサーバーが増えるほど証明書更新の運用コストが増す点は導入に際してそれなりに"覚悟"が必要になると思います。
3回に渡ってブログを書いておきながらこんな事を言ってしまうのもアレなのですが、実際に構築し検証した立場での率直な気持ちでもあります。

2019年現在、以下の様にADFSの移行に関する記事は探せばそれなり出てきます。

ADFSの導入に際しては「本当にADFSでなければならないのか」をしっかり考え判断するのが良いでしょう。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.