msDS-SupportedEncryptionTypes Attribute in Active Directory: How to View, Set, and Manage

Last updated on:

The msDS-SupportedEncryptionTypes attribute is a writable bitmask field on user, computer, and trust objects in Active Directory (AD) that tells the Kerberos Key Distribution Center (KDC) which encryption algorithms it may use when issuing service tickets for that account. Each bit in the integer value corresponds to a specific encryption type, from the deprecated DES family through RC4 and the current AES standards.

This article covers what msDS-SupportedEncryptionTypes is, how its bitmask values work, and how to manage it using three approaches: Active Directory Users and Computers (ADUC), PowerShell, and ManageEngine ADManager Plus.

msDS-SupportedEncryptionTypes at a glance

LDAP display name msDS-SupportedEncryptionTypes
CN ms-DS-Supported-Encryption-Types
Syntax Enumeration (32-bit unsigned integer bitmask, attributeSyntax: 2.5.5.9, omSyntax: 2)
OM-Syntax 2
Attribute ID (OID) 1.2.840.113556.1.4.1963
System ID GUID 20119867-1d04-4ab7-9371-cfc3d5df0afd
Single- or multi-valued Single-valued
Indexed No
In Global Catalog No
Replicated Yes. Within the domain.
System-Only (writable) False. Writable by administrators and by the computer account itself.
Visible in ADUC UI No. Requires the Attribute Editor tab (Advanced Features enabled).
Applies to User, Trusted-Domain classes (computer accounts via Security-Principal)
First implemented Windows Server 2008 (schema version 44)
Source schema Microsoft core AD schema
Microsoft reference Win32 ADSchema · MS-ADA2 · MS-KILE bit flags

Note: When msDS-SupportedEncryptionTypes is unset (null) or set to 0, the KDC falls back to the domain-wide default. Before the November 2022 security update (CVE-2022-37966), that default was RC4. After the update, the default on a patched DC is an RC4 service ticket with AES256 session keys, controlled by the DefaultDomainSupportedEncTypes registry value on each DC. Setting the attribute explicitly on each account removes the ambiguity entirely.

Bit flag reference

The attribute value is a sum of one or more of the following flags:

Hex Decimal Encryption type
0x01 1 DES_CBC_CRC
0x02 2 DES_CBC_MD5
0x04 4 RC4_HMAC_MD5
0x08 8 AES128_CTS_HMAC_SHA1_96
0x10 16 AES256_CTS_HMAC_SHA1_96
0x20 32 AES256_CTS_HMAC_SHA1_96_SK (enforce AES session keys)

Common combined values administrators set in practice:

Hex Decimal Encryption type
0x00 0 Unset—KDC falls back to domain default (see Note below)
0x08 8 AES128 only
0x10 16 AES256 only
0x18 24 AES128 + AES256 (recommended hardened baseline)
0x1C 28 RC4 + AES128 + AES256 (common transitional value)
0x1F 31 DES + RC4 + AES128 + AES256 (legacy; not recommended)
0x38 56 AES128 + AES256 + AES256-SK (enforce AES session keys; post-Nov 2022 hardening)

What msDS-SupportedEncryptionTypes is used for

msDS-SupportedEncryptionTypes was introduced in Windows Server 2008 alongside native AES support in the Kerberos implementation. Before 2008, AD had no per-account mechanism to advertise encryption capabilities. The KDC inferred supported types from the domain functional level and the account's password-key material. The attribute gave administrators an explicit, per-account control plane for negotiating encryption without relying on domain-wide policy.

The KDC consults msDS-SupportedEncryptionTypes specifically when issuing a service ticket (TGS-REQ). It selects the strongest encryption type that appears in both the client's requested types and the target account's attribute. If the intersection is empty, the KDC returns KDC_ERR_ETYPE_NOTSUPP and the client cannot authenticate to that service. The attribute has no effect on TGT encryption, which is determined by the KRBTGT account's key material and the domain functional level.

