AWS Managed Microsoft AD のベストプラクティス - AWS Directory Service

AWS Managed Microsoft AD のベストプラクティス

問題を回避し、AWS Managed Microsoft AD を最大限に活用するために考慮する必要のあるいくつかの提案とガイドラインを示します。

セットアップ: 前提条件

ディレクトリを作成する前に、これらのガイドラインを検討してください。

Verify You Have the Right Directory Type

AWS Directory Service provides multiple ways to use Microsoft Active Directory with other AWS services. You can choose the directory service with the features you need at a cost that fits your budget:

  • AWS Directory Service for Microsoft Active Directory is a feature-rich managed Microsoft Active Directory hosted on the AWS cloud. AWS Managed Microsoft AD is your best choice if you have more than 5,000 users and need a trust relationship set up between an AWS hosted directory and your on-premises directories.

  • AD Connector simply connects your existing on-premises Active Directory to AWS. AD Connector is your best choice when you want to use your existing on-premises directory with AWS services.

  • Simple AD is an inexpensive Active Directory–compatible service with the common directory features. In most cases, Simple AD is the least expensive option and your best choice if you have 5,000 or fewer users and don’t need the more advanced Microsoft Active Directory features.

For a more detailed comparison of AWS Directory Service options, see オプションの選択.

Ensure Your VPCs and Instances are Configured Correctly

In order to connect to, manage, and use your directories, you must properly configure the VPCs that the directories are associated with. See either AWS Managed Microsoft AD の前提条件, AD Connector の前提条件, or Simple AD の前提条件 for information about the VPC security and networking requirements.

If you are adding an instance to your domain, ensure that you have connectivity and remote access to your instance as described in EC2 インスタンスを AWS Managed Microsoft AD ディレクトリに結合する.

Be Aware of Your Limits

Learn about the various limits for your specific directory type. The available storage and the aggregate size of your objects are the only limitations on the number of objects you may store in your directory. See either AWS Managed Microsoft AD の制限, AD Connector の制限, or Simple AD の制限 for details about your chosen directory.

ディレクトリの AWS セキュリティグループの設定と使用について理解する

AWS は、セキュリティグループを作成し、それをディレクトリのドメインコントローラーの Elastic Network Interface にアタッチします。このセキュリティグループは、ドメインコントローラーへの不要なトラフィックをブロックし、Active Directory の通信に必要なトラフィックを許可します。AWS では、Active Directory の通信に必要なポートのみを開くようにセキュリティグループを設定します。デフォルト設定では、セキュリティグループは、これらのポートに対する任意の IP アドレスからのトラフィックを受け入れます。AWS では、ユーザーの VPC、ピアリングされた VPC、またはサイズ変更した VPC からアクセスできるドメインコントローラーのインターフェイスにセキュリティグループをアタッチします。これらのインターフェイスにインターネットからアクセスすることはできません (ルーティングテーブルを変更しても、VPC へのネットワーク接続を変更しても、NAT ゲートウェイサービスを設定してもアクセスできません)。そのため、VPC へのネットワークパスを持つインスタンスとコンピュータのみがディレクトリにアクセスできます。これにより、特定のアドレス範囲を設定する必要がないため、セットアップが簡素化されます。代わりに、信頼できるインスタンスやコンピュータからのトラフィックのみを許可するルートやセキュリティグループを VPC 内に設定します。

ディレクトリのセキュリティグループを変更する

ディレクトリのセキュリティを強化する場合は、セキュリティグループで許可するトラフィックの送信元 IP アドレスのリストを絞り込みます。たとえば、許可するアドレスを 0.0.0.0/0 から 単一のサブネットやコンピュータ別の CIDR 範囲に変更できます。同様に、ドメインコントローラーが通信する送信先アドレスを制限することもできます。このような変更を行うのは、セキュリティグループのフィルタリング機能を完全に理解している場合に限ります。詳細については、Amazon EC2 ユーザーガイドの「Linux インスタンスの Amazon EC2 セキュリティグループ」を参照してください。不適切な変更を行うと、対象のコンピュータやインスタンスとの通信が失われる場合があります。追加のポートを開くと、ディレクトリのセキュリティが低下します。AWS は、追加のポートを開かないようお勧めします。「AWS の責任共有モデル」をよくお読みください。

