Active Directory Connector(AD Connector)を試してみた

Active Directory Connector(AD Connector)を試してみた

#AWS Direct Connect
#AWS Directory Service
#AWS
Takuya Shibata

Takuya Shibata

facebook logohatena logotwitter logo
Clock Icon2019.06.13

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

しばたです。
勉強のためActive Directory Connectorを試してみました。

Active Directory Connector(AD Connector)とは

AD Connectorについて管理者ガイドを確認すると

AD Connector は、クラウドの情報をキャッシュせずにディレクトリリクエストをオンプレミスの Microsoft Active Directory へリダイレクトするのに使用するディレクトリゲートウェイです。

と定義されています。

これでも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    = "[email protected]";
    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でやりたかったのですが異常に面倒だったので諦めて権限をサービスアカウントに委任するにある様にウィザードから制御の委任を行います。

今回はウィザードのスクリーンショットを以下に貼っておきます。
ウィザードの細かい説明については弊社加藤のブログをご覧ください。

image

image

image

image

image

(コンピューターオブジェクト と ユーザーオブジェクト の2つ選択してください)

image

(最低限の設定であれば「読み取り」権限だけで良いです。今回は「書き込み」も選択しています)

image

以上でウィザードは完了です。
設定を確認するには「拡張機能」の表示を設定した上でドメインのプロパティを表示し、

image

image

「セキュリティ」にConnectorsグループの権限があればOKです。

image

image

ユーザーアクセス許可

すべての Active Directory ユーザーは、各ユーザー独自の属性を読み取るアクセス許可を持っている必要があります

各ドメインユーザーの設定はデフォルトであれば問題ありません。
ドメインユーザーの権限を制限している環境ではこちらの設定を注意してください。

IP アドレス

AD Connectorは、ディレクトリに接続するときに _ldap._tcp. および _kerberos._tcp. SRV レコードをこれらのサーバーから取得します。
そのため、これらの SRV レコードがこれらのサーバーに含まれている必要があります。

通常Active Directory統合DNSであれば問題なく上記SRVレコードが登録されているはずですが一応確認しておいてください。

image

サブネット用のポート

既存のネットワークのファイアウォールで 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台用意しておきます。
ざっくり下図のイメージです。

image

また、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: SSMRole

AD Connectorを構築してみる

最初にマネジメントコンソールから「Directory Service」に移動し、「ディレクトリのセットアップ」ボタンをクリックします。

image

「AD Connector」を選択し「次へ」をクリック。

image

ディレクトリサイズは環境応じて選びます。
今回は「スモール」を選び「次へ」をクリック。

image

環境に応じたVPCとサブネット2つを選択し「次へ」をクリック。

image

オンプレ側Active Direcotory情報を入力し「次へ」をクリック。

image

image

最後に入力内容の確認がありますので「ディレクトリの作成」をクリックします。

image

これでAD Connectorの作成が開始されますのでしばらく待ちます。

image

エラー無く作成されれば完了です。

image

詳細情報はこんな感じです。

image

image

初期状態ですのでアプリケーション連携はすべて無効となっています。

以上でAD Connectorの構築は完了です。

AD Connectorを試してみる

AD Connectorを利用するユースケースとしてはWorkSpacesでの利用が多いかと思いますが、今回は単純な例としてSSMからのAD参加を試してみます。

【2019.06.13 補足】AWS提供のSSMドキュメント

SSMには既にドメインに参加するためのドキュメントが提供されていたのを後からしったため以下の記事で補足しています。

https://dev.classmethod.jp/cloud/aws/try-active-directory-connector-2/

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ドキュメントを選択し、「ドキュメントの作成」をクリックします。

image

ドキュメントの名前は適当に、ドキュメントタイプは「コマンドのドキュメント」のままコンテンツに上記JSONを転記します。

image

image

画面下部の「ドキュメントの作成」ボタンをクリックすればドキュメントは作成されます。

image

ドメインへの参加

続けて作成したドキュメントをインスタンスに関連付けます。
今回はAWS Tools for PowerShellのNew-SSMAssociationコマンドレットを使い以下の様にします。

# 既定のリージョンおよびプロファイルの指定は環境に合わせて行ってください
Set-DefaultAWSRegion -Region ap-northeast-1
Set-AWSCredential -ProfileName your-profile

# ドキュメントをインスタンスに関連付け
New-SSMAssociation -InstanceId "該当インスタンスのインスタンスID" -Name MyCorp-ConnectADDomain

image

問題が無ければ少し時間が経ったのちに関連付けが成功し、SSMマネージドインスタンスの画面で以下の様に表示されます。

image

ドメインコントローラーを確認すると指定のOUにちゃんとEC2インスタンスが登録されています。

image

Share this article

facebook logohatena logotwitter logo

関連記事

[アップデート] AWS Cloud WANとDirect Connect Gatewayを直接接続できるようになりました

[アップデート] AWS Cloud WANとDirect Connect Gatewayを直接接続できるようになりました

User avatar
のんピ
2024.11.26
[アップデート] AWS Direct Connect のホスト型接続で 25 Gbps のポート速度がサポートされました

[アップデート] AWS Direct Connect のホスト型接続で 25 Gbps のポート速度がサポートされました

[登壇レポート]「オンプレミスネットワークとVPCとを接続する際に考慮すべきポイントを考えてみた」というタイトルで登壇しました #自治体クラウド勉強会

[登壇レポート]「オンプレミスネットワークとVPCとを接続する際に考慮すべきポイントを考えてみた」というタイトルで登壇しました #自治体クラウド勉強会

User avatar
のんピ
2024.05.29
AWS Direct Connect のフェイルオーバーテストを使って待機系の AWS Site-to-Site VPN へ切り替えテストをしてみた

AWS Direct Connect のフェイルオーバーテストを使って待機系の AWS Site-to-Site VPN へ切り替えテストをしてみた

User avatar
いわさ
2024.04.20
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.