Ausgangslage: Kerberos ist Standard — und trotzdem oft „weich“ konfiguriert
In AD-Umgebungen ist Kerberos der Normalfall. Genau deshalb wird es in Projekten gern als „läuft doch“ behandelt. In der Praxis sieht man aber häufig:
- uneinheitliche Client-Versionen und Altlasten in Applikationen,
- heterogene Kerberos-Policy (Verschlüsselung, Ticket-Lifetimes, Ausnahmen),
- viele Tier-0 Logons über unsaubere Wege (RDP, WinRM, Jump Hosts ohne klare Hygiene),
- und Kerberos-Preauth als „gegeben“ statt als harte Sicherheitskontrolle.
Kerberos Armoring (auch FAST – Flexible Authentication Secure Tunneling) adressiert einen konkreten Teil davon: die Absicherung der Pre-Authentication und der frühen Kerberos-Dialoge gegen bestimmte Offline- und Downgrade-Pfade. Es ist kein Allheilmittel — aber ein sehr sinnvolles Hardening-Bauteil, wenn die Voraussetzungen stimmen.
Zielbild: FAST verfügbar, messbar, in Wellen durchgesetzt
Ein brauchbares Zielbild ist nicht „Häkchen setzen“, sondern:
- KDCs (Domain Controller) und Clients unterstützen FAST und sind konsistent konfiguriert.
- Rollout ist staged: Pilot → Wave 1 → Wave 2, mit klaren Gates.
- Abhängigkeiten sind bekannt (Kerberos-Client-Stacks, Third-Party SSO, Appliances, Legacy Apps).
- Es gibt einen Rollback pro Scope (OU/Device-Gruppen), ohne das Programm zu stoppen.
- Wir können nachweisen: wer nutzt FAST, wer nicht, und warum.
Das Ziel ist maximale Wirkung bei minimaler Ausfallwahrscheinlichkeit.
Was FAST konkret schützt (und was nicht)
FAST „verpackt“ Kerberos-Preauth in einen zusätzlich geschützten Kanal (Armor), typischerweise mit einem Armor-Key aus einem Kerberos-Ticket (z. B. TGT) oder über einen Preauth-Mechanismus, der das Offline-Risiko reduziert.
Pragmatischer Nutzen in Projekten:
- reduziert die Angriffsfläche für bestimmte Offline-Angriffe auf Preauth-Daten,
- erschwert „weichere“ Kerberos-Flows, wenn Clients/KDCs sauber aufgestellt sind,
- verbessert die Basis für weitere Kerberos-Härtung (z. B. saubere AES-Only Roadmaps).
Wichtig:
- FAST ersetzt weder Tiering, noch Credential Hygiene, noch saubere E2E TLS-Story an anderer Stelle.
- Wenn Admins weiterhin auf beliebigen Endpoints arbeiten, bleibt das Gesamtrisiko hoch — FAST ist dann nur ein Baustein.
Voraussetzungen: bevor du „Enforce“ denkst
FAST ist kein guter Kandidat für „einfach mal domainweit“. Prüfe vorab:
1) Plattform-Basis
- Domain Controller: Versionen und Patch-Level konsistent (keine „Sonder-DCs“).
- Clients/Server: ausreichend modern in den OUs, die du zuerst härtest (Tier-0/Tier-1 zuerst).
- Kerberos-Verschlüsselung: AES ist Standard und RC4-Ausnahmen sind identifiziert (FAST profitiert von einer sauberen Crypto-Story).
2) Abhängigkeiten und „schwierige“ Kerberos-Clients
Typische Problemkandidaten:
- Appliances/VPN-Gateways mit eingebautem Kerberos-Stack,
- ältere Java/.NET Libraries in Legacy Apps,
- Drittanbieter-SSO/IdM/PAM-Komponenten, die Kerberos ungewöhnlich nutzen,
- Umgebungen mit vielen SPNs und historischen Sonderkonfigurationen.
Hier entscheidet sich meist, ob FAST eine schnelle Hardening-Welle wird — oder ein Wochenend-Feuer.
3) Telemetrie: du brauchst Signale, nicht Bauchgefühl
Plane vor Rollout, wie du Fehler siehst:
- Security/Directory-Service Logs auf DCs (Kerberos-/KDC-Fehlerbilder),
- Monitoring auf Login-/Service-Ausfälle (VPN, Fileserver, RDS, Web-SSO),
- Tickets für Applikationsverantwortliche: Welche Systeme authentifizieren wie?
Umsetzung: Rollout in drei Stufen
Stufe 1: „Supported“ in einem Pilot-Scope
Pilot bedeutet: eine OU mit wenigen, aber relevanten Systemen (z. B. Admin-Workstations oder ein kleiner Satz Tier-1 Server), plus definierte Testfälle:
- interaktives Admin-Login,
- Zugriff auf Dateifreigaben,
- Zugriff auf zentrale Applikationen,
- geplante Tasks/Services mit Service-Accounts,
- Kerberos-authentifizierte WinRM/Remote-Management-Flows.
Konfiguriere FAST zunächst als unterstützt (nicht erzwungen), und sammle Signale.
Stufe 2: Wave 1 für Tier-0 / Tier-1
Wenn der Pilot sauber ist, erweitere:
- Tier-0 (DCs, Admin-Endpoints, Jump Hosts),
- dann Tier-1 (Server, auf denen Admin-Logons real stattfinden).
Fokus: hoher Sicherheitsnutzen, überschaubare Client-Vielfalt, gute Ownership.
Stufe 3: Enforce — nur wenn die Backlog-Liste klein ist
Erzwingung macht nur Sinn, wenn:
- die verbleibenden Ausnahmen sauber dokumentiert sind,
- es einen akzeptierten Plan für Legacy-Systeme gibt,
- Rollback pro OU/Scope getestet ist.
Wenn du „Enforce“ zu früh setzt, bekommst du einen Auth-Blackout — und das Projekt verliert Vertrauen.
Vorteile und Nachteile (explizit, ohne Wunschdenken)
Vorteile
- Erhöht die Resilienz der Kerberos-Preauth gegen bestimmte Offline-/Downgrade-Pfade.
- Verbessert die Grundlage für weitere Kerberos-Härtung (AES-Only, konsistente Policy).
- Passt gut in ein Tier-0 Programm, weil Scope sauber steuerbar ist.
Nachteile / Grenzen
- Kompatibilität ist der Engpass: Legacy-Kerberos-Clients sind das Risiko, nicht die DCs.
- FAST ist nicht „sichtbar“ für Nutzer — der Mehrwert muss über messbare Security-Ziele erklärt werden.
- Erzwingung ohne Ownership/Backlog führt zu Ausfällen (und oft zu Rückrollen auf „Disabled“).
Typische Stolperfallen (die ich in Projekten regelmäßig sehe)
- Kein Inventar: „Wir haben doch nur Windows“ ist fast nie wahr.
- Zu großer Scope im Pilot: wenn du zu breit startest, weißt du nicht, was kaputtgeht.
- Kein Rollback pro OU: Rückfall muss granular sein, sonst rollst du alles zurück.
- Kerberos-Crypto-Drift: RC4-Ausnahmen und Alt-SPNs werden plötzlich sichtbar — und blocken Fortschritt.
- Tier-0 wird nicht priorisiert: wenn du mit Clients anfängst, verlierst du Wirkung.
Projekt-Checkliste (für ein sauberes Kerberos-Armoring-Change)
- [ ] DC-/Client-Basis prüfen (Versionen, Patch-Level, funktionale Level, Crypto-Stand).
- [ ] Abhängigkeiten inventarisieren (Appliances, SSO/IdM/PAM, Legacy Apps, SPN-Landschaft).
- [ ] Telemetrie definieren (Logs, Monitoring, Verantwortlichkeiten, Eskalationsweg).
- [ ] Pilot-OU definieren und Testfälle festschreiben.
- [ ] FAST auf „Supported“ im Pilot; 1–2 Wochen Beobachtung.
- [ ] Wave-Plan für Tier-0/Tier-1; Change-Fenster und Rollback testen.
- [ ] Enforce erst nach geschlossenem Backlog; Legacy-Plan dokumentieren.