When working with Windows Server 2012 R2 at the highest functional level, many administrators are surprised to find that Kerberos AES encryption isn't enabled by default for user accounts. This behavior persists even in modern environments without legacy compatibility requirements.

The Active Directory schema contains two critical attributes governing AES support:

msDS-SupportedEncryptionTypes (attribute ID: 1.2.840.113556.1.4.1789)
userAccountControl (UAC) flags

For AES to work, these values must be set appropriately:

AES128: UAC flag 0x200000 (TRUSTED_FOR_DELEGATION)
AES256: UAC flag 0x400000 (TRUSTED_TO_AUTH_FOR_DELEGATION)

Here's how to programmatically enable AES for all users via PowerShell:

# Enable both AES-128 and AES-256 for all users
Get-ADUser -Filter * | ForEach-Object {
    $current = $_.userAccountControl
    $new = $current -bor 0x600000
    if ($current -ne $new) {
        Set-ADUser $_ -UserAccountControl $new
    }
}

# Verify encryption types
Get-ADUser -Identity testuser -Properties msDS-SupportedEncryptionTypes | 
Select-Object Name, @{n='EncryptionTypes';e={$_.'msDS-SupportedEncryptionTypes'}}

While you can't enable AES per-user via GPO, you can enforce it through these policies:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options:
Network security: Configure encryption types allowed for Kerberos

The primary reasons for this default behavior include:

• Backward compatibility with systems predating Windows Server 2008
• Prevention of authentication failures in mixed environments
• Historical security policy favoring compatibility over stronger encryption

When implementing AES, watch for these common issues:

# Check effective Kerberos encryption with klist
klist get tickets

# Event Viewer logs to monitor:
Security logs with Event ID 4768 (Kerberos authentication)

While experimenting with Windows Server 2012 R2 in a test domain environment, I encountered a puzzling behavior: despite operating at the highest functional level with no backward compatibility constraints, Kerberos AES encryption wasn't automatically enabled for any Active Directory user accounts. This became evident when adding test accounts to the "Protected Users" group, which mandates AES encryption - suddenly all network logins started failing.

Windows Server supports multiple Kerberos encryption types:

# Common Kerberos encryption types in order of security:
1. AES256-CTS-HMAC-SHA1-96 (most secure)
2. AES128-CTS-HMAC-SHA1-96  
3. RC4-HMAC (deprecated, vulnerable)
4. DES-CBC-MD5 (obsolete)

Microsoft intentionally doesn't enable AES by default due to:

• Legacy system compatibility (though this shouldn't affect my test environment)
• Potential performance impact on older hardware (AES is more CPU-intensive)
• Historical deployment patterns (RC4 was default for decades)

To enable AES for all users via PowerShell:

# Enable both AES-128 and AES-256 for all users
Get-ADUser -Filter * | ForEach-Object {
    Set-ADAccountControl -Identity $_.DistinguishedName 
        -KerberosEncryptionType "AES128","AES256"
}

# Verify settings for specific user
Get-ADUser username -Properties msDS-SupportedEncryptionTypes | 
    Select-Object Name, msDS-SupportedEncryptionTypes

For enterprise-wide deployment, configure via GPO:

1. Navigate to: Computer Configuration → Policies → Windows Settings → 
   Security Settings → Local Policies → Security Options
2. Set "Network security: Configure encryption types allowed for Kerberos" to:
   - AES256_HMAC_SHA1
   - AES128_HMAC_SHA1

The manual checkbox approach (through ADUC → Account → Account Options) becomes problematic because:

• It's not scalable for large environments
• Newly created users inherit domain defaults (no AES)
• Automation via PowerShell/API becomes necessary

To confirm AES is being used for Kerberos:

# Check Kerberos tickets with klist
klist get krbtgt

# Look for encryption type in output:
# Encryption Type: AES-256-CTS-HMAC-SHA1-96