AWS Managed Microsoft ADを作成した後すぐにやるべき設定まとめ

# はじめに
お疲れ様です。矢儀 @yuki_ink です。

**AWS Managed Microsoft AD、使ってますか？？**

AWS Managed Microsoft ADは、AWS上で独自ドメインを管理したいとなったときに非常に便利なサービスです。
しかし、いざ作成しても、そのまま使い始めると躓いてしまうポイントがいくつかあります。
特に、いろんな制約のあるエンタープライズでは！

ということで、今回はそんな躓きポイントで躓かないために、AWS Managed Microsoft ADを作成したあとにまずやるべき設定をまとめます。

:::note
今書いているもの以外にも、思いついたら加筆していきます！
「これも最初にやるべき」という設定があれば、コメントいただければ幸いです！
:::


AWS Managed Microsoft ADを作成し、ステータスがアクティブになったところから始めます！
今回はマネコンぽちぽちで作りました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/ea35cff1-7767-4e8a-8c98-92cc4be3df3b.png)


# 最初にやるべき設定

1. 自動生成されたセキュリティグループの修正
1. モニタリング・ログ転送設定の有効化
1. 未使用のネットワーク暗号・プロトコル暗号の無効化
1. AD管理サーバの構築
1. パスワードポリシーの設定
1. ドメインユーザ作成
1. 条件付きフォワーダーの設定
1. LDAPS通信の有効化


## 1. 自動生成されたセキュリティグループの修正

:::note warn
**以下のようなケースで、セキュリティグループの修正が必要です。**
- **VPC外のリソースからAWS Managed Microsoft ADを利用したい場合**（信頼関係や条件付きフォワーダーの設定など）
- **社内のセキュリティ要件を満たすため、必要最小限の通信許可しか設定したくない場合**

【背景】
AWS Managed Microsoft ADの作成時に自動で作成され、ADのENIにアタッチされるセキュリティグループについて、初期状態では次のようなルールが設定されています。
必要に応じて、インバウンドルールを追加してあげる必要があります。

| ルール | 設定内容 |
|-|-|
| インバウンド  | <INS>**ADが作成されたVPCのIPレンジ**</INS>からの、AD関連通信を許可  |
| アウトバウンド  | 全通信（0.0.0.0/0への全てのトラフィック）を許可 (※)  |

※ 少し前までは、アウトバウンドルールは「同一のセキュリティグループに対してのみ、全てのトラフィックを許可」というルールになっていました。
条件付きフォワーダの設定や他ADとの信頼関係の構築の際に、ハマる要素の1つとなっていたのですが、最近改善されたようです。
（参考）[AWS Managed Microsoft AD と オンプレAD で信頼関係を構築する (2020年5月版)](https://dev.classmethod.jp/articles/how-to-setup-microsoft-ad-trust-relationship-202005/)
:::

セキュリティグループの修正にあたっては、現時点では、自動生成されたセキュリティグループを手動で修正するしか方法がありません。

ADに紐づくENIから「セキュリティグループを変更」をクリックし、他のセキュリティグループをアタッチできるか確認しましたが、現時点では `You do not have permission to access the specified resource.` と表示され、エラーとなってしまいます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/5d0b84bc-b4bf-4b1a-857a-27b7a2361477.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/0b8bbf3a-9221-497c-9a6c-2b335264ffeb.png)

抵抗があるかと思いますが、もともとアタッチされているセキュリティグループのルールを、手動で修正しましょう。。




## 2. モニタリング・ログ転送設定の有効化


:::note warn
**「モニタリングしてればよかった…」「監査ログ消失してる…」となる前に！！**
**インシデントが発生してから悔やんでも遅いのです。**

【背景】
AWS Managed Microsoft ADのモニタリング設定とログ転送設定は、現時点のデフォルトでは無効化されています。
特に本番環境で利用する場合は、設定を入れておいたほうがいいと思います。
:::

### 2.1. モニタリング
ADのステータスが `Active (アクティブ)` から `Impaired (障害)` または `Inoperable (操作不能)` に変わると、SNSトピックに通知されるように設定できます。
ADが復旧し、`Active (アクティブ)` に戻ったときにも通知を受け取れるので便利です。

ディレクトリ詳細ページの `メンテナンス` タブ > `ディレクトリのモニタリング` から設定します。
詳細な手順は[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/ms_ad_enable_notifications.html)を参照してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/774cebf6-801d-4cb9-94d7-b67a3ec5dad0.png)


