I investigated the details of AWS Managed Microsoft AD Hybrid Edition assessment

This is Shibata.

Yesterday, I wrote articles about trying the new Hybrid Edition of AWS Managed Microsoft AD.

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/

In this article, I would like to share the details of the directory assessment (referred to as "ディレクトリ評価" in the Japanese management console) to the extent currently known.

What is Hybrid Edition Assessment (Directory Evaluation)?

As introduced in my previous article, assessment evaluates whether your directory environment is in an appropriate state for AWS Managed Microsoft AD. It is conducted during directory creation and periodically thereafter.

There are two types of assessments: "Customer" and "System". They differ in their evaluation targets - "evaluation of domain controllers in the customer environment" and "evaluation of domain controllers on the AWS Managed Microsoft AD side" respectively, with different test items for each.

During initial creation, a "Customer" assessment is performed, and after directory creation, a "System" assessment is conducted approximately once per hour.
It's also possible to manually perform a "Customer" assessment after directory creation, though I couldn't confirm whether "Customer" assessments are automatically conducted or not.^[1]

List of Categories and Tests

As of today, there are 43 tests across 7 categories in the assessment.
Although not displayed in the management console UI, there is an internal version, which is currently v1.

			
			# You can check the assessment version from AWS CLI
~ $ aws ds describe-ad-assessment --assessment-id da-xxxxxxxxxxxxx --query "Assessment.{ReportType: ReportType, Version:Version}"
{
    "ReportType": "CUSTOMER",
    "Version": "v1"
}

		

Category List (v1)

The 7 categories are as follows:
I've assigned numbers for easier identification.

The list of tests is as follows.

Different items are implemented for customer assessment and system assessment, and the items also vary between execution before directory creation and after directory creation.
Since there was no document clearly stating when each test is conducted, I've included the implementation timing based on what I found through verification.

For convenience, I have assigned numbers to each test.

Test Details

Below are explanations of each test to the extent possible.

Most tests are executed via SSM Run Command, and for customer assessments, you can check the execution history of each test and the implementation of the executed scripts (PowerShell scripts).
For those where implementation details are available, I will include them in the explanation.

1. Domain Validation Test

1-1. DNS IP Match Test

Checks if the DNS server IP address (DNS IP address) specified during the assessment is included in the Private IP address of the target instance.
An error occurs if the DNS IP address is not included.

1-2. Valid Domain Controller Test

Checks if the target instance is a domain controller.
An error occurs if it is not a domain controller.

Specifically, it retrieves the ProductType value from the WMI Win32_OperatingSystem class and determines if it is 2 (Domain Controller).

			
			# Excerpt of the check process
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. Existing Domain Test

Checks if the target instance is joined to a domain.  
An error occurs if not domain-joined.

The implementation used the `Get-ADDomain` command to determine whether domain information could be retrieved or not.

#### 1-4. Same Domain Test

It appears to check whether the target instance's domain is the same as before the directory update.  
This was only performed during directory updates, but it seems to be checking using a method other than SSM Run Command, so I couldn't determine the details...

#### 1-5. DNS Name Match Test