Common reasons administrators read or set this attribute:

  • Kerberoasting mitigation: Forcing AES-only on service accounts with SPNs (msDS-SupportedEncryptionTypes = 24) eliminates RC4 service ticket hashes that offline password-cracking attacks exploit.
  • RC4 deprecation: Microsoft began enforcing stricter RC4 handling with the November 2022 security update. Accounts with null or 0 values now behave differently depending on DC patch level, making explicit configuration essential for predictable behavior.
  • Legacy compatibility: Accounts that interact with systems predating AES support (Windows XP, Server 2003, some network appliances) may need RC4_HMAC_MD5 retained in their bitmask to remain accessible.
  • Trust object configuration: Cross-forest and cross-domain trusts use msDS-SupportedEncryptionTypes on the Trusted-Domain object to negotiate Kerberos encryption between realms.
  • Compliance and audit: Many regulatory frameworks and security baselines (CIS, DISA STIG, Microsoft security recommendations) require evidence that DES and RC4 have been disabled on all privileged accounts and service accounts.
  • Windows Hello for Business and Azure AD Kerberos: The AzureADKerberos computer object and accounts used in hybrid Kerberos scenarios need msDS-SupportedEncryptionTypes set to include AES to function correctly.

Note: Setting msDS-SupportedEncryptionTypes on a user account without an SPN has no effect on Kerberos ticket encryption. The KDC only reads this attribute on the target of a service ticket request (the account that owns the SPN). Non-SPN user accounts are never the target of a TGS-REQ, so their attribute value is never consulted. If you find non-SPN accounts with this attribute set, it was likely set by a bulk script that did not filter by SPN and is safe to clear.

  • ADUC
  • PowerShell
  • ADManager Plus
  • Troubleshooting
  • FAQ
 

How to manage msDS-SupportedEncryptionTypes using ADUC

msDS-SupportedEncryptionTypes is not exposed in the standard user or computer properties tabs. You read and set it through the Attribute Editor, which requires Advanced Features to be enabled. The integer value you enter must be the decimal sum of the bit flags you want to enable.

  1. Open Active Directory Users and Computers (dsa.msc).
  2. From the menu bar, select View > Advanced Features.
  3. Navigate to the user or computer object. Right-click and select Properties, then select the Attribute Editor tab.
  4. Scroll to msDS-SupportedEncryptionTypes in the alphabetical list. The current value is shown in the Value column. A value of <not set> means null (0).
  5. Click Edit. Enter the decimal integer representing the bitmask you want (for example, 24 for AES128 + AES256 only). Click OK twice to commit.

Note: ADUC accepts the raw decimal integer. You must calculate the sum of the bit flags you want before entering the value. Use the bit flag table above as a reference. Entering an invalid value (for example, a value with unsupported bits set) will be silently stored but may be ignored by the KDC.

Limitations of ADUC

  • No bulk operations: Each object must be edited individually. ADUC provides no mechanism for setting msDS-SupportedEncryptionTypes across multiple accounts simultaneously.
  • Raw integer only: The Attribute Editor shows and accepts only the raw decimal integer. There is no bitmask decoder built in. You must manually calculate which flags are set.
  • No audit trail: ADUC does not log who changed the value or what the previous value was. Directory Service Changes auditing via Group Policy is required for change tracking.
  • No input validation: ADUC accepts any integer value without validating it against the supported flag set. Entering a nonsensical bitmask will not be rejected at entry time.

How to manage msDS-SupportedEncryptionTypes using PowerShell

PowerShell provides two approaches: the -KerberosEncryptionType parameter on Set-ADUser and Set-ADComputer, which accepts human-readable type names and handles the bitmask calculation automatically, and direct attribute manipulation via -Replace with an integer value for when you need precise bitmask control.

Read the current value

Get-ADUser -Identity svc-webapp -Properties 'msDS-SupportedEncryptionTypes' |
Select-Object SamAccountName, 'msDS-SupportedEncryptionTypes'

