Step by step guide: Kerberos Hardening (KB5073381)

Initial Steps

1. List user, computer, or service accounts with at least one SPN and an empty msDS-SET attribute.

2. List computers with a numeric OperatingSystemVersion less than 6. These computers will not use the msDS-SET field.

3. Collect events 4768 and 4769 to obtain RC4 usage (etype 0x17) in both the ticket and session key. If possible, use SIEM tools. In small environments, you can also use the official scripts Get-KerbEncryptionUsage.ps1 and List-AccountKeys.ps1.

4. Install the January cumulative update on domain controllers. This update enables auditing, which will help us anticipate problems with the implementation of hardening.

5. Obtain events 201, 202, 206, and 207 on domain controllers. These will alert us to encryption problems on client computers and/or service accounts. Obtain event 205 or check that the DefaultDomainSupportedEncTypes registry key is not created on any domain controller. If it is created, understand its value and consider setting it to 0x18 (AES only) in the future.

Inform account’s reponsibles

With all the audit data now available, we can start informing the responsibles of accounts that may be affected. We will inform them all when the hardening process will be enforced and propose an earlier date to migrate or correct their accounts beforehand:

• Services with SPN and without msDS-SET: Migrate your services to AES with msDS-SET set to 24.

• Devices with OperatingSystemVersion lower than 6: Clear this attribute and set msDS-SET to 24.

• Devices without AES support (msDS-SET lower than 8): If they are Windows, check the Kerberos GPO to enable AES. If they are Linux, we recommend reviewing installed modules.

• Events 201 and 206: Notify the machine owners (check the Client Address IP) that they are using RC4. We can check in Active Directory if the machine's msDS-SET is configured to not support AES or if it has an OperatingSystemVersion of 5 or lower. We can also use event 4769 to see if there are other AES tickets issued for that machine. It's possible that only one application, and not the entire machine, does not support AES. In this case, the machine administrators should review Kerberos-related configurations (e.g., krb5.conf).

• Events 202 and 207: It is necessary to check if the service accounts are compatible with AES, if the services need to be configured to use it (keytab), and to reset the password.

Pre-Hardening

The ideal situation before starting hardening tasks is:

• January’s or later cumulative update installed on all DCs.

• No events 201, 202, 206, or 207 in the last 7-14 days.

• No tickets or session keys in RC4 (etype 0x17) in events 4768 and 4769 from the last 7-14 days.

• The DefaultDomainSupportedEncTypes registry key does not exist or has a value of 0x18 or similar.

• All accounts with SPN already support AES in msDS-SET.

• All computers support AES via GPO and msDS-SET.

• No computers have an OperatingSystemVersion lower than 6, or if any exist, they are all AES-compatible, and we verified their AES usage in events 4768-4769.

Progressive hardening

To minimize the impact, we can opt for a phased hardening approach, gradually performing each action with 7-14 days between each one, to assess potential effects. It's best to create registry keys via a Group Policy Object (GPO) on the Domain Controllers Organizational Unit (OU).

1. Create the DefaultDomainSupportedEncTypes registry key with a value of 0x18 (24) on the domain controllers. If anything goes wrong, use the same Group Policy Object (GPO) to override the change and either delete the registry key or revert to the previous value.

2. If everything goes well, create the registry key RC4DefaultDisablementPhase with a value of 2 (forced) on the domain controllers. If anything goes wrong, use the same GPO with a value of 1 (auditing).

3. If everything continues to go well, there is no longer any risk. We can proceed to install the April cumulative update on the domain controllers, which should not have any impact.

4. If there are still no problems, install the July cumulative update on the domain controllers. After this point, there is no going back.