この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
しばたです。 勉強のためActive Directory Connectorを試してみました。
Active Directory Connector(AD Connector)とは
AD Connectorについて管理者ガイドを確認すると
AD Connector は、クラウドの情報をキャッシュせずにディレクトリリクエストをオンプレミスの Microsoft Active Directory へリダイレクトするのに使用するディレクトリゲートウェイです。
- From : Active Directory Connector
と定義されています。
これでもActive Directoryに親しんでいる方ですが最初に見たときにこの説明が何を言っているのかさっぱり理解できませんでした... ルー語かな？それともロコ語かな？という印象でした。
もう少しかいつまんだ説明を
少し古い記事ですがAWS Solutions Architect ブログの記事にもう少しわかりやすい情報が記載されています。
こちらの内容をふまえてAD Connectorを整理すると、
- AWS環境からオンプレ環境にあるドメインコントローラーに対する通信を中継するためのプロキシサービスである
- 汎用プロキシではなく例えばWorkSpaces、WorkDocs、WorkMailといったAWSのサービス向けの専用プロキシである
ということがわかりました。 このほかに、
- 既存RADIUSサーバーと組み合わせて多要素認証を有効にできる
とった機能もあるそうです。
AD Connectorを利用するための前提条件
AD Connectorがどういったものか概要はつかめたので早速試していきたいのですが、利用に際しての前提条件が結構たくさんあります。
以下、この前提条件をかいつまんで解説します。
VPC
- 少なくとも 2 つのサブネット。各サブネットはそれぞれ異なるアベイラビリティーゾーンにある必要があります。
- VPC は、仮想プライベートネットワーク (VPN) 接続または AWS Direct Connect を通じて既存のネットワークに接続されている必要があります。
- VPC にはデフォルトのハードウェアテナンシーが必要です。
要は複数サブネットにわたる冗長構成である必要があるということです。 これは他のAWSサービスでも良くあるパターンですね。
既存のネットワーク
Active Directory ドメインを持つ既存のネットワークに接続する必要があります。 このドメインの機能レベルは Windows Server 2003 以上である必要があります。 AD Connector は Amazon EC2 インスタンスでホストされているドメインへの接続にも対応しています。
要は機能レベルWindows Server 2003以降のドメインコントローラーと疎通できる環境にある必要があるということです。 こちらは基本オンプレ環境のはなしですが、EC2インスタンスのドメインコントローラーでも良いとされています。
サービスアカウント
次の権限が委任されている既存のディレクトリのサービスアカウントの認証情報が必要です。 * ユーザーおよびグループの読み取り * コンピュータのオブジェクトの作成 * コンピュータのドメインへの結合
AD Connector作成時に専用のドメインユーザーが必要になります。 権限をサービスアカウントに委任するに従い専用のグループとユーザーを用意します。
今回はConnectorsグローバルセキュリテグループとこのグループに所属するadconnectorユーザーを作ります。
オンプレ環境で以下のコマンドを実行してください。
(グループ名、ユーザー名は環境に応じて変更してください)
# オンプレ環境で実施
# ※ ActiveDirectory モジュールがインストールされている前提です
# グローバルセキュリテグループ Connectors を作成
New-ADGroup "Connectors" -GroupScope Global -GroupCategory Security
# Connectors に所属するユーザーを作成
$params = @{
Name = "adconnector";
UserPrincipalName = "adconnector@your-domain.com";
AccountPassword = ConvertTo-SecureString -AsPlainText "P@ssw0rd" -Force;
Enabled = $true;
PasswordNeverExpires = $true;
}
New-ADUser @params
# ユーザーをConnectorsに所属させる
Add-ADGroupMember -Identity "Connectors" -Members "adconnector"ここでConnectorsグローバルセキュリテグループに対して制御の委任(＝AD操作に係る権限の付与)をしてやる必要があります。
PowerShellおじさんとしてはここもPowerShellでやりたかったのですが異常に面倒だったので諦めて権限をサービスアカウントに委任するにある様にウィザードから制御の委任を行います。
今回はウィザードのスクリーンショットを以下に貼っておきます。 ウィザードの細かい説明については弊社加藤のブログをご覧ください。
(コンピューターオブジェクト と ユーザーオブジェクト の2つ選択してください)
(最低限の設定であれば「読み取り」権限だけで良いです。今回は「書き込み」も選択しています)
以上でウィザードは完了です。 設定を確認するには「拡張機能」の表示を設定した上でドメインのプロパティを表示し、
「セキュリティ」にConnectorsグループの権限があればOKです。
ユーザーアクセス許可
すべての Active Directory ユーザーは、各ユーザー独自の属性を読み取るアクセス許可を持っている必要があります
各ドメインユーザーの設定はデフォルトであれば問題ありません。 ドメインユーザーの権限を制限している環境ではこちらの設定を注意してください。
IP アドレス
AD Connectorは、ディレクトリに接続するときに _ldap._tcp. および _kerberos._tcp. SRV レコードをこれらのサーバーから取得します。 そのため、これらの SRV レコードがこれらのサーバーに含まれている必要があります。
通常Active Directory統合DNSであれば問題なく上記SRVレコードが登録されているはずですが一応確認しておいてください。
サブネット用のポート
既存のネットワークのファイアウォールで VPC の両方のサブネットの CIDR に対して次のポートが開かれている必要があります。 * TCP/UDP 53 - DNS * TCP/UDP 88 - Kerberos authentication * TCP/UDP 389 - LDAP これらは、ディレクトリに接続するために必要な最小限のポートです。固有の設定によっては、追加ポートが開かれていることが必要です。
必要に応じてドメインコントローラーのポートを開けておいてください。
- TCP/UDP 53 - DNS
- TCP/UDP 88 - Kerberos authentication
- TCP/UDP 389 - LDAP
上記の他に、例えばAmazon WorkSpaceを利用する場合は、
- UDP 123 - NTP
- TCP 135 - RPC
- UDP 137-138 - Netlogon
- TCP 139 - Netlogon
- TCP/UDP 445 - SMB
- TCP 1024-65535 - Dynamic ports for RPC
で通信できる必要があります。
Kerberos 事前認証
ユーザーアカウントの Kerberos 事前認証を有効にしておく必要があります。
こちらはデフォルト設定であれば有効です。 ドメインユーザーの権限を制限している環境ではこちらの設定を注意してください。
暗号化タイプ
AD Connector は、Active Directory ドメインコントローラーへの認証時の暗号化として、以下のタイプの暗号化をサポートしています。 * AES-256-HMAC * AES-128-HMAC * RC4-HMAC
こちらも大抵の場合は問題ありませんが、ドメインコントローラーでサポートしている暗号化方式を確認したい場合は以下のコマンドを実行してください。
# オンプレ環境で実施
# ※ ActiveDirectory モジュールがインストールされている前提です
$dc = Get-ADObject -Filter 'ObjectClass -eq "computer" -and Name -eq "ドメインコントローラー名"' -Properties *
$flag = $dc."msDS-SupportedEncryptionTypes"
if (($flag -band 0x01) -eq 0x01) {
Write-Host "Support DES-CBC-CRC"
}
if (($flag -band 0x02) -eq 0x02) {
Write-Host "Support DES-CBC-MD5"
}
if (($flag -band 0x04) -eq 0x04) {
Write-Host "Support RC4-HMAC"
}
if (($flag -band 0x08) -eq 0x08) {
Write-Host "Support AES128-CTS-HMAC-SHA1-96"
}
if (($flag -band 0x10) -eq 0x10) {
Write-Host "Support AES256-CTS-HMAC-SHA1-96"
}AD Connectorを構築してみる
ここまでをふまえてやっとAD Connectorを構築できます。 AD ConnectorのCloudFormation Templateは無い様なのでマネジメントコンソールから作成していきます。
構成図
以前紹介したVPN環境をベースにしつつVGWからインターネットへのアクセスが可能な環境を用意し、ここにAD Connectorを構築します。
(Directory Serviceのエンドポイントds.ap-northeast-1.amazonaws.comが要インターネットアクセスのため)
加えて検証用に適当なスペックのWindows Server 2019 EC2インスタンスを1台用意しておきます。 ざっくり下図のイメージです。
また、EC2インスタンスにはSSM用にAmazonSSMManagedInstanceCoreポリシーにDirectory Serviceに対するアクセス権(ds:CreateComputerとds:DescribeDirectories)を持つIAMロールを割り当てておきます。
ロールを作るCloudFormation Templateは以下。
AWSTemplateFormatVersion: 2010-09-09
Parameters:
RoleName:
Description: "Input SSM role name."
Type: String
Default: "EC2RoleforSSM"
Resources:
# IAM Role
SSMRole:
Type: AWS::IAM::Role
Properties:
RoleName:
Fn::Sub: "${RoleName}"
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Principal:
Service:
- "ec2.amazonaws.com"
Action:
- "sts:AssumeRole"
Path: "/"
ManagedPolicyArns:
- "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
Policies:
- PolicyName:
Fn::Sub: "${RoleName}-DomainJoin"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Action:
- "ds:CreateComputer"
- "ds:DescribeDirectories"
Resource: "*"
# Instance Profile
SSMRoleInstanceProfile:
Type: "AWS::IAM::InstanceProfile"
Properties:
InstanceProfileName:
Fn::Sub: "${RoleName}"
Path: "/"
Roles:
- Ref: SSMRoleAD Connectorを構築してみる
最初にマネジメントコンソールから「Directory Service」に移動し、「ディレクトリのセットアップ」ボタンをクリックします。
「AD Connector」を選択し「次へ」をクリック。
ディレクトリサイズは環境応じて選びます。 今回は「スモール」を選び「次へ」をクリック。
環境に応じたVPCとサブネット2つを選択し「次へ」をクリック。
オンプレ側Active Direcotory情報を入力し「次へ」をクリック。
最後に入力内容の確認がありますので「ディレクトリの作成」をクリックします。
これでAD Connectorの作成が開始されますのでしばらく待ちます。
エラー無く作成されれば完了です。
詳細情報はこんな感じです。
初期状態ですのでアプリケーション連携はすべて無効となっています。
以上でAD Connectorの構築は完了です。
AD Connectorを試してみる
AD Connectorを利用するユースケースとしてはWorkSpacesでの利用が多いかと思いますが、今回は単純な例としてSSMからのAD参加を試してみます。
【2019.06.13 補足】AWS提供のSSMドキュメント
SSMには既にドメインに参加するためのドキュメントが提供されていたのを後からしったため以下の記事で補足しています。
SSMドキュメント作成
SSMを使ったActive Direcotryへの接続は、AD環境設定が環境別の情報であるためSSMドキュメントを自作する必要があります。
Active Direcotryへの接続はSSM Agentのaws:domainJoinプラグインによって提供されているので以下の様なドキュメントを作成します。
{
"schemaVersion": "1.0",
"description": "Configuration to join an instance to a corp.shibata.tech domain",
"runtimeConfig": {
"aws:domainJoin": {
"properties": {
"directoryId": "d-1234567890",
"directoryName": "corp.shibata.tech",
"directoryOU": "OU=EC2Instances,DC=corp,DC=shibata,DC=tech",
"dnsIpAddresses": [
"192.168.9.61",
"192.168.9.62"
]
}
}
}
}上記例ではec2instancesというOUに参加させる設定としています。
OUはあらかじめ作成しておいてください。
また、EC2の権限としてds:CreateComputerが必要ですので別途IAMロールを割り当てておいてください。
以下作業手順を紹介します。
マネジメントコンソールからSSMドキュメントを選択し、「ドキュメントの作成」をクリックします。
ドキュメントの名前は適当に、ドキュメントタイプは「コマンドのドキュメント」のままコンテンツに上記JSONを転記します。
画面下部の「ドキュメントの作成」ボタンをクリックすればドキュメントは作成されます。
ドメインへの参加
続けて作成したドキュメントをインスタンスに関連付けます。
今回はAWS Tools for PowerShellのNew-SSMAssociationコマンドレットを使い以下の様にします。
# 既定のリージョンおよびプロファイルの指定は環境に合わせて行ってください
Set-DefaultAWSRegion -Region ap-northeast-1
Set-AWSCredential -ProfileName your-profile
# ドキュメントをインスタンスに関連付け
New-SSMAssociation -InstanceId "該当インスタンスのインスタンスID" -Name MyCorp-ConnectADDomain
問題が無ければ少し時間が経ったのちに関連付けが成功し、SSMマネージドインスタンスの画面で以下の様に表示されます。
ドメインコントローラーを確認すると指定のOUにちゃんとEC2インスタンスが登録されています。
67