Returns the current bitmask value for the specified user account. A null or missing value means the attribute is unset (effectively 0).

Set AES128 and AES256 on a user account (recommended hardened baseline)

Set-ADUser -Identity svc-webapp -KerberosEncryptionType AES128, AES256

Sets msDS-SupportedEncryptionTypes to 24 (0x18) on the user account, enabling AES128 and AES256 and disabling RC4 and DES. Use this for service accounts with SPNs in modern environments.

Set AES128 and AES256 on a computer account

Set-ADComputer -Identity WEB01 -KerberosEncryptionType AES128, AES256

Sets the encryption type bitmask to 24 on the specified computer account. Computer accounts can also update this attribute themselves when processing Group Policy.

Set RC4 + AES (transitional value for environments with legacy systems)

Set-ADUser -Identity svc-legacy -KerberosEncryptionType RC4, AES128, AES256

Sets msDS-SupportedEncryptionTypes to 28 (0x1C). Use this temporarily for accounts that serve clients incapable of AES, while you work toward full AES migration.

Clear the attribute (revert to domain default)

Set-ADUser -Identity svc-webapp -KerberosEncryptionType None

Clears msDS-SupportedEncryptionTypes to 0, reverting the account to the domain default behavior. After the November 2022 update the default is controlled by the DefaultDomainSupportedEncTypes registry value on each DC.

Set using a raw bitmask integer

Set-ADUser -Identity svc-webapp -Replace @{'msDS-SupportedEncryptionTypes' = 56}

Sets the attribute to 56 (0x38 = AES128 + AES256 + AES256-SK) using the raw LDAP attribute name and an integer value. Use -Replace for values not expressible via -KerberosEncryptionType, such as enabling the AES session key enforcement bit (0x20).

Find all SPN accounts with RC4 still enabled

Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
-Properties msDS-SupportedEncryptionTypes, ServicePrincipalName |
Where-Object { $_.msDS-SupportedEncryptionTypes -band 4 } |
Select-Object SamAccountName, msDS-SupportedEncryptionTypes, ServicePrincipalName |
Export-Csv .\rc4-spn-accounts.csv -NoTypeInformation

Uses a bitwise AND (-band 4) to find all user accounts with SPNs where the RC4 bit (0x04) is set, and exports the results to CSV for remediation planning.

Bulk set AES-only on all SPN user accounts

Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
-Properties msDS-SupportedEncryptionTypes |
Set-ADUser -KerberosEncryptionType AES128, AES256

Sets msDS-SupportedEncryptionTypes to 24 on every user account that has at least one SPN registered. Review the account list before running in production.

Bulk set AES-only on all computer accounts in an OU

Get-ADComputer -Filter * `
-SearchBase 'OU=Servers,DC=contoso,DC=com' `
-Properties msDS-SupportedEncryptionTypes |
Set-ADComputer -KerberosEncryptionType AES128, AES256

Sets AES128 + AES256 on all computer accounts in the specified OU. Computer accounts with existing custom values will have them overwritten.

Report msDS-SupportedEncryptionTypes for all user accounts to CSV

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes, PasswordLastSet, ServicePrincipalName |
Select-Object SamAccountName, PasswordLastSet, msDS-SupportedEncryptionTypes,
@{N='HasSPN'; E={ $_.ServicePrincipalName.Count -gt 0 }} |
Export-Csv .\encryption-type-audit.csv -NoTypeInformation

Exports a per-account inventory of encryption type configuration, including whether each account has an SPN. Use this as a baseline audit before enforcing AES-only policies.

Common PowerShell errors

  • KDC_ERR_ETYPE_NOTSUPP after setting AES-only: The client or service does not support AES. Check the client OS version and the msDS-SupportedEncryptionTypes on the service account. Temporarily add RC4 back to restore connectivity, then address the client-side capability before removing RC4 again.
  • Attribute reverts to previous value on computer accounts: Computer accounts update msDS-SupportedEncryptionTypes themselves when Group Policy is processed. If a GPO sets a conflicting value, the GPO wins at the next refresh. Align the PowerShell value with the Network security: Configure encryption types allowed for Kerberos GPO setting, or set the attribute via GPO instead of PowerShell.
  • A referral was returned from the server: The account is in a different domain. Specify -Server <domain-controller-fqdn> to target the correct domain.

