AWS Managed Microsoft AD Hybrid Edition アセスメントの詳細を調べてみた

しばたです。

前日AWS Managed Microsoft ADの新しいエディションであるHybrid Editionを試してみた記事を書きました。

https://dev.classmethod.jp/articles/aws-managed-microsoft-ad-hybrid-edition/

https://dev.classmethod.jp/articles/how-to-create-aws-managed-microsoft-ad-hybrid-edition-by-cli/

本記事ではディレクトリに対するアセスメント(日本語マネジメントコンソール上の表記は 「ディレクトリ評価」 )の詳細を現在わかる範囲で共有したいと思います。

Hybrid Editionのアセスメント (ディレクトリ評価) とは？

前回の記事でも紹介した通り、アセスメントはディレクトリ環境がAWS Managed Microsoft ADで適切な状態にあるかを評価するものであり、ディレクトリ作成時と作成後定期的に実施されます。

アセスメントには「顧客 (Customer)」と「システム (System)」の2種類あり、それぞれ「顧客環境のドメインコントローラーに対する評価」、「AWS Managed Microosft AD側のドメインコントローラーに対する評価」と評価対象が異なりテスト項目も変わります。

初回作成時は「顧客」アセスメントが実施され、ディレクトリ作成後は「システム」アセスメントが1時間に1回程度実施されます。
ディレクトリ作成後に手動で「顧客」アセスメントを実施することも可能で、「顧客」アセスメントが自動的に実施されるか否かについては確認できませんでした。^[1]

カテゴリーとテストの一覧

本日時点でアセスメントは7つのカテゴリーに43のテストが存在します。
マネジメントコンソールのUIには表示されないものの、内部的にバージョンが存在し現時点でv1となっています。

# AWS CLIからであればアセスメントのバージョンを確認できる
~ $ aws ds describe-ad-assessment --assessment-id da-xxxxxxxxxxxxx --query "Assessment.{ReportType: ReportType, Version:Version}"
{
    "ReportType": "CUSTOMER",
    "Version": "v1"
}

カテゴリー一覧 (v1)

7つのカテゴリーは以下の通りです。
識別しやすい様に便宜上No.を割り当てています。

テスト一覧 (v1)

テストの一覧は次の通りです。

顧客アセスメント、システムアセスメントで実施される項目が異なり、さらにディレクトリ作成前・作成後の実行でも項目は変わる様です。
具体的にどのタイミングで各テストが実施されるか明記されたドキュメントは無かったので検証して分かった範囲で実施タイミングも記載しています。

こちらも便宜上No.を割り当てています。

テスト詳細

ここからは各テストの詳細をわかる範囲で解説していきます。

ほとんどのテストはSSM Run Commandで実施され、顧客アセスメントであれば各テストの実行履歴と実行されたスクリプト(PowerShellスクリプト)の実装も確認できます。
実装を確認できたものについてはその点も踏まえて解説していきます。

1. ドメイン検証テスト

1-1. DNS IP 一致テスト

アセスメント時に指定したDNSサーバーのIPアドレス(DNS IPアドレス)が対象インスタンスのPrivate IPアドレスに含まれているかチェックします。
DNS IPアドレスが含まれていない場合にエラーとなります。

1-2. 有効なドメインコントローラーテスト

対象のインスタンスがドメインコントローラーであるかチェックします。
ドメインコントローラーでない場合にエラーとなります。

具体的にはWMIのWin32_OperatingSystemクラスからProductTypeの値を取得して2 (Domain Controller)かを判定しています。

# チェック処理を一部抜粋
Function Invoke-TestIsComputerDC {
	# Domain Controller product code https://learn.microsoft.com/en-us/dotnet/api/microsoft.powershell.commands.producttype?view=powershellsdk-1.1.0
	$DomainControllerProductCode = 2 
	$ComputerProductType = Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object -ExpandProperty ProductType
	return ($DomainControllerProductCode -eq $ComputerProductType)
}

1-3. 既存のドメインテスト

対象のインスタンスがドメインに参加しているかチェックします。
ドメイン未参加の場合にエラーになります。

実装としてはGet-ADDomainコマンドを使い自ドメインの情報を取得可能か否かで判定していました。

1-4. 同じドメインテスト

ディレクトリの更新時に対象インスタンスのドメインが更新前と同一ドメインか否かをチェックする様です。
ディレクトリの更新時のみ実施されたのですが、SSM Run Command以外の方法でチェックしている様で詳細までは分かりませんでした...

