Uncategorized

Network Security Configure Encryption Types Allowed for Kerberos

Reading time: 5 Minutes Read
Ben Balkin
Published on: May 13, 2024
Network Security Configure Encryption Types Allowed for Kerberos

What is Kerberos and encryption types?

The ability to authenticate securely over an unsecure network is paramount in safeguarding sensitive information and maintaining trust in digital interactions. In an era where communication often occurs over public networks like the internet, ensuring the authenticity of users and data is critical to prevent unauthorized access and data breaches.

Kerberos is a Windows security network authentication protocol that allows users and services to securely authenticate over a non-secure network. It works by issuing kerberos tickets to users, which they can present to services to prove their identity without transmitting their passwords over the network.

Network security: Configure encryption, allows administrators to specify which of these encryption types are allowed to be used by Kerberos. By default, Windows allows several encryption types, but in some cases, it might be necessary to restrict this list for security reasons.

Encryption types supported by Kerberos

With Kerberos there are six available encryption types, ranging from legacy encryptions like DES_CBC_CRC and AES encryption, to unknown future encryption types as shown in the table below:

Encryption typeStateNotes
DES_CBC_CRC(Disabled by default)Weak encryption, no longer considered secure due to its short key size.
DES_CBC_MD5(Disabled by default)Weak encryption with known vulnerabilities.
RC4_HMAC_MD5(Proceed with caution)While some legacy applications might require it, RC4 has weaknesses and should be disabled if possible.
AES128_HMAC_SHA1(Recommended)Strong and widely supported option for Kerberos encryption.
AES256_HMAC_SHA1(Recommended)Offers the highest level of security among currently supported options.
Future encryption types Allows for automatic adoption of stronger encryption methods as they become available.

 

Compatibility considerations

The strength of each encryption algorithm varies from one to the next, choosing stronger algorithms will reduce the risk of compromise however doing so may cause issues when the computer attempts to authenticate with systems that do not support them.

When deciding which encryption types to allow, it is important to evaluate the benefits and weaknesses of each to find a balance necessary for each specific system’s needs.

Choosing strong encryption (AES) enhances security but might cause compatibility issues with older clients or servers that don’t support it. However, Some legacy applications might rely on weaker encryption types like RC4. Disabling it can lead to authentication failures until those applications are updated or replaced.

It is also important to consider cross domain trust, both domains must support the same chosen encryption types in order to  avoid communication issues.

The stronger the encryption, the more secure the system will be, in lieu of compatibility. The weaker the encryption, the less secure a system is, but it will be compatible with a larger range of systems, for example legacy systems which might only have the option of using older DES or RC4 encryptions.

Legacy Protocols:Hiding in Plain Site See how to uncover and eliminate NTLM and similar risks.

See the Whitepaper

Impact of not selecting the correct encryption types

If not selected, the encryption type will not be allowed. This setting ‘network security configure encryption types allowed for kerberos’  may affect compatibility with client computers or services and applications. Multiple selections are permitted.

Note: Some legacy applications and OSes may still require RC4_HMAC_MD5 – we recommend you test in your environment and verify whether you can safely remove it.

Note #2: Windows Server 2008 (non-R2) and below allow DES for Kerberos by default, but later OS versions do not.

Note #3: Some prerequisites might need to be met on Domain Controllers to support Kerberos AES 128 and 256 bit encryption types, as well as enabling support for Kerberos AES 128 and 256 bit on user accounts (in account options) for this recommendation to work correctly.

Note #4: If your organization uses Azure Files, please note that Microsoft did not introduce AES 256 Kerberos encryption support for it until AD DS authentication module v0.2.2. Please see this link for more information:

Azure Files on-premises AD DS Authentication support for AES 256 Kerberos encryption

Vulnerability of attacks against Kerberos

In 2022, CVE-2022-37966 allowed for security bypass and elevation of privilege by exploiting accounts using outdated encryption types (such as DES or RC4) for session keys during authentication.

If computer configuration encryption types allowed for kerberos is set too lax, it can weaken the security posture of a system. This can be done in a number of ways, including:

  • Weak Encryption Algorithms: Allowing outdated or weak encryption algorithms such as DES or RC4 can make the Kerberos authentication vulnerable to exploits by attackers trying to decrypt authentication data.
  • Cryptographic Downgrade Attacks: If a network allows multiple encryption types but doesn’t prioritize stronger algorithms, attackers could potentially force the use of weaker encryption by intercepting and modifying network traffic.
  • Brute Force Attacks: Allowing encryption types with shorter key lengths increases the risk of brute force attacks, where attackers attempt to guess the encryption key by trying all possible combinations.

How to correctly set Network Security: Configure Encryption Types Allowed for Kerberos

To establish the recommended configuration windows settings security via GP, set the following UI path to AES128_HMAC_SHA1, AES256_HMAC_SHA1, Future encryption types:

Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity OptionsNetwork security: Configure encryption types

Default Value

RC4_HMAC_MD5, AES128_HMAC_SHA1, AES256_HMAC_SHA1, Future encryption types.

Recommended state

The recommended state for this setting is: AES128_HMAC_SHA1,AES256_HMAC_SHA1, Future encryption types.

Note: Some legacy applications and OSes may still require RC4_HMAC_MD5 – we recommend you test in your environment and verify whether you can safely remove it.

 

How to plan and manage a hardening project. Read our exclusive guide to get ahead

Learn More

Best practices for securing a system

It is paramount to ensure the security and compatibility of a system, therefore hardening a server is recommended to maintain a secure authentication environment, especially in environments where sensitive data and resources are accessed.

By having Kerberos correctly configured, IT professionals can ensure that only approved and secure encryption algorithms are used within their Kerberos authentication infrastructure, thereby enhancing the overall security posture of their network.

Ben Balkin
Ben Balkin is a professional writer and blogger specializing in technology and innovation. As a contributor to the Calcom blog, Ben shares practical insights, useful tips, and engaging articles designed to simplify complex processes and make advanced technological solutions accessible to everyone. His writing style is clear, insightful, and inspiring, reflecting his strong belief in technology's power to enhance quality of life and empower businesses.

Related Articles

About Us

Established in 2001, CalCom is the leading provider of server hardening solutions that help organizations address the rapidly changing security landscape, threats, and regulations. CalCom Hardening Suite (CHS) is a security baseline hardening solution that eliminates outages, reduces operational costs, and ensures a resilient, constantly hardened, and monitored server environment.

More about us
Background Shape
About Us

Stay Ahead with Our Newsletter

Get the latest insights, security tips, and exclusive resources straight to your inbox every month.

    Ready to simplify compliance?

    See automated compliance in action—book your demo today!