Limitations of PowerShell

  • No per-SPN granularity: The attribute applies to all SPNs on the account. You cannot set different encryption types for different SPNs on the same account.
  • Computer accounts can self-update: Windows computers update their own msDS-SupportedEncryptionTypes when processing Group Policy. A manually set value may be overwritten at the next policy refresh if the GPO specifies a different value.
  • DES removal in Server 2025: Windows Server 2025 domain controllers no longer support DES. Accounts with USE_DES_KEY_ONLY set in userAccountControl will fail authentication entirely on Server 2025 DCs, regardless of msDS-SupportedEncryptionTypes.

How to manage msDS-SupportedEncryptionTypes using ADManager Plus

ADManager Plus surfaces msDS-SupportedEncryptionTypes through custom attribute configuration and reporting, giving you a centralized view across all accounts without running individual PowerShell queries. For service account encryption type enforcement, ADManager Plus also supports bulk modification via CSV and templates.

  1. Log in to ADManager Plus.
  2. Navigate to Admin > Custom Settings > LDAP Attributes.
  3. Click + Add Attribute.
  4. Enter msDS-SupportedEncryptionTypes in the LDAP Name field.
  5. Enter a display label such as Kerberos Encryption Types in the Display Name field.
  6. Select Integer as the Data Type.
  7. Under Associated Reports, map it to User and Computer reports.
  8. Under Associated Management, map it to User Modification and Computer Modification so it appears as an editable field in management screens.
  9. Click Add to save the configuration.
Adding msDS-SupportedEncryptionTypes as a custom attribute in ADManager Plus.

Set or update for a single user

  1. Navigate to Management > User Management > Modify Single User.
  2. Search for and select the user account.
  3. Scroll to the Custom Attributes tab and locate Kerberos Encryption Types.
  4. Enter the decimal bitmask value (for example, 24 for AES128 + AES256).
  5. Click Update User to apply.

Bulk update via CSV

  1. Navigate to Management > Bulk User Modification > Custom Attributes.
  2. Enter msDS-SupportedEncryptionTypes in the LDAP Name field.
  3. Set Data Type to Integer.
  4. Enter the decimal bitmask value (for example, 24 for AES128 + AES256) in the Value field.
  5. Under Show Users List, select the domain and OU scope, then select CSV Import.
  6. Upload a CSV containing the sAMAccountName values of the accounts to update.
  7. Click Search, review the matched users, then click Apply.
Bulk updating msDS-SupportedEncryptionTypes via CSV import in ADManager Plus.

Report on encryption type configuration

  1. Navigate to Reports > Custom Reports and click + New Custom Report.
  2. Select User as the object type.
  3. Add Kerberos Encryption Types, sAMAccountName, Password Last Set, and Service Principal Names as columns.
  4. Optionally, apply a filter for accounts with SPNs set.
  5. Save and schedule the report for automated delivery.

Delegate encryption type management to non-admins

To allow a security team member to view and update encryption type settings for service accounts without broader AD write access, use help desk delegation:

  1. Navigate to Delegation > Help Desk Roles and click + Create New Role.
  2. Enter a Role Name and Description.
  3. Under User Attribute Privileges, select Kerberos Encryption Types for both read and write access.
  4. Save the role and assign it to the operator, scoped to the relevant OU.

Security and access considerations