Checks if the DNS name specified during assessment (the directory's DNS name) matches the Active Directory domain name that the instance is joined to.  
An error occurs if they don't match.

The implementation uses the `Get-ADDomain` command to retrieve the DNS name for testing.

```powershell:testDnsNameMatch.ps1
# Excerpt from script processing

# DNS name to retrieve
(Get-ADDomain).DNSRoot

		

1-6. AWS Administrator User Unknown Test

Checks that specific users and groups do not exist in the domain.

As far as verified, this was only performed during customer assessment prior to creating a directory.
However, in this case, the script was configured to always pass as the users and groups to be checked were not defined.

1-7. AWS Reserved OU Test

Checks if objects with the same names as AWS Managed Microsoft AD's dedicated OUs and group policy objects exist on the target instance.
An error occurs if objects with the same names exist.

Specifically, it checks for the existence of:

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

This test appears to be performed only during customer assessment before creating a directory.

2. Remote Connection Test

2-1. Remote Port Connection Test

I couldn't get details about this test as it seems to be performed using methods other than SSM Run Command.

It appears to be checking connectivity between AWS Managed Microsoft AD domain controllers → existing domain controllers, and vice versa.

From the error message when the test fails:

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

It's clear this is testing whether the ports mentioned in the prerequisites are open.

3. Privilege Test#### 3-1. SSM User Access Permission Test

Check if the SSM execution user on the target instance has Administrator privileges on the local machine.
If Administrator privileges are not present, an error will occur.

The specific implementation follows the common pattern for Windows permission checks.

			
			# Partial excerpt of the check process

# 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)

		

Normally, the Windows SSM Agent operates with administrator privileges, so this test appears to check whether the user has intentionally changed the settings.

4. Network Tests

4-1. DNS Record Test

Checks whether specified records can be retrieved from the domain's DNS.
Specifically, it checks:

• A record for <domain name>
• NS record for <domain name>
• SOA record for <domain name>
• SRV record for <domain name>
• SRV record for _ldap._tcp.<domain name>
• SRV record for _kerberos._tcp.<domain name>

It performs forward lookups.
There was no check for reverse lookups.

4-2. IP Conflict Test

Checks whether the Private IP of the target instance is included in the CIDR ranges reserved by AWS.
An error occurs if the IP is included in the reserved CIDR ranges.

The CIDR ranges reserved by AWS are:

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

All IPv4 addresses of the target instance are subject to this test.

4-3. NTLM Test

Checks the event logs of the target instance to see if NTLM V1 and V2 are enabled.
An error occurs if NTLM V1 is enabled.
If NTLM V2 is enabled, it is treated as a warning but does not result in an error.

5. Replication Test

5-1. Replication Test

Checks if there are any abnormalities in the replication status of the target instance.
An error occurs if abnormalities are detected.

Specifically, it analyzes the results of the repadmin command to check for errors.

			
			# Partial excerpt of the test content: Retrieves results from various repadmin commands and uses them for testing

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 Replication Test

Check the replication method and replication state of `Sysvol` on the target instance.  
Specifically, it checks:

* Whether the replication method has been migrated from FRS to DFSR using the `dfsrmig /getmigrationstate` command
* Whether there are no DFSR error events using the `dcdiag /test:dfsrevent` command

It should fail the test if there are issues with the migration status or error events exist, but currently the test passes even if there are errors in the script execution results.

#### 5-3. Bridgehead Naming Context Test

Checks the replication status for the bridgehead server of the instance.  
Specifically, it uses the `repadmin /bridgeheads /verbose` command, and AWS performs its own analysis to determine if there are any abnormalities.

The test will fail if abnormalities are detected.

### 6. System Tests

#### 6-1. NT4 Encryption Allow Test

Checks if the old "encryption algorithms compatible with Windows NT 4.0" are enabled on the target instance.  
The test will fail if old encryption algorithms are enabled.

Specifically, it inspects the value of the following registry key:

* `HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\AllowNT4Crypto`

#### 6-2. Domain Controller Specification Test

Checks the specifications (CPU core count and memory) of the target instance.  
According to the test script, it requires at least 2 CPU cores and 7GB of memory.

However, the test environment I verified used `t3a.medium` (2 CPU cores, 4GB memory), and although the script execution log showed failures and warnings, the test still passed...

```json:SSM Run Command execution results during verification
// The script result showed failure but the test passed...
{
    "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. Free Space Test

Checks if the target instance's disk has sufficient capacity.
The test fails if the capacity is insufficient.

Specifically, it requires the following allocations based on usage:

• Disk containing Sysvol: 7GB or more allocation
• Disk containing Active Directory database (NTDS): 17GB allocation

Interestingly, despite the test name including "Free Space," it doesn't actually check the available free space.
(It does gather free space information but doesn't use it for testing... perhaps it will be checked in the future?)

6-4. Server Level Plugin DLL Test

Checks if there are ServerLevelPlugin registrations in the DNS of the target instance.
It seems the intention is to fail if there are no plugin registrations, but the implementation appears to be incorrect.

A fresh Active Directory setup doesn't have plugin registrations, and in fact, the test passed without any registrations and the environment was built without any issues.#### 6-5. Disk Corruption Test

Checks for disk corruption in the target instance.
The Get-VolumeCorruptionCount command is used to check for corruption on all drives, and an error occurs if corruption is found.

6-6. S Channel SSP Test

Checks the SSL/TLS support status of the target instance.
Investigates whether TLS 1.2 and AES256 are enabled from registry values, and an error occurs if they are not enabled.

6-7. SMBV1 Test

Checks if SMBv1 is disabled on the target instance.
An error occurs if SMBv1 is enabled.

7. Domain Health Tests

7-1. AWS Administrator User Existence Test

Checks that specific users and groups exist in the domain.
The targeted users and groups appear to vary depending on the test situation.

In this case, an error occurs if the AWS Managed Microsoft AD administrator user (generated with a random ID) does not exist.

Incidentally, this was implemented as the same test script as "1-6. AWS Administrator User Unknown Test" but with different arguments.

7-2. AWS Reserved Group Membership Test

Checks if the AWS Managed Microsoft AD administrator user (generated with a random ID) belongs to the specified administrator groups.
An error occurs if they do not belong to the administrator groups.

Specifically, they need to belong to the following groups:

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

7-3. AWS Reserved OU Resource Test

The content is unknown as it was never executed during verification.

However, I suspect this might be executed when updating the directory, similar to "1-4. Same Domain Test"...^[2]

7-4. Child Domain Test

The "child domain" here doesn't refer to a subdomain but rather means another domain in the same forest.

Checks if there are other domains in the target domain's forest.
An error occurs if domains other than the target domain exist.

It seems the customer environment must also be a single-forest, single-domain configuration.

7-5. Read-Only Domain Controller Test

Checks if the domain is Read-Only (RODC).
An error occurs if it is an RODC.

7-6. FSMO Connectivity Test

Checks the connectivity of each FSMO role.
Confirms that there are domain controllers with each FSMO role and that they can be name-resolved.

An error occurs if there are no FSMO role holders or if name resolution fails.

7-7. LDAP Connectivity Test

Checks the connectivity of the LDAP service.
Examines the LDAP service configuration from the results of the Get-ADRootDSE command and verifies if it matches the expected value (<DomainFQDN>:<DomainControllerName>$@<DomainFQDN>).

An error occurs if it doesn't match the expected value.

7-8. Unknown Administrator User Test

Checks if there are standalone administrator users (what AWS refers to as Orphaned Admin Users) who don't exist in the administrator groups.
An error occurs if even one Orphaned Admin User is found.

It seems this test is in place because having users with strong permissions independently is not good for security.

7-9. Tombstone Lifetime Test

Checks if the domain's Tombstone Lifetime period is too long.
An error occurs if it's set to a value greater than 180 days.#### 7-10. Domain Forest Functional Level Test

Checks whether the forest functional level and domain functional level are within the supported range.
As per the prerequisites, both the forest functional level and domain functional level must be either:

• Windows Server 2016
• Windows Server 2012 R2

If the functional level is outside the supported range, it will result in an error.

7-11. FSMO Non-Read-Only Domain Controller Test

Checks that FSMO roles are not assigned to RODCs.
If even one FSMO role is assigned to an RODC, it will result in an error.

7-12. AD Password Policy Test

Checks the configuration status of the domain password policy.
An error will occur if the following conditions are not met:

1. Default Domain Password Policy
   • Default domain password policy must be configured
   • "Store password using reversible encryption" must not be enabled
2. AWS Reserved OU Password Policy
   • Fine-grained password policy must be configured
   • "Store password using reversible encryption" must not be enabled
3. AWS Service Administrators Group Password Policy
   • Fine-grained password policy must be configured
   • "Store password using reversible encryption" must not be enabled

7-13. Privileged User Count Test

Checks whether there are too many users belonging to administrator privilege groups.
An error will occur if there are too many users in a group.

Specifically, the following conditions apply:

• Domain Admins group: up to 5 users
• Enterprise Admins group: up to 5 users
• Administrators group: up to 5 users

7-14. Read-Only Domain Controller Password Replication Test

Checks the password replication policy settings for RODCs.
An error will occur if password caching for specified administrator groups is not denied when checked with the Get-ADDomainControllerPasswordReplicationPolicy command.

Specifically, the following groups are checked:

• Domain Admins
• Enterprise Admins
• krbtgt
• Schema Admins

Environments without RODCs automatically pass this test.

7-15. Domain Controller Time Source Test

Checks the time synchronization settings in the domain environment.
Based on the implementation, it appears to check the following points:

• The PDC Emulator references an authoritative time server
• Other domain controllers reference the PDC Emulator
• Time is synchronized across all time servers
• Time difference with AWS time server (169.254.169.123) is minimal (within 300 seconds)

7-16. Trust Type Test

Checks the types of trust relationships configured in the domain.
An error will occur if any trust relationships obtained using the Get-ADTrust command are not of type Uplevel.

It appears to test whether there are any old-style trust relationships or trust relationships to non-Windows AD environments.#### 7-17. Active Directory Services Test

Checks whether the services required for a domain controller are running on the target instance.
If the services are not running, it will result in an error.

Specifically, the following services are checked:

• 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 Test

Checks the status of the KRBTGT account required for Kerberos authentication.
The test passes if the klist get command executed against the KRBTGT account returns no errors.

7-19. Top Level GPO Test

Checks if the highest-level group policy objects (such as Default Domain Policy) are enforced.
If there are group policies that are Enforced, it will result in an error.

7-20. AWS Domain Controller non-FSMO Owner Test

Checks if any FSMO roles exist on AWS-managed domain controllers.
It will result in an error if any FSMO roles exist on AWS-managed domain controllers.

This test is only conducted in "System" assessments, so the specific implementation is unknown.
Also, even if the test fails, it was still possible to continue using the directory.

7-21. DcDiag Test

Uses the dcdiag command to check the health of the domain controller.
It executes the dcdiag /c command on the target instance, analyzes the results, and returns an error if problems are detected.

Additional Note: Specifications Gleaned from Troubleshooting

AWS documentation includes a list of errors and warnings for troubleshooting.

• Assessment Test error messages
• Assessment Test warning messages

Regarding warnings (warning messages), since there is no warning status in the test results, this means "the test itself succeeds, but the script execution results fail and a warning message appears."
As of today, these warning messages can only be confirmed through SSM Run Command, so normally you wouldn't notice them...

The previously mentioned "6-2. Domain Controller Spec Test" is of this type, and even with insufficient specifications, passing the assessment is the expected behavior.
There are other tests with this pattern, so please note that even if the script execution result fails, the test may pass if it meets the success criteria.## Finally

This concludes the article.

Please note that these findings are based on the current implementation (v1), so if the version is upgraded in the future, the results may differ from what's described in this article.
I hope that more detailed information will be officially published by AWS in the future.