警告

ディレクトリで使用するセキュリティグループを、ユーザーが作成した他の EC2 インスタンスと関連付けることは技術的には可能です。ただし、AWS では、この方法をお勧めしません。AWS では、管理対象ディレクトリの機能上またはセキュリティ上のニーズに対処するために、予告なしにセキュリティグループを変更する場合があります。このような変更は、ユーザーがディレクトリのセキュリティグループを関連付けるインスタンスに影響します。さらに、ディレクトリのセキュリティグループを EC2 インスタンスに関連付けると、EC2 インスタンスのセキュリティリスクが発生する可能性があります。ディレクトリのセキュリティグループは、必要な Active Directory ポートで任意の IP アドレスからのトラフィックを許可します。このセキュリティグループを関連付ける EC2 インスタンスにインターネットにアタッチされたパブリック IP アドレスがあると、開いているポートでインターネット上の任意のコンピュータが EC2 インスタンスと通信できます。

セットアップ: ディレクトリの作成

ディレクトリを作成する際に考慮するべき提案をいくつか示します。

お客様の管理者 ID とパスワードを忘れないでください

ディレクトリをセットアップするときに、管理者アカウントのパスワードを指定します。AWS Managed Microsoft AD のアカウント ID は Admin です。このアカウント用に作成したパスワードを忘れないでください。そうでないと、ディレクトリにオブジェクトを追加できません。

DHCP オプションセットの作成

AWS Directory Service ディレクトリの DHCP オプションセットを作成し、ディレクトリが含まれている VPC にこの DHCP オプションセットを割り当てることをお勧めします。このようにすると、その VPC 内のインスタンスは、指定されたドメインを参照し、DNS サーバーはドメイン名を解決できます。

DHCP セットの詳細については、「DHCP オプションセットの作成」を参照してください。

追加ドメインコントローラーのデプロイ

デフォルトでは、AWS は別々のアベイラビリティーゾーンに存在する 2 つのドメインコントローラーを作成します。これにより、ソフトウェアのパッチ適用など、1 つのドメインコントローラーが到達不能または利用不可になる可能性があるイベント中の耐障害性が提供されます。耐障害性をさらに高め、ドメインコントローラーまたはアベイラビリティーゾーンへのアクセスに影響する長期的なイベントの発生時にパフォーマンスが確実に拡大されるように、追加のドメインコントローラーをデプロイすることをお勧めします。

詳細については、「Windows DC Locator Service を使用する」を参照してください。

AWS アプリケーションのユーザー名の制限を理解する

AWS Directory Service は、ユーザー名の作成に使用できるほとんどの文字形式をサポートしています。ただし、AWS アプリケーション (例: Amazon WorkSpaces、Amazon WorkDocs、Amazon WorkMail、Amazon QuickSight) へのサインインに使用されるユーザー名には、文字制限が適用されます。これらの制限により、以下の文字は使用できません。

  • スペース

  • !"#$%&'()*+,/:;<=>?@[\]^`{|}~

注記

@ 記号は、UPN サフィックスが後に続く場合に限り、使用できます。

ディレクトリの使用

ここでは、ディレクトリを使用する場合に、心に留めておくべき推奨事項をいくつか示します。

事前定義されたユーザー、グループ、組織単位を変更しない

AWS Directory Service を使用して、ディレクトリを起動する場合、AWS は、ディレクトリのオブジェクトがすべて含まれているの組織単位 (OU) を作成します。この OU はドメインルートにあります。OU にはディレクトリを作成する際に入力した NetBIOS 名があります。ドメインルートは AWS が所有し、管理します。いくつかのグループと管理ユーザーも作成されます。

これらの事前定義されたオブジェクトを移動、削除、または他の方法で変更しないでください。これにより、自分と AWS の両方でディレクトリにアクセスできなくなります。詳細については、「作成されるファイル」を参照してください。

自動的にドメインを結合する

AWS Directory Service ドメインの一部となる Windows インスタンスを起動する場合は、手動で後からインスタンスを追加するより、インスタンスの一部としてドメインを結合するほうが、多くの場合は簡単です。自動的にドメインを結合するには、新しいインスタンスを起動するときに、単にドメイン結合ディレクトリの適切なディレクトリを選択します。詳細は、「Windows EC2 インスタンスをシームレスに結合する」にあります。