By default, msDS-SupportedEncryptionTypes is readable by all authenticated domain users, consistent with the general AD read model. Write access requires Domain Admin rights or delegated write permission on the attribute. Computer accounts are an exception: they hold write access to their own msDS-SupportedEncryptionTypes by default, which allows them to update the attribute automatically when Group Policy is applied.

  • Kerberoasting exposure: Leaving msDS-SupportedEncryptionTypes unset or including RC4_HMAC_MD5 on accounts with SPNs allows an attacker who can request a service ticket to receive an RC4-encrypted ticket. RC4 tickets can be cracked offline with a password recovery tool like Hashcat. Setting the attribute to 24 (AES128 + AES256) on all SPN-bearing accounts removes this attack surface. Service accounts with passwords set before 2008 may not have AES keys; reset the password after changing the attribute to ensure AES keys are generated.
  • DES removal in Windows Server 2025: DES encryption types (DES_CBC_CRC and DES_CBC_MD5) are removed entirely from Windows Server 2025. Any account with a DES-only bitmask or the USE_DES_KEY_ONLY flag set in userAccountControl will fail Kerberos authentication against a Server 2025 DC. Audit for DES-only accounts before introducing Server 2025 DCs into the domain.
  • November 2022 update behavior change: CVE-2022-37966 changed how the KDC handles accounts with null or 0 msDS-SupportedEncryptionTypes. Accounts that previously received RC4 tickets by default may now receive AES-encrypted tickets or fail authentication if the client does not support AES. Explicitly setting the attribute on all accounts eliminates reliance on the patched-DC defaults and ensures consistent behavior across DC versions.
  • AES session key enforcement: Adding bit 0x20 (value 32) to the bitmask enables AES256_CTS_HMAC_SHA1_96_SK, which instructs the KDC to issue AES session keys even when the service ticket itself is RC4-encrypted. This is a transitional hardening step for environments that cannot yet eliminate RC4 service tickets entirely.
  • Auditing changes: Changes to msDS-SupportedEncryptionTypes generate a Directory Service Change event (Event ID 5136) when Directory Service Changes auditing is enabled. Monitor for unexpected changes on privileged accounts and service accounts, as weakening the encryption type (for example, re-adding RC4 after it has been removed) is a potential indicator of credential-access preparation.

Troubleshooting

  1. Authentication to a service fails with KDC_ERR_ETYPE_NOTSUPP after setting AES-only.

    The client or the service host does not support AES. Check the operating system version on the client and the service host. Windows XP and Server 2003 do not support AES. Temporarily add RC4 back to the account's bitmask to restore connectivity, then migrate the legacy system or decommission it before removing RC4 again.

  2. Computer account's msDS-SupportedEncryptionTypes reverts after every Group Policy refresh.

    A GPO setting (Network security: Configure encryption types allowed for Kerberos) is overriding the manually set value. The computer account updates the attribute to match its GPO-configured encryption types when it processes policy. Either align the PowerShell value with the GPO or manage the attribute exclusively through the GPO to avoid the conflict.

  3. Service tickets are still RC4-encrypted even though msDS-SupportedEncryptionTypes is set to 24.

    Check two things: first, whether the account's password was set before 2008. Passwords set before Windows Server 2008 do not have AES key material. Reset the service account's password after changing the attribute to generate AES keys. Second, check the DC patch level. On unpatched DCs the November 2022 behavior change is not present and the KDC may still issue RC4 tickets under certain conditions.

  4. Get-ADUser returns null for msDS-SupportedEncryptionTypes.

    The attribute is unset on that account. A null value means the KDC will use its domain default (post-November 2022 update: an RC4 service ticket with AES256 session keys, if DefaultDomainSupportedEncTypes is not configured on the DC). Set the attribute explicitly to remove reliance on DC-level defaults.

  5. msDS-SupportedEncryptionTypes is set to 0 on the KRBTGT account.

    This is by design and is not a problem. The KDC ignores msDS-SupportedEncryptionTypes on the KRBTGT account entirely. TGT encryption is determined by the KRBTGT account's key material and the domain functional level, not by this attribute. Do not attempt to set a non-zero value on KRBTGT for this purpose.

  6. Accounts fail authentication on Windows Server 2025 DCs after upgrading.

    Check for accounts with the USE_DES_KEY_ONLY flag set in userAccountControl, or accounts with msDS-SupportedEncryptionTypes set to a DES-only value. DES was removed from Windows Server 2025. Run Get-ADUser -Filter 'UserAccountControl -band 2097152' to find all accounts with the DES-key-only flag, and update both userAccountControl and msDS-SupportedEncryptionTypes before promoting Server 2025 DCs.

  • msDS-KeyVersionNumber: The Kerberos Key Version Number (KVNO) for an account. Increments on each password change. Directly related to msDS-SupportedEncryptionTypes because changing encryption types without resetting the password can leave stale key material.
  • servicePrincipalName: The SPNs registered to an account. msDS-SupportedEncryptionTypes only meaningfully affects Kerberos behavior for accounts that have at least one SPN, since the KDC only reads it when issuing a service ticket for that account.
  • userAccountControl: Contains the USE_DES_KEY_ONLY flag (0x200000) that forces DES encryption regardless of msDS-SupportedEncryptionTypes. Must be cleared before AES-only policy can take effect.
  • pwdLastSet: Timestamp of the last password change. Accounts with pwdLastSet predating 2008 may not have AES keys even if msDS-SupportedEncryptionTypes is set to AES-only. A password reset is required to generate AES key material.
  • sIDHistory: Relevant in cross-domain Kerberos scenarios where msDS-SupportedEncryptionTypes on trust objects controls inter-realm ticket encryption.

