Kerberos_hardening_and_maintenance

THIS IS A WORK IN PROGESS

This is based on my limited understanding of Kerberos and if you should find any errors / mistakes or otherwise disagree with anything written here, please create an issue about it.

Encryption

• Encryption types
• RFC 8009: AES Encryption with HMAC-SHA2 for Kerberos 5
• Set allow_weak_crypto to false
• aes256-cts-hmac-sha384-192 seems to be the best available and should be preferred
• Kerberos 5 Release 1.21.2:
  • "The KDC will no longer issue tickets with RC4 or triple-DES session keys unless explicitly configured with the new allow_rc4 or allow_des3 variables respectively."
  • "The KDC will assume that all services can handle aes256-sha1 session keys unless the service principal has a session_enctypes string attribute."
• Changing the krbtgt key: "it can be important for the krbtgt service to support multiple encryption types"

Salts

Keysalt lists

Cryptographic salts should be random and the normal (which is the default) is not as it consists of the principal name combined with the realm. You should use special to use a random salt.

Attributes

Kerberos ticket properties

requires_preauth

• Addressing dictionary attack risks
• MITRE ATT&CK T1558.004: "Adversaries may reveal credentials of accounts that have disabled Kerberos preauthentication by Password Cracking Kerberos messages."
• Principals: "User principals should usually be created with the +requires_preauth -allow_svr options to help mitigate dictionary attacks."
• Preauth is less important for generated/randomized (e.g. not password based) keys, as those should be unfeasible to crack with brute-force when strong encryption is ensured
• Preauth also enables you to see failed authentications in the logs and in the KDB
• RFC 6113: A Generalized Framework for Kerberos Pre-Authentication

allow_svr

Configuring account lockout: "It is also important to set the -allow_svr flag on a principal to protect its password from an off-line dictionary attack through a TGS request."

You can test this with kinit -S and you should receive the following response:

kinit: Server principal valid for user2user only while getting initial credentials

Forwardable and proxiable

If you don't have a specific need for forwarding or proxying, you should set the disallow_forwardable and disallow_proxiable attributes for principals.

disallow_tgt_based

You should set this attribute to all /admin principals.

lockdown_keys

• This is set by default upon DB creation on certain sensitive principals
• Kerberos 5 Release 1.15.5: "Add a lockdown_keys principal attribute to prevent retrieval of the principal's keys (old or new) via the kadmin protocol. In newly created databases, this attribute is set on the krbtgt and kadmin principals."

When you create the Kerberos DB with kdb5_util create, the following principals will have this attribute:

• K/M
• kadmin/admin
• kadmin/changepw
• krbtgt

If you have created your DB with Kerberos version older than commit ac2b693, the kadmin/HOST principal will also have the lockdown_keys attribute.

disallow_dup_skey

• "-allow_dup_skey disables user-to-user authentication for this principal by prohibiting this principal from obtaining a session key for another user."
• You should set this for regular user principals

KDC configuration

• SPAKE Preauthentication: "By default, SPAKE with the edwards25519 group is enabled on clients, but the KDC does not offer SPAKE by default."

restrict_anonymous_to_tgt

• Enabling anonymous: "If the WELLKNOWN/ANONYMOUS@REALM principal exists then anonymous authentication is supported. No special considerations are made to prohibit changing the password of this principal. As a result, it may be possible for an attacker to change the password of this principal and perform anonymous authentication without actually using pkinit."
• Introduced in commit 9479352

When you set restrict_anonymous_to_tgt in the KDC, acquire an anonymous ticket with kinit -n and try to change it's password with kpasswd the KDC refuses the request with ANONYMOUS NOT ALLOWED: WELLKNOWN/ANONYMOUS@REALM for kadmin/changepw@REALM, KDC policy rejects request.

Policy

You should define and use some sensible policy and make sure it is enabled for principals.

Key rotation

• Migrating away from older encryption types
  • "Check the kadmin/history principal, which should have only one key entry."
• Changing the krbtgt key
  • The documentation states that "The key for this principal is created when the Kerberos database is initialized and need not be changed.", but surely key rotation is better for security. A stolen krbtgt is used to create golden tickets (T1558.001).
• Updating the history key
• Updating the master key

Backups

• Backups of secure hosts: "When you back up a secure host, you should exclude the host’s keytab file from the backup. If someone obtained a copy of the keytab from a backup, that person could make any host masquerade as the host whose keytab was compromised."
• Backing up the Kerberos database: "MIT recommends that you back up your Kerberos database regularly."
  • Dumping and loading a Kerberos database

Debugging

To debug Kerberos stuff, set the environment variable KRB5_TRACE to /dev/stdout.

References

CIS MIT Kerberos Benchmark