信頼を正しく設定する

AWS Managed Microsoft AD ディレクトリと別のディレクトリとの信頼関係を設定する場合は、以下のガイドラインに注意してください。

  • 信頼のタイプは両側 (フォレストまたは外部) で一致する必要があります。

  • 一方向の信頼 (信頼するドメインでの送信、信頼されたドメインでの受信) を使用する場合は、信頼の方向が正しく設定されていることを確認します。

  • 完全修飾ドメイン名 (FQDN) と NetBIOS 名のどちらも、フォレスト/ドメイン間で一意であることが必要です。

信頼関係の設定の手順の詳細については、「信頼関係を作成する場合」を参照してください。

ディレクトリの管理

ディレクトリを管理するためのこれらの提案を考慮します。

スキーマ拡張を慎重に計画する

重要かつ頻繁なクエリ用にディレクトリへのインデックス付けを行う場合、そのためのスキーマ拡張は慎重に適用します。ディレクトリへのインデックス付けが過剰になると、インデックスによるディレクトリ領域の消費や、インデックス付けされた値の急な変更により、パフォーマンスの問題が発生する可能性があるためです。インデックス付けを行うには、Lightweight Directory Access Protocol (LDAP) Directory Interchange Format (LDIF) ファイルを作成し、スキーマ拡張を行う必要があります。詳細については、「スキーマを拡張する」を参照してください。

ロードバランサーについて

AWS Managed Microsoft AD エンドポイントの前にロードバランサーを使用しないでください。Microsoft の Active Directory (AD) は、外部ロードバランシングを使用せずに応答性の最も高い運用中の DC を検出する、ドメインコントローラー (DC) 探索アルゴリズムと共に使用するように設計されています。外部network load balancerによるアクティブな DC の検出は正確でない場合があり、実行中であっても使用できない DC にアプリケーションが割り当てられることがあります。詳細については、Microsoft TechNet の「ロードバランサーと Active Directory」を参照してください。このページでは、外部ロードバランサーを実装するのではなく、AD を正しく使用するようにアプリケーションを修正することを推奨しています。

インスタンスのバックアップの作成

インスタンスを既存の AWS Directory Service ドメインに手動で追加する場合は、最初にそのインスタンスのバックアップまたはスナップショットを作成してください。これは Linux インスタンスを結合する場合には、特に重要です。インスタンスを追加するための手順は、正しく実行しないと、インスタンスに到達できなくなったり、使用できなくなるがあります。詳細については、「ディレクトリのスナップショットまたは復元」を参照してください。

SNS メッセージングの設定

Amazon Simple Notification Service (Amazon SNS) を使用して、ディレクトリのステータスが変更されたときにメールまたはテキストメッセージ (SMS) を受信することができます。ディレクトリのステータスが [Active] から [Impaired] または [Inoperable] に変わると、通知が送信されます。ディレクトリが Active ステータスが返した時も通知を受け取ります。

また、AWS Directory Service からメッセージを受け取る SNS トピックがある場合は、Amazon SNS コンソールからトピックを削除する前に、ディレクトリに別の SNS トピックを関連付ける必要があることに注意してください。そうしないと、重要なディレクトリステータスメッセージを失う恐れがあります。Amazon SNS をセットアップする方法については、「ディレクトリステータス通知を設定する」を参照してください。

ディレクトリを削除する前に Amazon エンタープライズアプリケーションを削除する

1 つ以上の Amazon エンタープライズアプリケーション (例: Amazon WorkSpaces、Amazon WorkSpaces Application Manager、Amazon WorkDocs、Amazon WorkMail、AWS マネジメントコンソール、Amazon Relational Database Service (Amazon RDS)) に関連付けられているディレクトリを削除する前に、まず各アプリケーションを削除する必要があります。これらのアプリケーションを削除する方法の詳細については、「ディレクトリの削除」を参照してください。

SYSVOL 共有および NETLOGON 共有へのアクセス時に SMB 2.x クライアントを使用する

