LoginSignup
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Japan AWS Top EngineersAdvent Calendar 2024

Day 7
@yuki_ink

AWS Managed Microsoft AD に LDAPS で接続する【イチから構築！】

Last updated at Posted at 2024-12-08

はじめに

お疲れ様です。矢儀 @yuki_ink です。

re:Invent 2024 のキャッチアップから目を逸らし、AWS Managed Microsoft AD に LDAPS で接続してみたという記事です。

やったこと

エンタープライズCAサーバを立てて、LDAPSを有効化し、AD管理用サーバからAWS Managed Microsoft AD に LDAPS で接続することをゴールとします。
構成図_AD.png

1. リソースを作る

VPC・サブネットから、AWS Managed Microsoft AD・EC2まで、必要なリソースをすべて作成するCloudFormationテンプレートを用意しまた。
今回はこれを使ってリソースの作成を行います。

CloudFormationテンプレート

事前にキーペアを作成していることを前提にしています。
パラメータ KeyName でキーペア名を指定してください。

Windows ServerのAMIは、今回は「Windows_Server-2019-English-Full-Base-2024.11.13」を利用しました。
東京リージョンでは ami-032985d75659a9d00 です。

今回は検証のため、EC2はパブリックサブネットに配置し、インターネット経由で接続します。
パラメータ AllowedPublicIP で指定したIPレンジからのRDP/SSHを許可するようにしていますが、扱いにはご注意ください。

vpc-msad-ec2-setup.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: CloudFormation template to create VPC, subnets with AZ selection, AWS Managed MSAD, and EC2 instances using Key Pair authentication.