1-5. DNS 名一致テスト

アセスメント時に指定したDNS名(ディレクトリのDNS名)が参加しているActive Directoryドメイン名と一致しているかチェックします。
一致しない場合にエラーとなります。

実装としてはGet-ADDomainコマンドを使いDNS名を取得してテストに使用しています。

# スクリプトの処理を一部抜粋

# 取得するDNS名
(Get-ADDomain).DNSRoot

1-6. AWS 管理者ユーザー不明テスト

ドメインに所定のユーザーとグループが存在しないことをチェックします。

検証した限りではディレクトリを作成する前の顧客アセスメントでのみ実施されました。
ただ、この場合はチェック対象となるユーザーやグループが未設定で必ず合格するスクリプトになっていました。

1-7. AWS リザーブド OU テスト

AWS Managed Microsoft AD専用のOUやグループポリシーオブジェクトと同名のものが対象インスタンスに存在しないかチェックします。
同名オブジェクトが存在する場合はエラーとなります。

具体的には

• OU : AWS Reserved
• GPO : AWS Reserved Policy:User, AWS Hybrid Managed Active Directory Policy, AWS Managed AppLocker Policy

の存在をチェックします。

このテストはディレクトリを作成する前の顧客アセスメントでのみ実施される様です。

2. リモート接続テスト

2-1. リモートポート接続テスト

このテストに関してはSSM Run Command以外の方法で実施しているのか詳細を得ることができませんでした。

AWS Managed Microsoft ADドメインコントローラー → 既存ドメインコントローラー、およびその逆方向の通信で疎通可能かチェックしている様です。

テスト失敗時のエラーメッセージにある

From subnet-xxxxxxxxxxxxx: xx.xx.xx.xx: Connection failed for TCP ports [9389, 3268, 3269, 389, 135, 445, 53, 88]. UDP ports [123].

といった内容から前提条件にあるポートが開いているかチェックするテストになっていることまでは分かります。

3. 特権テスト

3-1. SSM ユーザーアクセス許可テスト

対称インスタンスのSSM実行ユーザーがローカルマシンのAdministrator権限を持っているかチェックします。
Administrator権限がない場合はエラーとなります。

具体的な実装としてはWindowsの権限チェックでよくある形になっていました。

# チェック処理を一部抜粋

# Get Current Principal
$currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
# Check if current user has Admin privileges on local
$adminRole = [Security.Principal.WindowsBuiltInRole]::Administrator
$isUserAdmin = $currentPrincipal.IsInRole($adminRole)

通常であればWindowsのSSM Agentは管理者権限で動作するので、これは「利用者が意図的に設定を変えていないか」確認するためのテストの様です。

4. ネットワークテスト

4-1. DNS レコードテスト

ドメインのDNSから所定のレコードが引けるかチェックします。
具体的には、

• <ドメイン名>のAレコード
• <ドメイン名>のNSレコード
• <ドメイン名>のSOAレコード
• <ドメイン名>のSRVレコード
• _ldap._tcp.<ドメイン名>のSRVレコード
• _kerberos._tcp.<ドメイン名>のSRVレコード

を正引きします。
逆引きのチェックはありませんでした。

4-2. IP コンフリクトテスト

対象インスタンスのPirvate IPがAWSの予約するCIDRに含まれていないかチェックします。
予約CIDRに含まれている場合はエラーとなります。

AWSが予約するCIDRは

• 198.18.0.0/15, 198.19.0.0/16, 169.254.169.0/24

となり、対象インスタンスのすべてのIPv4アドレスがテスト対象になります。

4-3. NTLM テスト

対象インスタンスのイベントログからNTLM V1およびV2が有効になっているかチェックします。
NTLM V1が有効になっている場合エラーとなります。
NTLM V2が有効になっている場合は警告扱いとなるもののエラーにはなりません。

5. レプリケーションテスト

5-1. レプリケーションテスト

対象インスタンスのレプリケーション状態に異常がないかチェックします。
異常があると判定された場合にエラーとなります。

具体的にはrepadminコマンドの結果を解析してエラーが出ていないか検査しています。

# テスト内容を一部抜粋 : 各種repadminコマンドの結果を取得しテストに利用

Function Find-SourceReplicationSummary {
    Return repadmin /replsummary /bysrc
}

