KRB AP ERR MODIFIED entschlüsseln
Kerberos-Fehlerdiagnose: Event 4 lesen, SPNs prüfen, Zugriffsproblem lösenKRB_AP_ERR_MODIFIED entschlüsseln: wenn der falsche das Ticket aufmacht
Es gibt Fehlermeldungen, die klingen wie ein Tatortbericht. KRB_AP_ERR_MODIFIED ist so eine. „Modified“ suggeriert, jemand habe unterwegs am Ticket herumgeschraubt – Man-in-the-Middle, Alarmstufe Rot, Security-Team wecken. In 99 Prozent der Fälle ist die Wahrheit banaler und peinlicher: Der Server, der das Ticket aufmachen soll, hat einfach den falschen Schlüssel. Kein Angreifer. Nur Active Directory, das genau das getan hat, was jemand vor drei Jahren konfiguriert hat.
Der Mechanismus ist schnell erklärt. Wenn ein Kerberos-Client ein Ticket für einen Dienst anfordert, wird dieser Dienst über seinen SPN identifiziert. Das KDC stellt ein Service-Ticket aus, das mit dem geheimen Schlüssel des Dienstes verschlüsselt ist – im Kern also mit dem Kennwort des AD-Kontos, das zum angefragten SPN passt. Kurz gesagt passiert der Fehler, weil das KDC ein Ticket mit dem Kennwort von Konto A ausgestellt hat, der Dienst auf der Serverseite es aber mit dem Kennwort von Konto B zu entschlüsseln versucht.
Der Anwender merkt davon nichts Feines. Das eigentliche Symptom ist ein fehlgeschlagener Zugriff auf eine Ressource, meist mit „Zugriff verweigert“ beziehungsweise Fehler 5. Dieser Artikel geht den Weg entlang der Ereignisanzeige: Event 4 lesen, Ursachenkette verstehen, mit setspn, klist und nslookup den Schuldigen einkreisen. Grundlagen zum Protokoll stehen auf der Pillar-Seite /microsoft-kerberos.
|
INFO Faktenkasten: Event-ID 4, Quelle „Security-Kerberos“, Log „System“, Level „Fehler“. Das Event landet auf dem Client, nicht auf dem Server. Der Server, der nicht entschlüsseln kann, antwortet nur – protokollieren muss der Client. Wer also auf dem Dateiserver nach Spuren sucht, sucht am falschen Ort. |
|---|
Event 4 lesen: drei Namen, eine Wahrheit
Der Text des Events ist untypisch gesprächig für Microsoft-Verhältnisse. Er lautet in etwa: „The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server computer1$. The target name used was cifs/computer2.domain.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server.“
Genau hier steckt die halbe Diagnose. Es gibt zwei Namen im Text, und wenn sie nicht zusammenpassen, ist der Fall praktisch gelöst.
Feld 1: „from the server“
Das ist der Host, der geantwortet hat – der Rechner, bei dem das Paket tatsächlich angekommen ist. Steht dort ein Maschinenkonto mit Dollarzeichen, hat sich der Kollege selbst identifiziert.
Feld 2: „The target name used was“
Das ist der SPN, für den der Client sein Ticket geholt hat. Klassisch cifs/, host/ oder HTTP/. Dieser SPN bestimmt, mit welchem Kontokennwort das Ticket verschlüsselt wurde.
Der Abgleich
Steht in Feld 1 ein anderer Rechner als in Feld 2, hat der Client mit Host B gesprochen, aber ein Ticket für Host A dabei. Genau dieses Muster taucht in echten Fällen ständig auf, etwa „from the server z1526$“ bei „target name cifs/Z1508.GSFC.org“. Zwei verschiedene Rechner, ein Ticket – Ende der Vorstellung.
Stimmen beide Namen überein, wird es interessanter. Dann liegt das Problem nicht in der Adressierung, sondern in den Schlüsseln selbst: falsches Konto, altes Kennwort oder ein Verschlüsselungstyp, den die Gegenseite nicht mag.
|
TIPP Sammeln Sie mindestens fünf Events dieser Art, bevor Sie loslegen. Tritt immer derselbe Target-Name auf, ist es ein SPN- oder DNS-Problem. Wechseln die Namen wild und betreffen viele Clients untereinander, riecht es nach Klonen, Namensdubletten oder Verschlüsselungsrichtlinien. |
|---|
Die vier üblichen Verdächtigen
Die Liste der Ursachen ist erstaunlich kurz. Häufige Auslöser sind doppelte SPNs, falsche DNS-Einstellungen, zwei Computer mit demselben Namen in unterschiedlichen Domänen und Clients, die den falschen SPN anfragen. Dazu kommen seit einiger Zeit die Verschlüsselungstypen.
Doppelte SPNs
Der Klassiker. Probleme entstehen, wenn dieselbe SPN-Zeichenkette an mehreren AD-Objekten hängt – etwa wenn sowohl das Computerkonto SERVER01 als auch das Dienstkonto SqlSvcAcct01 den SPN MSSQLSvc/SERVER01.contoso.com:1433 tragen. Das KDC muss sich für einen Schlüssel entscheiden, und es entscheidet sich statistisch gerne für den falschen. Ohne eindeutige Principal-Namen kann der Kerberos-Client nicht sicherstellen, dass er mit dem richtigen Server spricht. Details zur SPN-Syntax und zu sauberer Registrierung stehen im SPN-Spoke dieser Serie unter /microsoft-kerberos/spn-service-principal-name.
Der SPN klebt am Ex-Server
Migration ohne Aufräumen. Ein real dokumentierter Fall nach einem Exchange-Umzug: Die SPNs für Mail und Autodiscover wurden nicht automatisch auf den neuen Server übertragen, sondern zeigten weiter auf den alten – nach Entfernen und Neusetzen liefen die Outlook-Clients wieder normal.
DNS-Alias auf dem falschen Host
Ein CNAME ist schnell gebaut und wird nie wieder angefasst. Ein dokumentierter Fall: Ein Client nutzte einen DNS-CNAME, um Verkehr nach der Außerbetriebnahme von Server A auf Server B zu lenken – das Entfernen des CNAME hätte das Problem gelöst. Auch veraltete Records zählen: Typische Auslöser sind eine falsch konfigurierte DNS-Umgebung, veraltete Einträge oder mehrere DNS-Records mit derselben IP. Der Reverse-Lookup gehört ausdrücklich mit geprüft, weil er für den Server-Match verwendet wird.
Geklonte oder gleichnamige Maschinen
Der Eventtext nennt es selbst: Häufig liegt es an identisch benannten Maschinenkonten in der Ziel- und in der Client-Realm. Wer VMs klont, ohne das Maschinenkonto neu aufzusetzen, hat zwei Rechner mit einem Namen und zwei verschiedenen Kennwörtern. Nur einer gewinnt.
|
WARNUNG Doppelte SPNs sind nicht immer sichtbar. In getesteten Domänen mit Windows Server 2012 R2 und 2016 konnten Dubletten entstehen, die die üblichen Prüfungen nicht erkannten: identisch benannte Computerkonten, von denen eines nach der Replikation einen CNF-Namen erhält, sowie unterschiedlich benannte Computer, die sich unsichtbar denselben SPN teilen. Ein sauberes setspn -X ist also kein Freispruch, nur ein Indiz. |
|---|
Der Diagnoseweg: setspn, klist, nslookup
Jetzt wird gearbeitet. Die Reihenfolge ist wichtig, weil jeder Schritt den nächsten billiger macht.
Schritt 1: Cache leeren, damit Sie echte Daten sehen
Ein altes Ticket im Cache verfälscht jeden Test. Microsoft-Anleitungen beginnen genau deshalb mit dem Aufräumen: Eine Eingabeaufforderung mit erhöhten Rechten öffnen, „klist purge“ für die zwischengespeicherten Kerberos-Tickets ausführen und mit „ipconfig /flushdns“ den DNS-Cache leeren. Für Dienste im Systemkontext gilt: klist purge -li 0x3e7. Wer das vergisst, jagt Geister und behebt Probleme, die schon behoben waren.
Schritt 2: Wem gehört der SPN?
Der Target-Name aus dem Event wandert direkt in setspn. Auf einer Eingabeaufforderung mit erhöhten Rechten und Enterprise-Admin-Anmeldedaten liefert setspn -Q <SPN> den zugehörigen Computernamen. Zusätzlich: setspn -L listet die registrierten SPNs eines Objekts, setspn -X sucht nach Dubletten, setspn -S fügt einen SPN erst nach Dublettenprüfung hinzu. Mit dem Modifier -F lässt sich die Suche über den gesamten Forest ausdehnen. Vorsicht bei großen Umgebungen: setspn -x durchsucht den kompletten Forest und kann lange dauern, weshalb setspn -q in großen Umgebungen die bessere Wahl ist.
Schritt 3: Namensauflösung gegenprüfen
nslookup auf den Namen im Target-Feld, dann nslookup auf die zurückgegebene IP. Landen Sie bei einem anderen Host als im Feld „from the server“, haben Sie den Alias gefunden. Doppelte Einträge werden so bereinigt, dass eine IP pro Server und ein Server pro IP bleibt – und man sollte Replikationsverzögerung sowie Client-Timeout abwarten, bevor man erneut testet. Nicht vergessen: die lokale hosts-Datei. In einem dokumentierten Fall zeigte nach einer Serverumbenennung ein nicht aktualisierter hosts-Eintrag den neuen Server auf die IP des alten.
Schritt 4: Aufräumen
Zur Lösung muss der SPN am falschen Konto gesucht, dort entfernt und am richtigen Konto in Active Directory hinzugefügt werden. Das Entfernen erfolgt mit setspn -D <SPN> <Computername>. Danach setspn -x erneut laufen lassen oder setspn -l am verbleibenden Objekt prüfen.
|
WICHTIG Ein SPN wird nie einfach gelöscht, weil er im Weg ist. Er wird umgezogen. Wer den SPN am Dienstkonto entfernt, weil das Computerkonto ihn auch hat, legt unter Umständen die Anwendung lahm, die unter diesem Dienstkonto läuft. Regel: Der SPN gehört dorthin, wo der Dienstprozess tatsächlich läuft – Maschinenkonto bei LocalSystem oder NetworkService, Dienstkonto bei allem anderen. |
|---|
Wenn der SPN sauber ist: Verschlüsselung und andere Ausreden
Manchmal ist alles korrekt – und der Fehler bleibt. Dann hilft die nüchterne Definition weiter: KRB_AP_ERR_MODIFIED bedeutet lediglich, dass der Schlüssel, mit dem das Ticket verschlüsselt wurde, nicht derselbe ist, mit dem der Server es zu entschlüsseln versucht. Das lässt Raum für zwei weitere Kategorien.
Erstens: Kennwörter. Der Fehler kann auch auftreten, wenn das Kennwort des Zieldienstkontos von dem abweicht, das im KDC für diesen Dienst konfiguriert ist – Dienst und KDC müssen dasselbe Kennwort verwenden. Klassiker: manuell gesetzte Dienstkonto-Kennwörter, zurückgerollte Snapshots, Maschinenkonten nach einem Restore.
Zweitens: Verschlüsselungstypen. Ein Mismatch entsteht, wenn Client und Server über die Richtlinie „Netzwerksicherheit: Konfigurieren von Verschlüsselungstypen für Kerberos“ unterschiedlich eingestellt sind – Ergebnis ist ein Entschlüsselungsfehler und Zugriff verweigert. Zu prüfen ist dabei das Attribut msDS-SupportedEncryptionTypes an Benutzer- und Computerobjekten.
Dieses Thema hat 2026 an Brisanz gewonnen. Microsoft härtet Kerberos stufenweise: Ab den Sicherheitsupdates vom 13. Januar 2026 erhalten Domänencontroller neue Telemetrie und Auditfunktionen für schwache Verschlüsselung, im April 2026 folgt der Default-Wechsel und für Juli 2026 ist die vollständige Erzwingung geplant. Mit dem Update wird AES-SHA1 (0x18) zum Standardwert für DefaultDomainSupportedEncTypes, der bisherige RC4-Fallback auf Domänencontrollern entfällt – Altdienste, die auf RC4 setzen, können ab dann in Authentifizierungsfehler laufen. Im Juli 2026 entfallen der Audit-Modus und der Registry-Schlüssel RC4DefaultDisablementPhase; Enforcement wird der einzige Betriebszustand.
Immerhin liefert Microsoft dafür bessere Werkzeuge: Die Security-Events 4768 und 4769 enthalten künftig msDS-SupportedEncryptionTypes, verfügbare Schlüssel, angebotene Etypes und den verwendeten Ticket- beziehungsweise Sessionschlüssel-Typ – damit lässt sich feststellen, ob das Problem am Client, am Konto oder an den KDC-Defaults liegt.
Und drittens, der Vollständigkeit halber, die Netzwerkausrede: Seltener entsteht der Fehler durch Netzwerkprobleme zwischen Client und Server, bei denen das Ticket abgeschnitten wird.
|
INFO Faktenkasten RC4-Ausstieg: Auslöser ist CVE-2026-20833, eingeordnet als Verwendung eines gebrochenen oder riskanten kryptografischen Algorithmus in Windows Kerberos. Betroffen sind vor allem Dienstkonten, NAS-Geräte und Altanwendungen ohne explizit gesetztes msDS-SupportedEncryptionTypes. Wer im Zuge dieser Umstellung plötzlich Event 4 sieht, sollte nicht reflexhaft SPNs umbauen, sondern erst die Enctypes prüfen. |
|---|
Häufige Fragen
Ist KRB_AP_ERR_MODIFIED ein Angriff?
Fast nie. Der Name stammt aus dem RFC-Wortschatz und meint „Nachricht verändert“, tatsächlich signalisiert er einen Schlüssel-Mismatch. Bevor Sie das SOC alarmieren, prüfen Sie SPNs, DNS und Enctypes. Wenn der Fehler nur für einen einzigen Dienst und immer denselben Target-Namen auftritt, ist es Konfiguration, nicht Kriminalität.
Warum sehe ich Event 4 zwischen Clients, nicht nur bei Servern?
Weil Clients auch Dienste anbieten. SPNs werden nicht nur für Benutzerkonten registriert, sondern ebenso für Maschinen – ob Server oder Client. Typisch sind cifs/-Tickets bei Inventarisierung, Fernwartung oder Softwareverteilung. Auch dokumentiert bei Managementsystemen: Ereignisse mit „from the server computer1$“ und Target „cifs/computer2.domain.com“ tauchten dort für viele Arbeitsplätze auf.
Kann setspn Dubletten automatisch aufräumen?
Nein, und das ist gut so. Weil es Duplikate sind, kann setspn sie nicht selbst entfernen – das Werkzeug weiß nicht, welcher Eintrag der richtige ist. Diese Entscheidung müssen Sie treffen, indem Sie nachsehen, unter welchem Konto der Dienst wirklich läuft.
Reicht ein Neustart?
Ein Neustart leert den Ticketcache und lässt das Problem verschwinden – bis zum nächsten Zugriff. Wer nur neu startet, verschiebt den Anruf auf morgen. klist purge macht dasselbe schneller und ohne Wartungsfenster.
Was ist mit Aliasnamen, die legitim sind?
Aliase sind erlaubt, brauchen aber eigene SPNs am richtigen Konto, und bei Dateidiensten zusätzlich Anpassungen an der Namensprüfung des Servers. Ein CNAME allein genügt Kerberos nicht. Details dazu im SPN-Spoke unter /microsoft-kerberos/spn-service-principal-name.
|
TIPP Bauen Sie sich eine Ein-Zeilen-Diagnose: Target-Name aus dem Event kopieren, setspn -Q darauf laufen lassen, nslookup auf denselben Namen. Stimmen Kontobesitzer und aufgelöster Host mit dem Server im Event überein, sind Sie in unter zwei Minuten bei den Verschlüsselungstypen. Das ersetzt drei Stunden Paketmitschnitt. |
|---|
Fazit
KRB_AP_ERR_MODIFIED ist kein Kryptorätsel, sondern ein Buchhaltungsproblem. Irgendwo in Active Directory hält das falsche Objekt den Schlüssel für einen Namen, den ein anderer Rechner beantwortet. Der Eventtext verrät fast immer, wer wen verwechselt: ein Blick auf „from the server“ und „target name“, und die Richtung stimmt.
Der Diagnoseweg bleibt derselbe, egal ob doppelter SPN, vergessener CNAME oder eine geklonte VM mit fremder Identität: Cache leeren, SPN-Besitzer klären, Namensauflösung gegenprüfen, dann sauber umziehen statt löschen. Neu ist nur die zweite Fehlerklasse, die 2026 an Bedeutung gewinnt – Verschlüsselungstypen. Wer nach dem RC4-Ausstieg plötzlich Event 4 sieht, sollte zuerst die Enctypes prüfen, bevor er an funktionierenden SPNs schraubt.
Und die gute Nachricht: Dieser Fehler ist ehrlich. Er tritt sofort auf, betrifft reproduzierbar denselben Dienst und verschwindet dauerhaft, sobald die Ursache weg ist. Mehr Kooperation kann man von einer Fehlermeldung kaum erwarten. Weitere Bausteine der Serie: /microsoft-kerberos.