【レポート】 AWS Directory Service for Microsoft Active Directory Deep Dive #reinvent #win403

はじめに

中山（順）です

本記事は、以下のセッションのレポートとなります。ご査収ください。

概要

• title: AWS Directory Service for Microsoft Active Directory Deep Dive
• Speaker: Ron Cully (Mgr., Product Management, AWS Directory Service , AWS)

Ron Cully is a Senior Product Manager at AWS where he leads feature and roadmap planning for AWS Directory Service for Microsoft Active Directory (Enterprise Edition), Simple AD, and AD Connector. Ron has over 20 years of industry experience in product and program management of networking and directory related products. He is passionate about delivering secure, reliable solutions that help make it easier for customers to migrate directory aware applications and workloads to the cloud.

セッション

導入部分

「システムをクラウドネイティブな構成にrefactorするにあたり、いきなり実装を変えることは困難な場合が多いです。
rehostなどでいったん仮想化するという選択肢はよくありますよね」という感じの導入からセッションは始まりました。

ドメインコントローラーのデプロイに関する選択肢

大きく、以下の3つがあります。

• On-Premise
• on EC2(IaaS)
• Directory Service(Microsoft AD)

このセッションはMicrosoft ADを取り上げるものとなっております。

本日のアジェンダ

アジェンダは以下の通りです。

• AWS Directory Service (Microsoft AD / MSAD)とは
• 責任共有モデル
• デプロイモデル
• セットアップ
• 管理
• ユースケース

AWS Directory Service (Microsoft AD)とは

MSADの基本的な特徴の紹介

• Windows Server 2012 R2がベース
• マネージメントコンソールなら、3ステップ程度で作成できる（CLIを使ってスクリプト化することも可能）
• Multi-AZに冗長化できる
• ドメインコントローラーを追加可能
• Dynamic DNS
• 認証取得済みのサービス (HIPPA, PCI DSS, SOC etc)
  • Manage Microsoft AD Compliance

責任共有モデル

AWSとユーザーがそれぞれ何をするべきかが述べられていました。
（責任共有モデル）

• AWS
  • Multi-AZ Deployment
  • スキーマ拡張
  • Snapshot, restore
  • etc
• Customer
  • パスワードポリシー
  • 信頼関係
  • 証明書
  • Federation
  • etc

Capacity

エディションごとのキャパシティーについて紹介がありました。

AWS Directory Service Options

AWS Microsoft AD is available in two editions: Standard and Enterprise.

Standard Edition: AWS Microsoft AD (Standard Edition) is optimized to be a primary directory for small and midsize businesses with up to 5,000 employees. It provides you enough storage capacity to support up to 30,000* directory objects, such as users, groups, and computers. Enterprise Edition: AWS Microsoft AD (Enterprise Edition) is designed to support enterprise organizations with up to 500,000* directory objects.

• 機能はエディションが異なっても同じ
• ドメインコントローラー単位の課金
• 30日の試用期間がある

Deployment model

MSADを利用する場合の使い方に関するパターンを紹介されていました。
リソースドメインを別途作るパターンは、比較的大きい組織で見かけることがありますね。

• プライマリーディレクトリーとして単独利用
• リソースディレクトリーとして、On-Premiseや他のMSADのDirectoryと連携（信頼関係を設定）

動作要件

動作要件に関する紹介です。
（詳細は公式ドキュメントを確認しましょう。）
オンプレミスのドメインコントローラーと連携する場合、セットワークの可用性がシステム全体の可用性に大きく影響します。
そのあたりも留意して設計しましょう。

Microsoft AD Prerequisites

• VPC
• 2 Subnet (different AZ)
• (Option)On-premiseとの接続
  • DX
  • VPN Connection

ディレクトリーの作成同時に作成されるリソースも作成されます。

• ENI
  • VPC上にデプロイされるため
• Security Group
  • 許可する接続元のIPアドレスが0.0.0.0/0のため、他のインスタンスに流用してはならない

ベストプラクティス

以下の設定を行うことが推奨されています。
ドメイン参加前に参照するDNSサーバーをいちいち変更するのは面倒なので、押さえておきたいですね。

AWS Directory Service Best Practices

• DHCP OptionSet
  • ドメイン参加にあたり、参照先のDNSをDirectoryにする必要があるため