Parameters:
  VpcCidr:
    Type: String
    Default: 10.0.0.0/16
    Description: CIDR block for the VPC
  Subnet1Cidr:
    Type: String
    Default: 10.0.1.0/24
    Description: CIDR block for AWS Managed MSAD subnet 1
  Subnet1Az:
    Type: String
    Default: us-east-1a
    Description: Availability Zone for AWS Managed MSAD subnet 1
  Subnet2Cidr:
    Type: String
    Default: 10.0.2.0/24
    Description: CIDR block for AWS Managed MSAD subnet 2
  Subnet2Az:
    Type: String
    Default: us-east-1b
    Description: Availability Zone for AWS Managed MSAD subnet 2
  Subnet3Cidr:
    Type: String
    Default: 10.0.3.0/24
    Description: CIDR block for EC2 subnet
  Subnet3Az:
    Type: String
    Default: us-east-1c
    Description: Availability Zone for EC2 subnet
  WindowsServerAMI:
    Type: String
    Description: AMI ID for Windows Server
  InstanceType:
    Type: String
    Default: t3.medium
    Description: EC2 instance type
  DomainName:
    Type: String
    Description: Fully qualified domain name for Microsoft AD
  AdminPassword:
    Type: String
    Description: Admin password for Microsoft AD
    NoEcho: true
  KeyName:
    Type: String
    Description: Name of the EC2 Key Pair to use for SSH/RDP access
  AllowedPublicIP:
    Type: String
    Description: Allowed public IP address for RDP and SSH access (e.g., 203.0.113.0/32)

Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcCidr
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: MyVPC

  DHCPOptions:
    Type: AWS::EC2::DHCPOptions
    Properties:
      DomainName: !Sub '${DomainName}'
      DomainNameServers: !GetAtt MyMicrosoftAd.DnsIpAddresses

  VPCDHCPOptionsAssociation:
    Type: AWS::EC2::VPCDHCPOptionsAssociation
    Properties:
      VpcId: !Ref MyVPC
      DhcpOptionsId: !Ref DHCPOptions

  Subnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: !Ref Subnet1Cidr
      AvailabilityZone: !Ref Subnet1Az
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: MSAD-Subnet1

  Subnet2:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: !Ref Subnet2Cidr
      AvailabilityZone: !Ref Subnet2Az
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: MSAD-Subnet2

  Subnet3:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: !Ref Subnet3Cidr
      AvailabilityZone: !Ref Subnet3Az
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: EC2-Subnet

  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: MyInternetGateway

  AttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref MyVPC
      InternetGatewayId: !Ref InternetGateway

  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref MyVPC
      Tags:
        - Key: Name
          Value: PublicRouteTable

  PublicRoute:
    Type: AWS::EC2::Route
    DependsOn: AttachGateway
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  PublicRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref Subnet3
      RouteTableId: !Ref PublicRouteTable

  VPCAllowAllSG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow specific IP for RDP and SSH, and VPC internal communication
      VpcId: !Ref MyVPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 3389
          ToPort: 3389
          CidrIp: !Ref AllowedPublicIP
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref AllowedPublicIP
        - IpProtocol: -1
          CidrIp: !Ref VpcCidr
      SecurityGroupEgress:
        - IpProtocol: -1
          CidrIp: 0.0.0.0/0
      Tags:
        - Key: Name
          Value: VPCAllowAllSG

  MyMicrosoftAd:
    Type: AWS::DirectoryService::MicrosoftAD
    Properties: 
      CreateAlias: false
      Edition: Standard
      EnableSso: false
      Name: !Ref DomainName
      Password: !Ref AdminPassword
      VpcSettings: 
        SubnetIds: 
          - !Ref Subnet1
          - !Ref Subnet2
        VpcId: !Ref MyVPC

  WindowsInstanceForADManagement:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref InstanceType
      ImageId: !Ref WindowsServerAMI
      SubnetId: !Ref Subnet3
      KeyName: !Ref KeyName
      SecurityGroupIds:
        - !Ref VPCAllowAllSG
      Tags:
        - Key: Name
          Value: AD-Management-Server
      UserData:
        Fn::Base64: !Sub |
          <powershell>
          tzutil /s "Tokyo Standard Time"
          reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f
          Rename-Computer -NewName "ADManagementServer" -Force -Restart
          </powershell>

  WindowsInstanceForEnterpriseCA:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref InstanceType
      ImageId: !Ref WindowsServerAMI
      SubnetId: !Ref Subnet3
      KeyName: !Ref KeyName
      SecurityGroupIds:
        - !Ref VPCAllowAllSG
      Tags:
        - Key: Name
          Value: Enterprise-CA-Server
      UserData:
        Fn::Base64: !Sub |
          <powershell>
          tzutil /s "Tokyo Standard Time"
          reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f
          Rename-Computer -NewName "EnterpriseCAServer" -Force -Restart
          </powershell>

Outputs:
  VPCId:
    Description: The ID of the created VPC
    Value: !Ref MyVPC
  ADManagementInstance:
    Description: Windows Server for AD Management
    Value: !Ref WindowsInstanceForADManagement
  EnterpriseCAInstance:
    Description: Windows Server for Enterprise CA
    Value: !Ref WindowsInstanceForEnterpriseCA
  DirectoryId:
    Description: The ID of the created Microsoft AD
    Value: !Ref MyMicrosoftAd

CloudFormationテンプレートを実行した結果がこちら！

Microsoft ADは以下のように作成されました。
今回、ドメインは yagitest.local としました。
ネットワークとセキュリティ タブの情報から、DNSアドレスは10.0.1.206と10.0.2.121だと分かります。
image.png

EC2は以下のように作成されました。
image.png

2. AD管理用サーバのセットアップ

AD管理用サーバ（AD-Management-Server）での作業になります。

こちらの記事を参考に、ドメインの設定を行います。

2.1. DNSサーバの設定確認

今回は、上記のCloudFormationテンプレートにて、DHCPオプションを利用して、VPCのDNSサーバをMicrosoft ADに向くよう設定しました。
なのでDNSの設定は既に反映済みです。

