Trust creation status reasons - Amazon Directory Service
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Trust creation status reasons

When trust creation fails, the status message contains additional information. Here’s some help understanding what those messages mean.

Access is denied

Access was denied when trying to create the trust. Either the trust password is incorrect or the remote domain’s security settings do not allow a trust to be configured. To resolve this problem, try the following:

  • The Amazon Managed Microsoft AD Active Directory and the self-managed Active Directory you wish to create a trust relationship with, must have the same First Site name. The First Site name is set to Default-First-Site-Name. An access denied error occurs if these names vary between domains.

  • Verify that you are using the same trust password that you used when creating the corresponding trust on the remote domain.

  • Verify that your domain security settings allow for trust creation.

  • Verify that your local security policy is set correctly. Specifically check Local Security Policy > Local Policies > Security Options > Network access: Named Pipes that can be accessed anonymously and ensure that it contains at least the following three named pipes:

    • netlogon

    • samr

    • lsarpc

  • Verify that the above named pipes exist as the value(s) on the NullSessionPipes registry key which is in the registry path HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters. These values must be inserted on separated rows.

    Note

    By default, Network access: Named Pipes that can be accessed anonymously is not set and will display Not Defined. This is normal, as the domain controller's effective default settings for Network access: Named Pipes that can be accessed anonymously is netlogon, samr, lsarpc.

  • Verify the following Server Message Block (SMB) Signing Setting in the Default Domain Controllers Policy. These settings can be found under Computer Configuration > Windows Settings > Security Settings > Local Policies/Security Options. They should match the following settings:

    • Microsoft network client: Digitally sign communications (always): Default: Enabled

    • Microsoft network client: Digitally sign communications (if server agrees): Default: Enabled

    • Microsoft network server: Digitally sign communications (always): Enabled

    • Microsoft network server: Digitally sign communications (if client agrees): Default: Enabled

The specified domain name does not exist or could not be contacted

To resolve this problem, ensure the security group settings for your domain and access control list (ACL) for your VPC are correct and you have accurately entered the information for your conditional forwarder. Amazon configures the security group to open only the ports that are required for Active Directory communications. In the default configuration, the security group accepts traffic to these ports from any IP address. Outbound traffic is restricted to the Security group. You will need to update the outbound rule on the security group to allow traffic to your on premise network. For more information about security requirements, please see Step 2: Prepare your Amazon Managed Microsoft AD.


        Edit security group

If the DNS servers for the networks of the other directories use public (non-RFC 1918) IP addresses, you will need add an IP route on the directory from the Directory Services Console to the DNS Servers. For more information, see Create, verify, or delete a trust relationship and Prerequisites.

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

  • 10.0.0.0 - 10.255.255.255 (10/8 prefix)

  • 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

  • 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

For more information, see https://tools.ietf.org/html/rfc1918.

Verify that the Default AD Site Name for your Amazon Managed Microsoft AD matches the Default AD Site Name in your on-premises infrastructure. The computer determines the site name using a domain of which the computer is a member, not the user's domain. Renaming the site to match the closest on-premises ensures the DC locator will use a domain controller from the closest site. If this does not solve the issue, it is possible that information from a previously created conditional forwarder has been cached, preventing the creation of a new trust. Wait several minutes, and then try creating the trust and conditional forwarder again.

For more information about how this works, see Domain Locator Across a Forest Trust on Microsoft website.


        Default first site name

The operation could not be performed on this domain

To resolve this, ensure both domains / directories do not have overlapping NETBIOS name(s). If the domains / directories do have overlapping NETBIOS names, recreate one of them with a different NETBIOS name, and then try again.

Trust creation is failing because of the error "Required and valid domain name"

DNS names can contain only alphabetical characters (A-Z), numeric characters (0-9), the minus sign (-), and a period (.). Period characters are allowed only when they are used to delimit the components of domain style names. Also, consider the following:

  • Amazon Managed Microsoft AD does not support trusts with Single label domains. For more information, see Microsoft support for Single Label Domains.

  • According to RFC 1123 (https://tools.ietf.org/html/rfc1123), the only characters that can be used in DNS labels are "A" to "Z", "a" to "z", "0" to "9", and a hyphen ("-"). A period [.] is also used in DNS names, but only between DNS labels and at the end of an FQDN.

  • According to RFC 952 (https://tools.ietf.org/html/rfc952), a "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names".

For more information, see Complying with Name Restrictions for Hosts and Domains on Microsoft website.

General tools for testing trusts

The following are tools that can be used to troubleshoot various trust related issues.

Amazon Systems Manager Automation troubleshooting tool

Support Automation Workflows (SAW) leverage Amazon Systems Manager Automation to provide you with a predefined runbook for Amazon Directory Service. The AWSSupport-TroubleshootDirectoryTrust runbook tool helps you diagnose common trust creation issues between Amazon Managed Microsoft AD and an on-premises Microsoft Active Directory.

DirectoryServicePortTest tool

The DirectoryServicePortTest testing tool can be helpful when troubleshooting trust creation issues between Amazon Managed Microsoft AD and on-premises Active Directory. For an example on how the tool can be used, see Test your AD Connector.

NETDOM and NLTEST tool

Administrators can use both the Netdom and Nltest command-line tools to find, display, create, remove and manage trusts. These tools communicate directly with the LSA authority on a domain controller. For an example on how to use these tools, see Netdom and NLTEST on Microsoft website.

Packet capture tool

You can use the built-in Windows package capture utility to investigate and troubleshoot a potential network issue. For more information, see Capture a Network Trace without installing anything.