Directory ServiceのMicrosoft ADとオンプレミスのADで信頼関係を組んでみた

Directory ServiceのMicrosoft ADとオンプレミスのADで双方向の信頼関係を作成してみた。
2018.07.10

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

おはようございます、加藤です。東京暑すぎませんか?最高気温34度って理解が追いつかないです、体が溶けてしまいそう...

今回はWorkSpacesを使う際に役立つかなと考えDirectory ServiceのADとオンプレミスのADで信頼関係を構築してみました。

やってみた

検証の為にオンプレミスのサーバーを用意するのは手間なので、EC2で代用します。

本ブログでは、EC2のADをオンプレミスAD・オンプレミス側、Directory ServiceのADをマネージドAD、AWS側と呼称します。

検証用環境の作成

まずは、図のような構成を作成します。NAT Gatewayは冗長化していますが検証用なのでSingle-AZにしてもOKです。

今回ADは同一のVPC内に作成しました。また、EC2 on ADする場合はプライベートサブネットに置く事が多いと思いますが、ここでは踏み台を省略し、パブリックサブネットに配置しました。

  • VPC
    • Internet Gateway
    • Public Subnet × 2
    • Private Subnet × 2
    • NAT Gateway × 2
  • EC2
    • EC2
      • Active Directory
  • Directory Service
    • Microsoft AD

オンプレミス側のインバウンド許可

AWS→オンプレミス方向の通信を許可します。

今回の検証環境の場合は、オンプレミスADのセキュリティグループとWindows Firewallを設定します。

プロトコル ポート番号 送信元 備考
TCP/UDP 53 マネージドADが存在するサブネットのCIDR DNS
TCP/UDP 88 マネージドADが存在するサブネットのCIDR Kerberos認証
TCP/UDP 389  マネージドADが存在するサブネットのCIDR  LDAP
TCP 445 マネージドADが存在するサブネットのCIDR SMB

Directory ServiceはMulti-AZになっています。複数のサブネットのCIDRから許可することを忘れないようにしてください。

マネージド側のアウトバウンド許可

Directory ServiceのMicrosoft ADはデフォルトではアウトバウンド通信が自分のセキュリティグループにしか許可されていません。オンプレミス側に通信するためにアウトバウンドを許可します。

Directory Serviceの管理画面からID(d-xxxxxxxxxx)を確認して、一致するセキュリティグループを見つけます。

プロトコル ポート番号 送信元 備考
ALL ALL オンプレミス側ADのIPアドレス

マネージド側のインバウンド許可

オンプレミス→AWS方向の通信を許可します。

ものすごい数がありますが、一番上のICMP以外はデフォルトで0.0.0.0/0に対して開放されています。

プロトコル ポート番号 送信元 備考
ICMP ALL オンプレミス側ADのIPアドレス ICMP
TCP/UDP 53 オンプレミス側ADのIPアドレス DNS
TCP/UDP 88 オンプレミス側ADのIPアドレス Kerberos認証
UDP 123 オンプレミス側ADのIPアドレス
UDP 138  オンプレミス側ADのIPアドレス
TCP/UDP 389 オンプレミス側ADのIPアドレス  LDAP
TCP 445 オンプレミス側ADのIPアドレス SMB
TCP 464 オンプレミス側ADのIPアドレス
TCP 636 オンプレミス側ADのIPアドレス
TCP 3268-3269 オンプレミス側ADのIPアドレス
TCP 1024-65535 オンプレミス側ADのIPアドレス
ALL ALL ディレクトリのセキュリティグループ(自分自身)

Kerberos 事前認証を有効にする

ユーザーアカウントの Kerberos 事前認証を有効にします。デフォルトでは有効になっているので今回は作業しませんでした。

この設定を確認する場合は「事前認証」を確認してください。

オンプレミス側 DNS 条件付きフォワーダーの構成

オンプレミス→AWS方向にDNSフォワーダーを設定します。

最初にマネジメントコンソールで必要な情報を収集します。FQDNとDNS ServerのIPアドレスが必要です。

次は、オンプレミスADで作業をします。PowerShellで以下のコマンドを実行します。変数部分は収集した情報に合わせて変更してください。

$dnsservers = @("xx.xx.xx.xx","xx.xx.xx.xx")
$fqdn = "example.internal"

Add-DnsServerConditionalForwarderZone `
-MasterServers $dnsservers `
-Name $fqdn `
-ReplicationScope "Domain"

オンプレミス側の信頼関係の作成

双方向の信頼関係作成をします。

オンプレミスADで作業をします。「Active Directory ドメインと信頼関係」を開き画像の通り操作してください。

この部分もPowerShellで作成したかったのですが、うまくいきませんでした...

AWS側のドメイン名を入力します。

任意の信頼パスワードを設定してください。

信頼関係の作成

双方向の信頼関係作成と、AWS→オンプレミス側のDNSフォワーダーを設定します。

マネジメントコンソールのディレクトリの画面から信頼関係を追加します。

オンプレミス側のドメイン、信頼パスワードを入力する。

信頼方向は双方向に設定し、条件付きフォワーダーにオンプレミスADのIPアドレスを入力する。

ステータスが検証済みになれば成功です。

あとがき

無事に構築できました!オンプレミスADの信頼関係を構築するところをPowerShell化できなかったのが残念ですね、ググると情報は出てくるのですが、今回の環境では上手く動きませんでした。いつかリベンジしたいです。

信頼関係を組むメリットは片方が死んでも継続動作できることです。WorkSpacesでDirectory ServiceをAD ConnectorでオンプレミスADを利用している場合、間の回線(VPN,DX)やオンプレミスADがダウンするとWorkSpacesがマネージドサービスだとしても止まってしまいます。

信頼関係を組むことによって普段は連携し、障害時もサービスが継続期待できます。

以上です、ありがとうございました。