Die AES-Checkbox ist gesetzt, der zweite Knoten fällt aus

Eine Anwendung besteht aus zwei Linux-Knoten hinter einem Loadbalancer. Beide verwenden dasselbe AD-Dienstkonto und lokale Keytabs. Nach einer AES-Umstellung funktioniert die Anmeldung zunächst. Beim nächsten Failover scheitert sie: Nur der aktive Knoten hatte das neue Schlüsselmaterial erhalten. Die AD-Konfiguration war korrekt, die Anwendung trotzdem nicht betriebsbereit.

Solche Fehler verschwinden nicht durch eine weitere globale Kerberos-Einstellung. Dieser Beitrag behandelt die technische Migration einzelner Dienstpfade: von vorhandenen Schlüsseln über Keytab-Versionen bis zur Abnahme von Tickets und Anwendungssitzungen. Patchtermine, generelle Service-Account-Hygiene und eine krbtgt-Rotation sind eigene Arbeitspakete.

Das Ziel ist überprüfbar: Jeder freigegebene Pfad arbeitet mit AES, einschließlich Neustart, Failover und benötigter Backend-Zugriffe. Für RC4 verbleibt entweder eine ausdrücklich befristete Ausnahme oder kein produktiver Bedarf.

Vier Ebenen müssen zusammenpassen

AD-Attribut: msDS-SupportedEncryptionTypes beschreibt unterstützte Verfahren. Es erzeugt keine Schlüssel und beweist keine erfolgreiche Nutzung. Ein fehlender Wert bedeutet nicht automatisch RC4-only; das Ergebnis hängt unter anderem vom KDC-Default ab.

Schlüsselmaterial: Das Konto benötigt passende AES-Schlüssel in AD. Alte Kennwörter können diese Voraussetzung verfehlen. Ein kontrollierter Kennwortwechsel kann fehlende AES-Schlüssel erzeugen; die beteiligten Dienste müssen dasselbe neue Geheimnis beziehungsweise daraus abgeleitete Schlüssel erhalten.

Host und Anwendung: Windows-Richtlinien, Kerberos-Bibliotheken und Produktkonfiguration bestimmen, was tatsächlich angeboten und akzeptiert wird. Ein Linux-Dienst wird durch eine Windows-GPO allein nicht umgestellt.

Laufender Austausch: Ticketverschlüsselung und Sitzungsschlüssel sind getrennte Ergebnisse. Ein AES-Sitzungsschlüssel beweist nicht, dass auch das Service-Ticket mit AES geschützt wurde. Genau diese Trennung gehört in den Abnahmenachweis.

Ein Migrationsblatt pro Dienstpfad anlegen

Erfasse Clienttyp, aufgerufenen DNS-Namen, erwarteten SPN, zugehöriges AD-Konto, alle Dienstknoten und gegebenenfalls Backend oder Trust-Grenze. Ergänze Keytab-Pfad, verwaltendes Deployment, Herstellerfreigabe, Owner und Wartungsfenster. Dokumentiere Metadaten, niemals Keytab-Inhalt oder Kennwörter im Ticket-System.

Eine gezielte, rein lesende Abfrage des bekannten Dienstobjekts liefert einen Ausgangspunkt. Der Beispieldistinguishedname muss ersetzt werden; normale delegierte Leserechte reichen bei üblichen AD-Berechtigungen aus. Das ActiveDirectory-Modul ist erforderlich.