コマンドプロンプトで ipconfig /all を打鍵し、一応確認。
image.png
大丈夫そう！

2.2. Windowsをドメインに参加させる

次に[コントロールパネル]-[システムとセキュリティ]-[システム]の「コンピューター名、ドメインおよびワークグループの設定」の「設定の変更」をクリックします。

「変更」をクリックします。

所属するグループのドメインにMicrosoft ADのドメインを入力してOKをクリックします。

今回はドメインに yagitest.local を指定します。
Admin@yagitest.local ユーザの認証情報を入力し、ドメイン参加完了！
image.png

再起動が求められるので、再起動しておきます。
image.png

再起動後は yagitest.local ドメインのユーザでサーバに接続できます。
image.png

2.3. Active Directoryのツール群のインストール

AWS公式ドキュメントに従い、PowerShellで以下のコマンドを実行。

Install-WindowsFeature -Name GPMC,RSAT-AD-PowerShell,RSAT-AD-AdminCenter,RSAT-ADDS-Tools,RSAT-DNS-Server

インストールに少し時間がかかりますが、Success すればOK！
image.png

3. AWS Managed Microsoft ADでLDAPS通信を有効化する

こちらの記事を参考に、設定を行います。

3.1. エンタープライズCAサーバのセットアップ

エンタープライズCAサーバ（Enterprise-CA-Server）での作業になります。

3.1.1. Windowsをドメインに参加させる

2.2. Windowsをドメインに参加させる と同様の手順で、エンタープライズCAサーバも yagitest.local ドメインに参加させます。
image.png

3.1.2. エンタープライズCAのインストール

参考にした記事では言語設定が英語となっています。
私は言語設定を日本語しているため、適宜読み替えて操作しています。

1. デスクトップから [ Server Manager ] を開きます。

2. ページが切り替わったのち、 [ Manage ] > [ Add Role and Features ] を選択します。
2.1. "Before you begin" ページは、そのまま[ Next ] を押します。
2.2. "Select installation" ページでは、"Role-based or feature-based installation" が選択されていることを確認し、そのまま[ Next ] を押します。
2.3. "Select destination server" ページでは、ログイン中の PC が選択されていることを確認し、そのまま[ Next ] を押します。
2.4. "Select server roles" ページでは、 "Active Directory Certificate Services" にチェックをいれます。新しいペインが開いたら、[ Add Feature ] を押します。元の画面に戻ったら[ Next ] を押します。
2.5. "Select Features" ページでは、そのまま [ Next ] を押します。

[ AD DS and AD LDS Tools ]にチェックを入れて、 [ Next ] を押します。
※これで、後続手順で使う ldp.exe を取得できます。
image.png

2.6. "AD CS" ページでは、そのまま [ Next ] を押します。
2.7. "Select Role services" では、"Certification Authority" が選択されていることを確認し、 [ Next ] を押します。
2.8. "Confirm installation selections" ページでは、問題がなければ [ Install ] を押します。

3. インストールが完了したら [ Close ] を押します

インストール完了！！
次の手順として 対象サーバーに Active Directory 証明書サービスを構成する が案内されます。
image.png

以降の作業はドメイン管理ユーザで行ってください。
サーバのローカルユーザー（Administrator など）で操作している場合は、ここでドメイン管理ユーザ（今回であれば Admin@yagitest.local）で接続しなおしてください。

続いて、AD CS アプリケーションの設定を行って、ルートかつ、エンタープライズ CA の認証局 をセットアップします。

1. [ Server Manager ] のダッシュボード画面の右上にある [ フラグマーク ] を押します。

2. [ Configure Active Directory Certificate Services on the destination server ] を選択します。

3. あたらしいページが開いたら、[ Change ] を押して、 AD 管理ユーザの認証情報をいれてください。その後 [ Next ] を押します。
image.png

