From RC4 to AES — What Actually Changes and What You Must Fix Now
🔥 Why This Matters (No Marketing, Just Reality)
Kerberos is quietly going through one of the most important security shifts in years:
RC4 is dying. AES is becoming the default.
This is not just a “nice security improvement”.
This will:
-
break legacy configurations
-
expose weak AD setups
-
surface misconfigured service accounts
-
create authentication failures in real environments
If you run Active Directory, this affects you. Period.
⚙️ Kerberos Encryption — What’s Changing
Supported Encryption Types
| Encryption | Status | Risk Level | Notes |
|---|---|---|---|
| RC4-HMAC | ❌ Deprecated | 🔴 High | Weak, widely abused in attacks |
| AES128 | ⚠️ Transitional | 🟡 Medium | Better, but not ideal |
| AES256 | ✅ Recommended | 🟢 Low | Strong default moving forward |
💣 Why RC4 Is a Problem
RC4 is not just “old”.
It is:
-
fast to crack
-
widely used in Kerberoasting attacks
-
often enabled on service accounts by default
👉 If RC4 is enabled, attackers can:
-
request service tickets
-
extract hashes
-
crack them offline
Game over for that account.
🔍 Where RC4 Still Hides
Even if you think “we don’t use RC4 anymore” — you probably do.
Common places:
-
Service accounts (SPNs)
-
Legacy applications
-
Old domain functional levels
-
Misconfigured GPOs
-
Third-party integrations
🧪 How to Check Your Environment
1. Check user encryption types
2. Check service accounts (critical)
3. Identify RC4 usage via logs
Look for:
-
Event ID 4769
-
Encryption type: 0x17 (RC4)
🧰 Kerberos Flow (Simplified)
Client → KDC → Service
1. Client requests TGT
2. KDC issues ticket (encryption matters here)
3. Client requests service ticket
4. Service validates ticket
👉 Weak encryption anywhere in this chain = attack surface.
✅ Hardening Checklist (Do This)
🔐 Encryption
-
Disable RC4 where possible
-
Enforce AES256
-
Audit msDS-SupportedEncryptionTypes
👤 Service Accounts
-
Rotate passwords
-
Remove legacy SPNs
-
Ensure AES support
🖥️ Domain Configuration
-
Raise domain functional level (if outdated)
-
Review Kerberos policies
-
Validate GPO settings
📊 Monitoring
-
Track Event ID 4769
-
Detect RC4 usage
-
Alert on unusual ticket patterns
⚠️ What Will Break
Be honest — things WILL break.
Typical issues:
| Scenario | Impact |
|---|---|
| Legacy apps | Authentication failure |
| Old service accounts | No ticket issuance |
| Hardcoded configs | Silent failures |
| Third-party systems | Compatibility issues |
🧠 Real-World Scenario
If you have:
-
500+ endpoints
-
legacy apps
-
mixed domain configs
👉 You will not “just switch to AES”.
You will:
-
discover broken services
-
troubleshoot authentication failures
-
fix configs one by one
This is not a toggle.
This is a migration.
🚀 Migration Strategy
Phase 1 — Discovery
-
Identify RC4 usage
-
Map dependencies
Phase 2 — Testing
-
Test AES-only configs
-
Validate critical apps
Phase 3 — Enforcement
-
Disable RC4
-
Enforce AES
Phase 4 — Monitoring
-
Track authentication errors
-
watch logs continuously
🧨 Common Mistakes
-
“We disabled RC4, we’re safe”
-
Ignoring service accounts
-
Not checking logs
-
Breaking production systems
🧭 Final Thought
Kerberos is not changing overnight.
But attackers are already using:
-
RC4 weaknesses
-
service account misconfigs
-
weak encryption paths
👉 Moving to AES is not optional.
👉 It’s overdue.
🔗 Related Topics (Internal Links)
(вставишь потом свои ссылки)
-
Active Directory security
-
Kerberoasting
-
Entra ID vs AD
-
Identity-first security
🏁 TL;DR
-
RC4 = dead (but still everywhere)
-
AES256 = target state
-
migration = painful but necessary
-
ignoring this = security risk
💬 Want More?
If you’re working with:
-
Active Directory
-
Microsoft security
-
Identity & authentication
This blog is built exactly for those problems that appear after the vendor documentation ends.