Function Find-DestinationReplicationSummary {
    Return repadmin /replsummary /bydest
}

Function Find-DetailedDCReplicationStatus {
    $RawData = $(repadmin /showrepl * /repsto /csv 2> $Null)
    $RawData = $RawData | Where-Object { $_ -notlike "showrepl_ERROR*" }
    Return $RawData | ConvertFrom-Csv
}

5-2. Sysvol レプリケーションテスト

対象インスタンスのSysvolレプリケーションの方法とレプリケーション状態をチェックします。
具体的には

• dfsrmig /getmigrationstateコマンドを使いレプリケーション方法がFRSからDFSRに移行済みか？
• dcdiag /test:dfsreventコマンドを使いDFSRのエラーイベントが存在していないか？

を確認しており、移行状況およびエラーイベントが存在する場合にエラーとなる...はずなのですが現状スクリプトの実行結果にエラーがあってもテストは通る様です。

5-3. Bridgehead ネーミングコンテキストテスト

当該インスタンスのブリッジヘッドサーバーに対するレプリケーション状態をチェックします。
具体的にはrepadmin /bridgeheads /verboseコマンドの結果をAWSが独自に解析して異常がないか判定しています。

異常があるとみなされた場合はエラーとなります。

6. システムテスト

6-1. NT4 暗号を許可テスト

対象インスタンスで古い「Windows NT 4.0 と互換性のある暗号化アルゴリズム」が有効になっていないかチェックします。
古い暗号化アルゴリズムを有効にしているとエラーになります。

具体的には以下のレジストリキーの値を検査します。

• HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\AllowNT4Crypto

6-2. ドメインコントローラースペックテスト

対象インスタンスのスペック(CPUコア数とメモリ量)をチェックします。
テストスクリプトを読む限りではCPUコア数2以上、メモリ7G以上であることを要求します。

ただ、今回検証した環境はt3a.medium(CPU2コア, メモリ4GB)でスクリプトの実行ログには失敗と警告が出ていたのですがテストには合格してました...

// スクリプトの結果は失敗なのにテストは合格になっていた...
{
    "TestPassed": false,
    "TestName": "testDcSpecs",
    "Output": {
        "DiskSizeGb": 30,
        "MemorySizeGb": 4,
        "CpuCores": 2,
        "CpuModel": "AMD EPYC 7571"
    },
    "Warn": "Overriding parameter: requiredCores with 2. Overriding parameter: requiredRam with 7. ",
    "Error": [
        {
            "ErrorMessage": "4 GB ram detected when 7 GB recommended. ",
            "ErrorCode": "INSUFFICIENT_RESOURCES"
        }
    ]
}

6-3. フリースペーステスト

対象インスタンスのディスクに一定の容量があるかチェックします。
容量が不足している場合はエラーになります。

具体的にはActive Directoryデータベースなどの用途に応じて

• Sysvolのあるディスク : 7GB以上の割り当て
• Active Directoryデータベース(NTDS)のあるディスク : 17GBの割り当て

が求められます。

ちなみに、テスト名に「フリースペース」が入っているもの空き容量のチェックまではしてませんでした。
(情報として空き容量の取得はしてるもののテストには使われなかったです...将来的にはチェックされるかも？)

6-4. サーバーレベルプラグイン DLL テスト

対象インスタンスのDNSにServerLevelPluginの登録があるかチェックします。
プラグインの登録が無い場合はエラーにしたい...様なのですが、どうにも実装が間違っている気がします。

初期状態のActive Directoryにはプラグインの登録はありませんし、実際無い状態でテストに合格して特段問題なく環境を構築できました。

6-5. ディスク破損テスト

対象インスタンスのディスクに破損が無いかチェックします。
Get-VolumeCorruptionCountコマンドを使い全ドライブの破損を調べ、破損が見つかった場合はエラーになります。

6-6. S チャネル SSP テスト

対象インスタンスのSSL/TLS対応状況をチェックします。
レジストリ値からTLS 1.2とAES256が有効であるか調査し、有効でない場合はエラーになります。

6-7. SMBV1 テスト

対象インスタンスでSMBv1が無効になっているかチェックします。
SMBv1が有効になっている場合はエラーになります。

7. ドメインヘルステスト

7-1. AWS 管理者ユーザー存在テスト