クライアントコンピュータは、グループポリシー、ログインスクリプト、およびその他のファイルについて AWS Managed Microsoft AD ドメインコントローラー上の SYSVOL 共有および NETLOGON 共有にアクセスするためにサーバーメッセージブロック (SMB) を使用します。2020 年 5 月 31 日以降、AWS は SMB プロトコルのサポートを更新し、SMB バージョン 2.0 (SMBv2) 以降のみをサポートします。

SMBv2 バージョン以降のプロトコルには、クライアントのパフォーマンスを向上させ、ドメインコントローラーとクライアントのセキュリティを強化するいくつかの機能が追加されています。この変更は、SMBv1 の無効化に関する United States Computer Emergency Readiness Team (米コンピュータ緊急事態対策チーム)Microsoft の勧告に従うものです。

重要

現在 SMBv1 クライアントを使用してドメインコントローラーの SYSVOL 共有および NETLOGON 共有にアクセスしている場合は、2020 年 5 月 31 日までに、これらのクライアントを更新して SMBv2 以降を使用する必要があります。この期限が過ぎると、ディレクトリは引き続き正常に動作しますが、SMBv1 クライアントは AWS Managed Microsoft AD ドメインコントローラーの SYSVOL 共有および NETLOGON 共有に接続できなくなり、グループポリシーの処理もできなくなります。

SMBv1 クライアントは、現在使用している他のすべての SMBv1 互換ファイルサーバーとは引き続き動作します。ただし、AWS では、すべての SMB サーバーとクライアントを SMBv2 以降に更新することをお勧めします。システムの SMBv1 を無効にして新しい SMB バージョンに更新する方法の詳細については、Microsoft TechNet およびサポートで関連する投稿を参照してください。

SMBv1 リモート接続の追跡

AWS Managed Microsoft AD ドメインコントローラーにリモート接続して Windows イベントログの Microsoft Windows-SMBServer/Audit を確認できます。このログ内のすべてのイベントは SMBv1 接続を示します。これらのログの 1 つに表示される情報の例を次に示します。

SMB1 アクセス

クライアントアドレス: 203.0.113.0

ガイダンス:

このイベントは、クライアントが SMB1 を使用してサーバーにアクセスしようとしたことを示します。SMB1 アクセスの監査を停止するには、Windows PowerShell コマンドレットの Set-SmbServerConfiguration を使用します。

アプリケーションのプログラミング

アプリケーションをプログラミングする前に、以下の点を考慮します。

Windows DC Locator Service を使用する

アプリケーションの開発時、ドメインコントローラー (DC) の探索には、Windows DC Locator Service を使用するか、AWS Managed Microsoft AD の Dynamic DNS (DDNS) サービスを使用するようにします。アプリケーションを DC のアドレスでハードコードしないでください。DC Locator Service では、ディレクトリの負荷を分散できるだけでなく、デプロイにドメインコントローラーの追加によりスケールイン/アウトを活用できます。アプリケーションを固定 DC にバインドした場合、その DC がパッチ適用または復旧を行うと、アプリケーションは残りのいずれかの DC を使用する代わりに、DC へのアクセスを失います。さらに、DC をハードコードすると、1 つの DC にホットスポットが発生する可能性があります。重大な問題な場合、ホットスポットが原因で DC が応答しなくなる可能性があります。このような場合、AWS のディレクトリオートメーション機能によりディレクトリに障害発生済みフラグが付けられ、応答しない DC を置き換える復旧プロセスがトリガーされる可能性があります。

本番稼働用環境にロールアウトする前の負荷テスト

本番稼働用環境のワークロードを表すオブジェクトとリクエストを使用してラボテストを行い、ディレクトリがアプリケーションの負荷に合わせてスケールされることを確認します。追加のキャパシティーが必要な場合は、DC 間でリクエストを分散しながら追加の DC でテストします。詳細については、「追加ドメインコントローラーのデプロイ」を参照してください。

効率的な LDAP クエリを使用する

何万個ものオブジェクトにまたがるドメインコントローラーへの広範な LDAP クエリにより、1 つの DC で大量の CPU サイクルが消費されて、ホットスポットが発生することがあります。これは、クエリ中に同じ DC を共有するアプリケーションに影響を与える可能性があります。