Set-StrictMode -Version Latest
Import-Module ActiveDirectory -ErrorAction Stop
$serviceIdentity = 'CN=svc-app,OU=Service Accounts,DC=example,DC=org'
$properties = @(
    'servicePrincipalName', 'msDS-SupportedEncryptionTypes',
    'msDS-KeyVersionNumber', 'pwdLastSet'
)
Get-ADObject -Identity $serviceIdentity -Properties $properties `
    -ErrorAction Stop |
    Select-Object DistinguishedName, servicePrincipalName,
        msDS-SupportedEncryptionTypes, msDS-KeyVersionNumber, pwdLastSet

Die Abfrage zeigt weder die geheimen Schlüssel noch den Nachweis ihrer Nutzbarkeit. Das Kennwortdatum ist ein Hinweis für die Planung, kein AES-Test. Computer-, gMSA- und klassische Benutzerkonten müssen passend zu ihrem Verwaltungsmodell behandelt werden.

Keytabs und Schlüsselversionen gemeinsam wechseln

Eine Keytab enthält langfristige geheime Schlüssel. Ihre Einträge unterscheiden sich unter anderem nach Principal, Verschlüsselungstyp und Key Version Number, kurz KVNO. Ein korrekter Dateiname oder ein vorhandener AES-Eintrag allein reicht nicht.

Plane den Wechsel als zusammenhängenden Dienst-Change:

  1. Prüfe AES-Unterstützung der tatsächlich eingesetzten Produkt- und Bibliotheksversion. Kläre, welcher Prozess die Keytab lädt und wann er Änderungen übernimmt.
  2. Sichere die bisherige Konfiguration und einen herstellerkonformen Wiederanlaufplan. Ein altes Keytab-Backup ist nach einem AD-Kennwortwechsel nicht automatisch verwendbar.
  3. Erzeuge benötigte AES-Schlüssel über den vorgesehenen Kennwort- und Keytab-Prozess. Berücksichtige exakten Principal, Groß-/Kleinschreibung, Salt und Schlüsselversion.
  4. Verteile die aktuelle Keytab geschützt auf sämtliche berechtigten Knoten. Dateirechte müssen auf die vorgesehenen Dienstidentitäten begrenzt bleiben.
  5. Prüfe Principal, AES-Typen und passende KVNO anhand von Metadaten und einem frischen Ticket. Gleiche Versionsnummern allein beweisen noch keinen passenden Schlüssel.
  6. Lade die Schlüssel durch den vorgesehenen Dienstneustart oder Reload neu und teste jeden Knoten gezielt. Steuere dafür das Routing im Test, während vorgesehener Dienst-DNS-Name und SPN erhalten bleiben; ein anderer Backendname würde einen anderen Identitätspfad prüfen.

Keine Keytab-Generierung als beiläufigen Diagnoseschritt ausführen: Werkzeuge wie ktpass können Kontozuordnung, Kennwort und damit andere Verbraucher beeinflussen. Kennwörter gehören auch dabei nicht in Kommandozeilen oder Shell-History.

AES erlauben und RC4 gezielt herausnehmen

Nach erfolgreichem Schlüssel- und Anwendungstest wird die erlaubte Kryptografie eingeschränkt. Auf Windows liegt die Einstellung unter Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos.

Für den abgestimmten AES-SHA1-Basissatz werden AES128_HMAC_SHA1 und AES256_HMAC_SHA1 zugelassen; RC4 und DES entfallen im freigegebenen Geltungsbereich. Zusätzliche neuere Verfahren folgen der getesteten Plattformbaseline. Verteile die Änderung zunächst an eine Pilotgruppe und plane die erforderlichen Neustarts ein. Prüfe anschließend die effektive Richtlinie, nicht nur den GPO-Editor.

Behandle Kontoattribute separat. In deren Bitmaske stehen 0x4 für RC4, 0x8 für AES128 und 0x10 für AES256. Ersetze bestehende Werte nicht blind durch 0x18: Weitere Fähigkeitsbits können relevant sein. Bei Windows-Computerkonten wird das Attribut durch die Computerkonfiguration mitverwaltet.

Explizite KDC-Defaults und kontobezogene Ausnahmen gehören ebenfalls ins Inventar. Ein aktueller DC-Patchstand allein belegt kein vollständiges RC4-Verbot. Der frühere globale Audit-Rollback über RC4DefaultDisablementPhase wird von Updates ab Juli 2026 nicht mehr unterstützt.

Tickets und Anwendungserfolg getrennt abnehmen

Voraussetzung auf den DCs ist eine wirksame Advanced Audit Policy: Unter Account Logon werden Audit Kerberos Authentication Service und Audit Kerberos Service Ticket Operations für den abgestimmten Umfang mit Success und Failure erfasst. Prüfe Weiterleitung und Aufbewahrung gegen das erwartete Ereignisvolumen. DC-Updatestand und Eventversion bestimmen, welche Zusatzfelder verfügbar sind; fehlende Felder sind kein Nachweis sicherer Verschlüsselung.

Sammle die Security-Ereignisse 4768 und 4769 der zuständigen DCs mit kontrollierten Leserechten beziehungsweise zentraler Weiterleitung. Für Service-Tickets liefert 4769 insbesondere TicketEncryptionType, SessionKeyEncryptionType, Status und Dienstkonto. Parse XML-Feldnamen statt fester Feldpositionen.

Die angezeigten unterstützten Verfahren können verarbeitete Werte statt des unveränderten AD-Attributs sein. Auch RC4 unter Available Keys belegt keine RC4-Nutzung. Bewerte vorhandene Schlüssel und tatsächlich ausgewählte Verschlüsselung deshalb separat.

Bei den Ticket-Etypes bedeuten 0x11 AES128, 0x12 AES256 und 0x17 RC4; 0x18 bezeichnet hier RC4-HMAC-EXP, nicht AES. Das sind andere Werte als die AD-Bitmaske. Ein erfolgreicher Request mit Status 0x0 belegt die Ticketausstellung; erst der Anwendungstest belegt, dass der Dienst es akzeptiert. ServiceName identifiziert im Event das Zielkonto und ist kein verlässlicher Ersatz für den vollständig aufgerufenen SPN.

Die Testmatrix sollte mindestens enthalten:

  • frische Anmeldung einer isolierten Testsitzung mit dem vorgesehenen DNS-Namen;
  • Zugriff auf jeden Dienstknoten und anschließenden Failover;
  • Neustart beziehungsweise Reload des Diensts mit erneutem Zugriff;
  • reale Hintergrundjobs sowie benötigte Backend- und Delegationspfade;
  • Zugriffe über betroffene Domänen- oder Forest-Grenzen in jeder benötigten Richtung;
  • Nachweis, dass kein unbemerkter NTLM-Fallback den Erfolg erklärt.

Vorhandene Tickets und langlebige Verbindungen können Fehler verdecken. Erzeuge frische Testsitzungen kontrolliert; leere keine Ticket-Caches fremder Produktionssitzungen. Beobachte zudem seltene Abläufe wie Monatsjobs. Ein stilles Log außerhalb ihrer Laufzeit ist keine Abnahme.

Fehler nach Ursache behandeln

Kein gemeinsamer Typ: Prüfe angebotene Verfahren und effektive Richtlinien auf Client, Dienst und KDC. Ticket ausgestellt, Dienst lehnt ab: Prüfe SPN-Zuordnung, verwendete Keytab, Principal, KVNO und tatsächlich geladenes Schlüsselmaterial. Nur einzelne Knoten betroffen: Vergleiche Deploymentstand und Prozessneustart. DNS, Uhrzeit und Replikation bleiben zusätzliche Prüfungen.

Eine notwendige Ausnahme erhält Konto, betroffene Systeme, Owner, Ablaufdatum und konkreten Ablöseplan. Sie darf die Domäne nicht pauschal auf RC4 zurücksetzen. Nach der Reparatur folgen derselbe frische Funktionstest und die Entfernung der Ausnahme. Ein produktiver Kennwortwechsel wird über einen abgestimmten Recovery-Prozess behandelt, nicht durch Zurückkopieren einer beliebigen alten Keytab.

Vorteile

  • RC4 verschwindet aus nachgewiesenen Dienstpfaden; schwache Kompatibilitätsannahmen werden sichtbar.
  • Abgestimmte Schlüssel- und Keytab-Verteilung reduziert Ausfälle bei Neustart und Failover.
  • Getrennte Ticket- und Sitzungskriterien machen die Abnahme technisch belastbar.
  • Owner und Wiederanlaufverfahren bleiben auch für spätere Rotation nutzbar.

Nachteile und Grenzen

  • Verteilte Anwendungen benötigen koordinierte Wartungsfenster und herstellerspezifische Tests.
  • Alte Produkte können einen Versionswechsel oder Ersatz erfordern; ein AD-Attribut repariert keine fehlende Implementierung.
  • AES verhindert weder Kerberoasting mit schwachen Geheimnissen noch Missbrauch eines bereits kompromittierten Diensts.
  • RC4-Abschaltung in Kerberos deaktiviert NTLM nicht. Dieses Protokoll braucht eigene Kontrollen.
  • Ein begrenztes Beobachtungsfenster beweist nicht die Funktion selten genutzter Abhängigkeiten.

Projekt-Checkliste

  • [ ] Dienstpfade einschließlich SPNs, Knoten, Backends und Trust-Grenzen dokumentiert.
  • [ ] AES-Unterstützung der tatsächlich eingesetzten Produkte geprüft.
  • [ ] Vorhandene Schlüssel von Attributwerten und Hostrichtlinien getrennt bewertet.
  • [ ] Keytab-Verteilung, Principal, KVNO und Dateirechte auf jedem Knoten geprüft.
  • [ ] Kennwortwechsel, Reload und Recovery mit allen Verbrauchern abgestimmt.
  • [ ] Konto- und KDC-Ausnahmen sowie effektive Windows-Richtlinien geprüft.
  • [ ] Audit-Unterkategorien, Eventversionen, Weiterleitung und Aufbewahrung geprüft.
  • [ ] Ticket- und Sitzungstypen mit frischen Anmeldungen getrennt nachgewiesen.
  • [ ] Failover, Neustart, Hintergrundjobs und benötigte Trust-Pfade getestet.
  • [ ] Anwendungserfolg bestätigt und NTLM-Fallback ausgeschlossen.
  • [ ] Restliche RC4-Ausnahmen befristet und Entfernung verbindlich terminiert.