### 2.2. ログ転送
アカウントログオンやオブジェクトアクセス、ポリシー変更といった項目のログを取得できます。
取得できるログの種類は[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/ms_ad_directory_logs.html)を参照してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/fc818dfb-5ee9-4bff-85ce-5746ac7bd716.png)


ディレクトリ詳細ページの `ネットワークとセキュリティ` タブ > `ログ転送` から設定します。
詳細な手順は[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/ms_ad_enable_log_forwarding.html)を参照してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/1fd0ac12-ae1e-4a20-bc96-a7302f2d0266.png)


## 3. 未使用のネットワーク暗号・プロトコル暗号の無効化
:::note warn
**利用しないプロトコル・暗号方式が分かっているのであれば、最初から無効化しておきましょう。**

【背景】
AWS Managed Microsoft ADが対応しているプロトコル・暗号方式については、デフォルトでは全て有効化されています。
後から設定を変えるとなると、影響調査など手間がかかるので、構築時点で利用しないことが分かり切っているものがあるのであれば、最初に無効化しておくことをおすすめします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/49e17617-b52c-45ef-8eda-6cbad81a7914.png)
:::

ディレクトリ詳細ページの `ネットワークとセキュリティ` タブ > `ディレクトリ設定` から設定します。
詳細な手順は[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/ms_ad_directory_settings.html)を参照してください。



## 4. AD管理サーバの構築
以上でマネジメントコンソールでの操作は終わり、いよいよADの中身の設定に入っていきます。
その前提として、AD管理サーバを構築しておきましょう。

以下の記事が参考になります。

https://dev.classmethod.jp/articles/management-server-for-aws-managed-microsoft-ad/

https://blog.serverworks.co.jp/managed_ad_login



## 5. パスワードポリシーの設定

:::note warn
**自社のセキュリティ要件に沿うように、最初にパスワードポリシーを仕込んでおきましょう。**

【背景】
現時点で、デフォルトでは以下のポリシーが設定されていますが、企業のセキュリティ要件に完全にフィットするものではないと思います。
企業内のシステムの一部としてADを使うのであれば、そのポリシーはセキュリティ要件に合致させておきましょう。
後から設定を変えるとなると、影響調査など手間がかかるので、最初にやっておくことをおすすめします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/3e44c43f-d648-46af-83e7-24f00d714a9d.png)
（出典）[AWS Managed Microsoft AD パスワードポリシーについて](https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/ms_ad_password_policies.html)
:::

私からは、以下の設計をおすすめします。
- **<INS>ドメインユーザ</INS>のパスワードポリシーは「きめ細かいパスワードポリシー（PSO）」で制御**
- **<INS>ドメインに参加しているコンピュータ</INS>のパスワードポリシーは「グループポリシー（GPO）」で制御**

パスワードポリシーだけなら「きめ細かいパスワードポリシー（PSO）」で制御するに越したことはないのですが、、
ドメインに参加しているコンピュータ（特にドメイン管理用のコンピュータ）に対しては、セキュリティの観点から、リモートアクセスを拒否する設定を入れることが推奨されています。
そしてそれを設定できるのは「グループポリシー（GPO）」となっているため、コンピュータの制御という意味では「グループポリシー（GPO）」に寄せたほうがよいと考えます。

>ドメインおよびエンタープライズ管理者のネットワーク権限またはドメインに参加しているコンピュータアカウントへのリモートアクセス権限を拒否するグループポリシーオブジェクト (GPO) を作成します。
詳細については、セキュリティポリシー設定に関する Microsoft のドキュメント「[ローカルでのログオンの拒否](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/deny-log-on-locally)」および「[リモートデスクトップサービスによるログオンの拒否](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services)」を参照してください。
>
>（出典）[AWS セキュリティリファレンスアーキテクチャ - AWS Managed Microsoft AD](https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/security-reference-architecture/workplace-aws-managed-ad.html)

### 5.1. きめ細かいパスワードポリシー（PSO）の設定

以下の記事が参考になります。

https://dev.classmethod.jp/articles/tsnote-managed-microsoft-ad-pso-001/


### 5.2. グループポリシー（GPO）の設定

以下の記事が参考になります。

https://www.rem-system.com/post-869/

パスワードポリシーの設定に加え、必要に応じて「ローカルでのログオンの拒否」と「リモートデスクトップサービスによるログオンの拒否」も設定しておきます。


## 6. ドメインユーザ作成
:::note warn
**デフォルトで作成される `Admin` ユーザは、初期構築後は使わないようにします。**
パスワードをランダム文字列にしておいて、あとは放置しておきましょう。
パスワードはマネジメントコンソールからいつでも変えられるので、必要に迫られたらその時にまたパスワードを変更すればいいと思います。