Manage msDS-SupportedEncryptionTypes and every AD attribute from one console

ADManager Plus gives you centralized control over Kerberos encryption type configuration, service account reporting, and bulk remediation for RC4 deprecation, without requiring Domain Admin rights for every task. You can view, set, and audit msDS-SupportedEncryptionTypes values across your entire user and computer base from a single web-based console.

Frequently asked questions

For service accounts with SPNs: 24 (0x18), which enables AES128 and AES256 and disables RC4 and DES.

For environments that need to enforce AES session keys alongside any remaining RC4 service tickets: 56 (0x38).

For user accounts without SPNs, the attribute has no effect on Kerberos and can be left unset.

No. The KDC only reads msDS-SupportedEncryptionTypes on the target account of a TGS-REQ, which is the account that owns the SPN the client is requesting a service ticket for. Accounts without SPNs are never the target of a TGS-REQ, so the attribute has no effect on their Kerberos ticket encryption.

Before the November 2022 security update, the KDC assumed RC4 for backward compatibility. After the update, the KDC uses the value of the DefaultDomainSupportedEncTypes registry key on the DC if it is set, or defaults to an RC4 service ticket with AES256 session keys if it is not. Explicitly setting the attribute on all accounts removes this dependency on DC-level defaults and patch state.

The KDC intentionally ignores this attribute on the KRBTGT account. TGT encryption is determined by the KRBTGT account's embedded key material and the domain functional level, not the attribute. This is by design and is not a misconfiguration.

No. msDS-SupportedEncryptionTypes is a single value that applies to all SPNs registered on the account. If different encryption requirements are needed for different services, those services should use separate accounts, each with its own attribute configuration.

No. This is an on-premises AD DS attribute and is not synchronized to Microsoft Entra ID by Microsoft Entra Connect. Kerberos encryption type configuration in Entra ID is managed separately through the Entra Kerberos infrastructure and Entra ID settings.

The SK suffix stands for "Session Key." Enabling this bit (value 32) instructs the KDC to issue AES256 session keys even in cases where the service ticket itself is still RC4-encrypted. This is a transitional control introduced to allow organizations to harden session key encryption without immediately eliminating all RC4 service ticket issuance. It was particularly relevant post-November 2022 update.

Manage msDS-SupportedEncryptionTypes and any AD attribute at scale with ADManager Plus

The one-stop solution to Active Directory Management and Reporting
Email Download Link Email the ADManager Plus download link