3.1. "Role Services" ページで "Certificate Authority" を選択します。その後 [ Next ] を押します。
3.2. "Setup Type" ページで "Enterprise CA" を選択します。その後 [ Next ] を押します。
3.3. "CA Type" ページで "Root CA" を選択します。その後 [ Next ] を押します。
3.4. "Private Key" ページで、"Create a new private key" を選択します。その後 [ Next ] を押します。
3.5. "Cryptography for CA" ページは、そのまま [ Next ] を押します。
3.6. "CA Name" ページは、"Common name for this CA" に "root-CA" と入力して [ Next ] を押します。
image.png

3.7. "Validity Period" ページは、5年のまま [ Next ] を押します。
3.8. "CA Database" ページは、そのまま [ Next ] を押します。

4. 入力した値に誤りがないことを確認して、[ Configure ] を押します。セットアップが完了したら、 [ Close ] を押してページを閉じます。

セットアップ完了！！
image.png

3.1.3. 証明書テンプレートの設置

エンタープライズ CA を構築したら、以下の手順で証明書テンプレートを作成します。

1. 再び [ Server Manager ] のダッシュボード画面に戻り、[ Tools ][ Certification Authority ] を押して、"certsrv" を開きます。
image.png

2. [ root-CA ] を開き、[ Certificate Templates ] を右クリックして、 [ Manage ] を押します。

3. 一覧から [ Kerberos Authentification ] を右クリックし、 [ Dupulicate Template ] を押します。

4. 以下を行います。全て完了したら [ OK ] を押します。
4.1. [ General ] タブにて、"Template display name" を "LDAPSOverSSL" に変更します。 "Publish ceritificate in Active Directory" にチェックを入れます。
image.png
4.2. [ Compatibility ] タブにて、 "Certification Authority" を "Windows Server 2016" にします。 "Ceritification recipient" を "Windows Server 2012 R2" に変更します。
image.png
4.3. [ Security ] タブにて、[ Domain Controllers ] の権限を Read, Enroll, Autoenroll にします。
image.png

5. コンソールを閉じて、先ほどの "certsrv" に戻り、再び [ Certificate Templates ] を右クリックして、 [ New ] > [ Certificate Template to issue ]を押します。

6. 先ほどの作成した証明書テンプレート "LDAPSOverSSL" を選択して [ OK ] を押します。 ※ "LDAPSOverSSL" が一覧に出るまで、ラグがあります。
image.png

3.2. AWS Managed Microsoft ADとエンタープライズCA間の通信許可

今回はVPC内通信を全許可するSGを作成してEC2に付与しており、またAWS Managed Microsoft AD作成時に自動で作成されるSGもVPC内からの必要なポートの通信を許可する設定が入っているため、特に対応は必要ありません。

通信要件は公式ドキュメントを参照してください。
※ADとエンタープライズCA間の全てのトラフィックを許可するような記述になっていますが、頑張ればもっと絞れると思われる。。

3.3. AWS Managed Microsoft ADとのLDAPS通信の確認

ここでちょっと休憩！！
時間をおいてから実施しましょう。

AD が エンタープライズ CA に証明書を自動取得するまで、最大で30分ほどかかるので気長に待ちましょう。

エンタープライズCAサーバからMicrosoft ADにLDAPS通信してみます。

デスクトップで ldp で検索して、アプリケーションを開始します。
image.png

Connect を押して、
image.png
Server に ADドメイン名（今回は yagitest.local）、Port に 636、[ SSL ] にチェックを付けて、OK を押します。
image.png

接続できると証明書情報が返ってきます。
よさそう！！
image.png

3.4. LDAPS通信に必要な証明書のエクスポート

エンタープライズCAサーバからMicrosoft ADにLDAPS通信ができることは確認できましたが、証明書がインポートされていない他の端末からはLDAPS通信はできません。
そのため、必要な証明書をエクスポートしておきます。

こちらの記事を参考に、作業を行います。

1. エクスポートしたい証明書を有するドメイン・コントローラーにログインします。