ドメインに所定のユーザーとグループが存在していることをチェックします。
対象となるユーザー・グループはテストを実施する状況によって変わる様です。

ここではAWS Managed Microsoft ADの管理者ユーザー(ランダムIDで生成されるユーザー)が存在していないとエラーになります。

ちなみに「1-6. AWS 管理者ユーザー不明テスト」と同じテストスクリプトの引数違いとして実装されていました。

7-2. AWS リザーブドグループメンバーシップテスト

AWS Managed Microsoft ADの管理者ユーザー(ランダムIDで生成されるユーザー)が所定の管理者グループに所属しているかチェックします。
管理者グループに所属していない場合はエラーとなります。

具体的には以下のグループに所属している必要があります。

• Domain Admins
• Domain Users
• Schema Admins
• AWS Service Administrators
• Enterprise Admins
• Administrators

7-3. AWS リザーブド OU リソーステスト

検証中一度も実施されなかったため内容は不明です。

ただ、こちらは「1-4. 同じドメインテスト」と同様にディレクトリの更新時に実行されるのでは？という気がしています...^[2]

7-4. 子ドメインテスト

ここで言う「子ドメイン」はサブドメインのことではなく同じフォレストに含まれるという意味での子を指します。

対象ドメインのフォレストに他のドメインが存在しないかチェックします。
対象ドメイン以外のドメインが存在する場合はエラーとなります。

顧客環境もシングルフォレスト・シングルドメイン構成でなければならない様です。

7-5. 読み取り専用ドメインコントローラーテスト

ドメインがRead-Only(RODC)でないかチェックします。
RODCの場合はエラーになります。

7-6. FSMO 接続テスト

FSMOの各役割の接続可能性をチェックします。
FSMOの各役割を持つドメインコントローラーが存在し、かつ、名前解決できるまでを確認します。

FSMOの役割を持ってない状況や名前解決ができない場合はエラーとなります。

7-7. LDAP 接続テスト

LDAPサービスの接続可能性をチェックします。
Get-ADRootDSEコマンドの結果からLDAPサービスの設定状況を調べ期待した値(<ドメインFQDN>:<ドメインコントローラー名>$@<ドメインFQDN>)になっているか確認します。

期待した値でない場合はエラーとなります。

7-8. 著者不明管理者ユーザーテスト

ドメインに管理者グループに存在しない単独の管理者ユーザー(AWSとしてはこの様なユーザーをOrphaned Admin Userと呼称)がいないかチェックします。
Orphaned Admin Userが一人でもいる場合はエラーとなります。

単独で強力な権限を持つユーザーがいることはセキュリティ上よろしくないのでこの様なテストを設けている様です。

7-9. 墓石ライフタイムテスト

ドメインのTombstone Lifetimeの期間が長すぎないかチェックします。
180日より大きい値に設定されている場合はエラーとなります。

7-10. ドメインフォレスト機能レベルテスト

フォレストの機能レベルとドメインの機能レベルがサポート範囲内かチェックします。
前提条件にある通り、フォレストの機能レベル、ドメインの機能レベルともに

• Windows Server 2016
• Windows Server 2012 R2

のいずれかでなければなりません。

サポート外の機能レベルの場合はエラーとなります。

7-11. FSMO 用非読み取り専用ドメインコントローラーテスト

FSMOの各種役割がRODCに割り当てられていないかチェックします。
一つでもFSMOの役割がRODCに割り当てられている場合はエラーとなります。

7-12. AD パスワードポリシーテスト

ドメインのパスワードポリシーの設定状況をチェックします。
以下の条件を満たさない場合はエラーとなります。

1. デフォルトドメインパスワードポリシー
   • デフォルトドメインパスワードポリシーが設定されていること
   • 「暗号化を元に戻せる状態でパスワードを保存」していないこと
2. AWS ReservedOUのパスワードポリシー
   • きめ細かいパスワードポリシーが設定されていること
   • 「暗号化を元に戻せる状態でパスワードを保存」していないこと
3. AWS Service Administratorsグループのパスワードポリシー
   • きめ細かいパスワードポリシーが設定されていること
   • 「暗号化を元に戻せる状態でパスワードを保存」していないこと

7-13. 特権ユーザー数テスト

管理者権限をもつ特定グループに所属するユーザー数が多すぎないかチェックします。
グループに所属するユーザーが多すぎる場合はエラーとなります。

具体的には次の条件となります。

• Domain Adminsグループ : 5名まで
• Enterprise Adminsグループ : 5名まで
• Administratorsグループ : 5名まで

7-14. 読み取り専用ドメインコントローラーパスワードレプリケーションテスト

RODCに対するパスワードレプリケーションポリシーの設定をチェックします。
Get-ADDomainControllerPasswordReplicationPolicyコマンドを使い所定の管理者グループのパスワードキャッシュが拒否されていないとエラーとなります。

具体的には以下のグループがチェック対象となります。

• Domain Admins
• Enterprise Admins
• krbtgt
• Schema Admins

RODCが無い環境は無条件で合格となります。

7-15. ドメインコントローラータイムソーステスト

ドメイン環境の時刻同期設定をチェックします。
実装を見る限り以下の点を確認している様です。

• PDCエミュレーターが権威あるタイムサーバーを参照していること
• その他ドメインコントローラーはPDCエミュレーターを参照していること
• 各タイムサーバーの時刻が同期していること
• AWSのタイムサーバー(169.254.169.123)と時刻のずれが少ないこと(300秒以内)

7-16. 信頼タイプテスト

ドメインに構成されている信頼関係の種別をチェックします。
Get-ADTrustコマンドを使い取得した信頼関係の種類がUplevelでない場合エラーとなります。

古い方式や非Windows AD環境に対する信頼関係が存在しないかテストする意図の模様です。

7-17. アクティブディレクトリサービステスト

対象インスタンスでドメインコントローラーとして必要なサービスが動作しているかチェックします。
サービスが動作していない場合はエラーとなります。

具体的には以下のサービスが対象です。

• ADWS : Active Directory Web Services
• AppIDSvc (Optional) : Application Identity (i.e. Enforces AppLocker policies)
• DFSR : Sysvol
• DNS : DNS Server
• W32Time : Time Server
• SamSS : Security Accounts Manager
• RpcSS : Remote Procedure Call (RPC)
• EventSystem : COM+ Event System
• gpsvc : Group Policy Client
• IsmServ : Intersite Messaging
• NTDS : Active Directory Domain Services
• NetLogOn : NetLogon
• LanmanServer (Optional) : Server
• LanmanWorkstation (Optional) : Workstation

7-18. Kerberos テスト

Kerberos認証に必要なKRBTGTアカウントの状態をチェックします。
KRBTGTアカウントに対しklist getコマンドを実行しエラーが出なければ合格となります。

7-19. トップレベル GPO テスト

最上位にあるグループポリシーオブジェクト(Default Domain Policyなど)が強制されていないかチェックします。
強制(Enforced)されているグループポリシーがある場合はエラーとなります。

7-20. AWS ドメインコントローラー非 FSMO 所有者テスト

FSMOの各役割がAWSマネージドなドメインコントローラーに存在していないかチェックします。
FSMOの各役割がAWSマネージドなドメインコントローラーに存在しているとエラーとなります。

このテストは「システム」アセスメントでのみ実施されるため具体的な実装は不明です。
また、テストに失敗してもディレクトリの継続利用が可能でした。

7-21. DcDiag テスト

dcdiagコマンドを使いドメインコントローラーの正常性をチェックします。
対象インスタンスでdcdiag /cコマンドを実行して結果を解析し、問題があると判定された場合にエラーとなります。

追記 : トラブルシュートから読み取れる仕様

AWSのドキュメントを確認するとトラブルシューティング用のエラーと警告のリストが載っています。

• Assessment Test error messages
• Assessment Test warning messages

このうち警告(warning messages)に関しては、各テストの結果に警告というステータスはないため「テスト自体は成功しているが、スクリプトの実行結果は失敗し警告メッセージが出ている」という状況になります。
本日時点ではこの警告メッセージはSSM Run Command側でしか確認できないため通常はまず気づかないでしょう...

先述の「6-2. ドメインコントローラースペックテスト」もこの類でスペック不足であってもアセスメントとしては成功するのが正常な動作でした。
他のテストでもこのパターンがあり、スクリプトの実行結果が失敗であってもテストに合格していれば問題ないケースがあるのでご留意ください。

最後に

以上となります。

本日時点(v1)における実装を調べた結果のため将来的にバージョンが上がった場合は本記事の内容と異なる結果になる可能性があるのでご了承ください。
今後より詳細な情報がAWS公式に公開されることを期待したいですね。