AD DS: Security: Kerberos "Unsupported etype" error when accessing a resource in a trusted domain

Applies to: Windows ServerWindows Server 2016Windows Server 2012 R2 Standard


A computer in a child domain of an Active Directory Domain Services (AD DS) forest cannot access a service that resides in a different domain within the same forest. If you run a network trace on communications to and from the client computer, the trace contains the following Kerberos messages:

6 9:35:19 AM 8/14/2018   17.8417442  KerberosV5   KerberosV5:AS Request Cname: Administrator Realm: Sname: krbtgt/   {TCP:4, IPv4:1}  

7 9:35:19 AM 8/14/2018   17.8452544  KerberosV5   KerberosV5:KRB_ERROR - KDC_ERR_ETYPE_NOSUPP (14)  {TCP:4, IPv4:1}  

On the domain controller of the child domain, Event Viewer records the following Event 14 entry: 

Log Name: System
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center
Event ID: 14
Task Category: None
Level: Error
Keywords: Classic
While processing an AS request for target service krbtgt, the account Administrator did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 3. The accounts available etypes : 23 -133 -128. Changing or resetting the password of Administrator will generate a proper key.


This problem occurs when you configure the child domain (or just the client) as follows:

  • You disable the RC4_HMAC-MD5 encryption type, leaving the AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96 encryption types enabled.
  • You disable NTLM authentication.

Kerberos encryption types

RC4 encryption is considered less secure than the newer encryption types, AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96. Security guides such as the Windows 10 Security Technical Implementation Guide provide instructions for improving the security of a computer by configuring it to use only AES128 and/or AES256 encryption (see Kerberos encryption types must be configured to prevent the use of DES and RC4 encryption suites). 

Such a client can continue to connect to services within its own domain that use AES128 or AES256 encryption. However, other factors can prevent the client from connecting to similar services in another trusted domain, even if those services also use AES128 or AES256 encryption. 

At a very high level, a domain controller (DC) is responsible for managing access requests within its own domain. As part of the Kerberos authentication process, the DC checks that both the client and the service can use the same Kerberos encryption type. However, when a client requests access to a service in a different, trusted domain, the client's DC must "refer" the client to a DC in the service's domain. When the DC builds the referral ticket, instead of comparing the encryption types of the client and the service, it compares the encryption types of the client and the trust.

The problem occurs because of the configuration of the trust itself. In Active Directory, a domain object has associated trusted domain objects (TDOs) that represent each domain that it trusts. The attributes of a TDO describe the trust relationship, including the Kerberos encryption types that the trust supports. The default relationship between a child domain and a parent domain is a two-way transitive trust that supports the RC4 encryption type. Both the parent and the child domain have TDOs that describe this relationship, including the encryption type.

When the client contacts the DC to request access to the service, the DC determines that the service is in the trusted domain The DC checks the trust configuration to identify the encryption type that the trust supports. By default, the trust supports RC4 encryption but not AES128 or AES256 encryption. On the other hand, the client cannot use RC4 encryption. The DC cannot identify a common encryption type, so it cannot build the referral ticket, and the request fails.

NTLM authentication

After the Kerberos authentication fails, the client tries to fall back to NTLM authentication. However, if NTLM authentication is disabled, the client has no other alternatives. Therefore, the connection attempt fails.


To resolve this problem, use one of the following methods:

The choice depends on your security needs and your need to minimize disruption or maintain backward compatibility.

Method 1: Configure the trust to support AES128 and AES 256 encryption in addition to RC4 encryption

This method adds the newer encryption types to the trust configuration for non-Windows realms, and does not require any changes to the client or the service. In this method, you use the ksetup command-line tool to configure the trust. 

To configure the Kerberos encryption type of a trust, open a Command Prompt window on a DC in the trusted domain and then enter for following command:

ksetup /setenctypeattr <trustingdomain> RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

In the example in which is the root domain (where the service resides) and is the child domain (where the client resides), open a command prompt window on a DC and then enter the following command:

ksetup /setenctypeattr RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

After this command finishes, the DC can successfully build the referral ticket that the client can use to reach the DC.

Because the relationship between the two domains is a two-way transitive trust, configure the other side of the trust by opening a Command Prompt window on a DC and then enter the following command:

ksetup /setenctypeattr RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

After this command finishes, a DC can build referral tickets for any clients in that cannot use RC4 encryption but must use resources in

For more information about the ksetup tool, see ksetup.

Method 2: Configure the client to support RC4 encryption in addition to AES128 and AES256 encryption

This method involves changing the configuration of the client instead of the trust. You can change the configuration of a single client, or use Group Policy to change the configuration of multiple clients in a domain. However, the main drawback to this configuration change is that if you disabled RC4 encryption in order to improve security, rolling back that change may not be possible.

For complete instructions to change the encryption types that clients can use, see Windows Configurations for Kerberos Supported Encryption Type.

Method 3: Configure the trust to support AES128 and AES 256 encryption instead of RC4 encryption

This method resembles method 1 in that you configure the trust attributes.

In the case of Windows forest trusts, both sides of the trust support AES. therefore, all ticket requests on the trust use AES. However, a third-party Kerberos client that inspects the referral ticket might notify you that the ticket uses an encryption type that the client does not support. In order to continue to allow such a client to inspect the ticket, update it to support AES.

When you use this method, configure the trust by using the Active Directory Domains and Trusts MMC snap-in.

To use this method, follow these steps:

  1. In Active Directory Domains and Trusts, navigate to the trusted domain object (in the example, Right-click the object, select Properties, and then select Trusts.
  2. In the Domains that trust this domain (incoming trusts) box, select the trusting domain (in the example,
  3. Select Properties, select The other domain supports Kerberos AES Encryption, and then select OK.
    Properties of a child domain in an AD DS forest, highlighting the
  4. On the Trusts tab, click OK.
  5. Navigate to the domain object for the trusting domain (
  6. Repeat steps 1 – 4 to make sure that the trust configuration for this domain mirrors the trust configuration for the other domain (in this case, the incoming and outgoing trust lists include