>各 AWS Managed Microsoft AD デプロイには、ディレクトリを管理するためにプロビジョニングされた Active Directory アカウントがあります。このアカウントの名前は Admin です。
ディレクトリをデプロイしたら、ディレクトリにアクセスする必要がある昇格されたユーザーごとに個別の Active Directory ユーザーアカウントを作成することをお勧めします。
これらのアカウントを作成したら、管理者のアカウント認証情報をランダムなパスワードに設定し、ブレークグラスシナリオ用に保存することをお勧めします。
管理者アカウントなどの共有アカウントや汎用アカウントを標準管理に使用しないでください。そうしないと、ディレクトリの監査が困難になります。 
>
>（出典）[AWS セキュリティリファレンスアーキテクチャ - AWS Managed Microsoft AD](https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/security-reference-architecture/workplace-aws-managed-ad.html)
:::

というわけで、普段使い用のドメインユーザを作成します。
詳細な手順は[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_create_user.html)を参照してください。

前述の項目で設定したパスワードポリシーが適用されるよう、また、適切な権限が割り当てられるように、グループの設定などは忘れずに行いましょう！！

ユーザの権限設計については、自社のセキュリティ要件に沿ってくださいとしか言えないのですが、、突き詰めると、役割に応じた最小権限が原則です。
考え方としては、以下のMicrosoftの記事が参考になると思います。

https://learn.microsoft.com/ja-jp/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models


## 7. 条件付きフォワーダーの設定

:::note warn
AWS Managed Microsoft ADには、デフォルトでAmazon Provided DNS (Amazon Route 53 Resolver) へのフォワーダー設定が入っています。
これにより、AWS Managed Microsoft ADのDNSで解決することができない名前解決のリクエストはAmazon Provided DNSに転送され、VPC内部のDNS名 (例：ip-xx-xx-xx-xx.ap-northeast-1.compute.internal) や、インターネット上のDNS名 (例：www.google.co.jp) の名前解決が可能になります。

しかし、オンプレミス環境で独自ドメインをホストしている場合などはAmazon Provided DNSでも名前解決ができないため、別途条件付きフォワーダーを設定してあげる必要があります。

（参考）
- [AWS Directory Serviceで「Managed Microsoft AD」を構築した際の「管理用サーバー」の設定方法](https://dev.classmethod.jp/articles/management-server-for-aws-managed-microsoft-ad/#DNS%25E3%2583%259E%25E3%2583%258D%25E3%2583%25BC%25E3%2582%25B8%25E3%2583%25A3%25E3%2583%25BC)
- [EC2インスタンス上にActive Directory環境を構築する際のTIPS](https://dev.classmethod.jp/articles/tips-for-build-active-directory-on-ec2/#DNS%25E3%2583%2595%25E3%2582%25A9%25E3%2583%25AF%25E3%2583%25BC%25E3%2583%2580%25E3%2583%25BC%25E3%2581%25AE%25E8%25A8%25AD%25E5%25AE%259A)

:::

今回作成したAWS Managed Microsoft AD以外にも、独自ドメインを管理しているドメコンがあるのであれば、条件付きフォワーダーを設定する必要があります。

注意事項を含め、以下の記事が参考になります。

https://note.com/shou0522/n/n2d1c9be83055

レプリケート設定は「このドメインのすべてのDNSサーバー」を必ず選択するようにしましょう。





## 8. LDAPS通信の有効化
追加構築レベルの話なので、「AWS Managed Microsoft AD作成時に最初にやるべき設定」に入れるのは少々気が引けますが…
LDAPS通信が必要なことが分かっているのであれば、初期構築時にまとめてやっておいたほうがいいかな、というレベルです。

以下の記事を参考にしてください。

https://qiita.com/yuki_ink/items/c5bcc22707d298881aa1




# 終わりに
ここまでお目通しいただき、ありがとうございました。
書き始めると結構やることが多くて驚きましたw

:::note
【再掲】
今書いているもの以外にも、思いついたら加筆していきます！
「これも最初にやるべき」という設定があれば、コメントいただければ幸いです！
:::

最後に、上記で紹介できなかったものの、参考にさせていただいた記事を紹介させていただきます。

https://dev.classmethod.jp/articles/lookup-msad-password-policy/

https://dev.classmethod.jp/articles/notes-for-microsoft-ad-aws-directory-service/

https://repost.aws/ja/knowledge-center/ds-private-hosted-zones-msft-ad

ありがとうございました。