2. 「Windows Key + R」を押下し、「mmc.exe」と入力してMicrosoft管理コンソール(MMC)を開きます。

3. MMC上で、「ファイル」を開き、「スナップインの追加と削除」を選択します。

4. 「証明書」を選択し、「追加」をクリックします。
4.1. 「コンピューター アカウント」を選択し、「次へ」をクリックします。
4.2. 「ローカル コンピューター」を選択し、「完了」をクリックします。

5. ドメイン・コントローラーに発行された証明書(サーバー証明書)は、Microsoft管理コンソール(MMC)の「証明書(ローカル コンピューター)」>「個人」>「証明書」で確認できます。
注: 「発行先」の値には、該当のドメイン・コントローラーの完全修飾ドメイン名(FQDN)が含まれます。「発行者」の値には、中間CA証明書の名前が含まれます。

6. 該当の証明書を右クリックし、「すべてのタスク」から「エクスポート」を選択して、証明書をエクスポートします。エクスポートする証明書ごとに、これらのステップの対応をしてください
6.1. 「次へ」をクリックし、その後「いいえ、秘密キーをエクスポートしません」のオプションを選択して、再度「次へ」をクリックします。証明書の形式に「Base-64 encoded」を選択して「次へ」をクリックします。
6.2. 証明書の名前を入力するか、エクスポートの宛先フォルダーを選択して、「次へ」をクリックします。
6.3. 「完了」をクリックして証明書のエクスポートを完了します。

7. 中間CA証明書は「証明書(ローカル コンピューター)」>「中間証明機関」>「証明書」で確認できます。中間CA証明書の「発行先」の値はステップ5の「発行者」のフィールドで確認されたものと同じ名前になっています。

8. 中間CA証明書をエクスポートするには、ステップ6を再度実施します。

9. ルートCA証明書は「証明書(ローカル コンピューター)」>「信頼されたルート証明機関」>「証明書」で確認できます。ルートCA証明書の「発行先」の値はステップ5の「発行者」のフィールドで確認されたものと同じ名前になっています。

10. ルートCA証明書をエクスポートするには、ステップ6を再度実施します。

今回はルートCA証明書をエクスポートして利用します。
ルートCA証明書を確認すると、root-CA の記載が2つありましたが、片方のみの証明書のエクスポートで大丈夫です。
※両方エクスポートして証明書の中身を比較しましたが、内容は同じでした。
image.png

今回は LDAP-root-CA.cer という名前で証明書をエクスポートしました。
image.png

4. AD管理用サーバからMicrosoft ADにLDAPS通信してみる

AD管理用サーバ（AD-Management-Server）での作業になります。
私はローカルユーザ（Administrator）で接続し、作業しました。

4.1. 証明書のインストール

3.4. LDAPS通信に必要な証明書のエクスポート でエクスポートした証明書を、AD管理用サーバにインストールします。

LDAP-root-CA.cer を以下の操作でインストールしていきます。

＝＝＝＝＝＝

証明書ファイルをダブルクリックして、証明書のインストール をクリック。
image.png

保存場所は ローカルユーザー を選択。
image.png

証明書ストアはデフォルトに任せましょう。
image.png

終わり。
image.png

4.2. やってみる

3.3. AWS Managed Microsoft ADとのLDAPS通信の確認 と同様に ldp.exe を起動し、接続！
image.png

いけました！！
image.png

終わりに

AWS Managed Microsoft AD に LDAPS で接続してみました。
HTTPSはよく使うけどLDAPSは使ってない、というような環境も多いと思いますが、ID・パスワードの情報がやりとりされる通信こそセキュアであるべきかなと思います。
何かのお役に立てば幸いです。

次はLinuxサーバからのLDAPS通信を試したい！

本記事の執筆にあたっては以下のブログを参考にガッツリ引用させていただきました。
ありがとうございました。

参考文献

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?