• Security Group
  • 許可の範囲は必要最小限に
• IAM Role
  • EC2 Systems Managerが利用できる権限
  • ドメイン参加をスムーズに行うため
• ディレクトリーを管理するためのEC2インスタンス(Windows)
  • 詳細は後述

管理する手段

管理ツールとマネージメントコンソールで管理できることが異なるので、把握しておきましょう。

• 管理インスタンスの管理ツール
• マネージメントコンソール

管理用インスタンスにインストールすべきツール

以下の管理ツールが必要になりますので、EC2インスタンスなどを用意して機能を追加しましょう。

• グループポリシー
• ADDS
• DNS

Directoryを作成する際に管理ユーザー名を指定しますが、このユーザで管理用インスタンスにログインして管理することになります。 ただし、できることは限られていますので注意しましょう。 （例えば、特定のOU配下のオブジェクトしか操作できないなど、完全な管理権限はユーザーには与えられません。）

Admin Account

マネージメントコンソールで管理できるもの

マネージメントコンソールでは、以下の管理操作が可能です。

• 他のAWSのサービスとの連携
  • WorkSpaces, WorkDocs, WorlMail
  • Management Console
  • RDS(SQL Serve)
  • etc
• ドメインコントローラー
  • ドメインコントローラーの追加などが可能
• スキーマ拡張
• スナップショット
  • 日次で自動取得できる
  • DirectoryのステータスがImpairedになるなど、異常が発生したらリストアする必要がある
• MFA
  • 既存のRADIUSサーバーとの連携
• IP Routing
• 信頼関係
  • 双方向も片方向もできる
• 監視
  • ステータスが異常の際に通知できる

ユースケース

プライマリーディレクトリーとして利用

以下のようなユースケースがあります。

• EC2インスタンスのドメイン参加
• 各種Windows Workload
  • リモートデスクトップ
  • SQL Server
  • SharePoint
  • .NET Application
  • ADCS(Certification Service)
• 各種AWSのサービスとの連携
  • WorkSpaces, WorkDocs, WorlMail
  • マネージメントコンソール
  • RDS(SQL Server)
  • Connect
  • QuickSight
  • Chime
• Federtion
  • ADSyncやADFSを利用したAzureADとのID／認証連携　

LDAPS通信もできるようになったので、このあたりも必要に応じて構成しましょう。

Secure LDAP Communications

リソースディレクトリーとして

オンプレADと信頼関係を設定し、MSADはリソースディレクトリ（EC2インスタンスやWorkSpacesのインスタンスをドメインに参加させ、ユーザー認証は信頼先のドメインコントローラーで行う）として利用する構成が紹介されていました。

信頼関係を結ぶ場合、ActiveDirectoryのセキュリティグループで、ローカル / グローバル / ユニバーサルなどスコープの違いにも注意しましょう。

VPCやAccountをまたがる場合の考慮事項

• VPC・AccountをPerringで超える場合の考慮事項
  • EC2 Systems Managerでのドメイン参加はできない（手動でのドメイン参加は可能）
  • マネージドサービスとの連携もできない
• 複数のVPC上に作成した各ディレクトリーからOn-Premiseのフォレストを信頼することは可能
  • メリット: 境界が明確、支払いの明確化
  • デメリット: コスト
• MSADは1つにして、他のVPCと連携
  • メリット: コストは比較的下がる（ディレクトリを1つにまとめる）
  • デメリット: 境界があいまいになる（責任やコスト）

まとめ

マネージドサービスを利用することで管理の手間は減る一方で、若干の制約は存在します。
そのあたりを考慮して、採用の是非を検討してみてはいかがでしょうか。

また、Directory Serviceに限ったことではありませんが、責任共有モデルに関する考えは本当に重要です。
使い側がどんな責任を追わなければならないのか、よく確認しましょう。

AWS AccountやVPCをまたがった構成の場合の考慮事項および構成のパターンについても言及されていて、実際の案件でも参考にできそうだと感じました。
大規模な組織だとシングルフォレスト＋マルチドメインの構成を取ることはよくありますが、マルチフォレストは個人的にあまり経験がないので、案件がいつ来てもいいようにしっかり検証しておきたいと思います。