How to remediate – AD Starter Scan – Weak Kerberos encryption

1. Introduction

AD Starter Scan identifies weak Kerberos encryption configurations, specifically the use of DES. This matters because DES is a deprecated and insecure algorithm that can be easily cracked, potentially allowing attackers to compromise Active Directory accounts. Systems affected are typically those with older user accounts still configured with legacy settings. A successful exploit could lead to confidentiality, integrity, and availability loss.

2. Technical Explanation

Active Directory uses Kerberos for authentication. Older versions of Kerberos support DES encryption due to historical limitations. While modern configurations default to stronger algorithms like AES, some legacy accounts may still be configured with DES. An attacker could exploit this by attempting to authenticate using a user account with weak Kerberos settings and then cracking the DES-encrypted ticket.

• Root cause: The Kerberos protocol is configured to use the DES algorithm for encryption on a user account.
• Exploit mechanism: An attacker attempts to authenticate with an affected account, captures the Kerberos ticket, and cracks the DES encryption offline using tools like Hashcat or John the Ripper.
• Scope: Active Directory environments, particularly those with older accounts or incomplete security hardening.

3. Detection and Assessment

You can confirm a vulnerable system by checking account settings in Active Directory Users and Computers (ADUC) or using command-line tools. Scanning tools like Nessus can also identify this vulnerability.

• Quick checks: In ADUC, check the “Account options” for an account. If “Do not require Kerberos preauthentication” is enabled, investigate further for encryption type.
• Scanning: Nessus plugin ID 14c411d0 can identify weak Kerberos configurations. This is intended for smaller deployments (up to 5000 users).
• Logs and evidence: Security logs may show authentication attempts using DES, but this requires careful analysis.

klist tickets -f # Lists Kerberos tickets, look for encryption type.

4. Solution / Remediation Steps

The Kerberos protocol should not be configured to use the DES algorithm. Update user account settings to enforce stronger encryption algorithms.

4.1 Preparation

• No services need to be stopped for this change, but plan during off-peak hours.
• Roll back: If issues occur, restore the Active Directory backup or revert the account settings. A change window may be required depending on organizational policy.

4.2 Implementation

1. Step 1: Open Active Directory Users and Computers (ADUC).
2. Step 2: Locate the user account with weak Kerberos encryption.
3. Step 3: Right-click the account and select “Properties”.
4. Step 4: Go to the “Account” tab.
5. Step 5: Ensure “Do not require Kerberos preauthentication” is *disabled*.
6. Step 6: If enabled, disable it and apply changes. This will force stronger encryption algorithms during authentication.

4.3 Config or Code Example

Before

Account options: Do not require Kerberos preauthentication - Enabled

After

Account options: Do not require Kerberos preauthentication - Disabled

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege limits the impact of compromised accounts. Regular security audits identify and remediate weak configurations. Patching ensures systems are up-to-date with the latest security fixes.

• Practice 1: Least privilege reduces the potential damage from a compromised account using DES.

4.5 Automation (Optional)

PowerShell can automate this process, but use caution when modifying Active Directory settings at scale.

# Example PowerShell script - Use with extreme care!
Get-ADUser -Filter 'DoNotRequirePreAuth -eq $true' | Set-ADUser -DoNotRequirePreAuth $false

5. Verification / Validation

Confirm the fix by rechecking account settings in ADUC and verifying that accounts no longer allow weak Kerberos encryption. Test authentication with a user account to ensure it functions correctly.

• Post-fix check: In ADUC, verify “Do not require Kerberos preauthentication” is disabled for the affected account.
• Re-test: Run Nessus plugin ID 14c411d0 again; it should no longer report the vulnerability.
• Smoke test: Log in to a system with the updated user account to confirm authentication works as expected.
• Monitoring: Review security logs for failed Kerberos authentications, which could indicate issues with the change.

klist tickets -f # Lists Kerberos tickets, verify encryption type is no longer DES.

6. Preventive Measures and Monitoring

Update your security baselines to enforce strong Kerberos encryption algorithms. Implement regular scans to identify misconfigured accounts. Review patch management processes to ensure timely updates.

• Baselines: Update Group Policy or Intune settings to disable “Do not require Kerberos preauthentication” for all user accounts.
• Asset and patch process: Review Active Directory configuration regularly (e.g., quarterly) as part of a broader security audit.

7. Risks, Side Effects, and Roll Back

Disabling “Do not require Kerberos preauthentication” may cause compatibility issues with older systems that do not support modern Kerberos features. If this occurs, restore the original setting or identify and update affected systems.

• Risk or side effect 1: Compatibility issues with legacy systems. Mitigation: Identify and update those systems if possible; otherwise, consider a phased rollout.
• Roll back: Re-enable “Do not require Kerberos preauthentication” in ADUC for the affected account(s).

8. References and Resources

• Vendor advisory or bulletin: https://www.tenable.com/blog/new-in-nessus-find-and-fix-these-10-active-directory-misconfigurations
• NVD or CVE entry: Not applicable for this specific configuration issue.
• Product or platform documentation relevant to the fix: https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication