Kerberos Password setzen (KPASSWD)

Kerberos wird nicht nur zur Anmeldung und Autorisierung genutzt, sondern über Kerberos kann ein Client auch sein Kennwort aktualisieren.

Die Mitschnitte wurden mit Windows 2016 Patchstand Jan 2023 angefertigt, d.h. nach dem Nov 2022. AES ist der neue Default Encryption Type.

Benutzer ändert Kennwort

Zuerst habe ich auf einem Windows 2016 DC mit Wireshark einen Netzwerk-Mitschnitt konfiguriert, bei dem ich alle Pakete des Clients (Ebenfalls Windows 2016) mitgeschnitten habe. An dem Client war ich bereits angemeldet und habe dann über CTRL-ALT-DEL mein Kennwort geändert. Im Wireshark haben wir folgende Pakete gesehen:

  • Paket 19/20 ist der Versuch ein Ticket ohne Kerberos PreAuth zu bekommen, was normal ist. Der Server lehnt ab und der Client weiß nun, was er zu tun hat.
  • Paket 27 ist dann die Anforderung ein Ticket für den Dienst "kadmin/changepw" zu bekommen.

    Die Antwort im Paket 28 (nicht abgebildet) liefert ein Service Ticket.
  • Paket 36 zeigt dann die Kennwortänderung mit dem Serviceticket aus Paket 28
    "Leider" ist hier alles verschlüsselt, so dass Sie sonst nichts sehen können. Wir erkennen aber, dass die AES für das ServiceTicket und die Kennwortänderung eingesetzt wird.
  • Paket 37 enthält die Antwort
    Auch hier ist alles verschlüsselt und wir können nicht einmal sehen, ob die Änderung erfolgreich war oder nicht.

Ich habe dazu versucht ein "einfaches" Kennwort zu setzen, welches durch den DC anhand der Kennwortrichtlinie natürlich abgelehnt wurde. Auf dem Client bekam ich die Fehlermeldung aber diese ist nicht als Fehler oder Status in Wireshark-Trace zu sehen.

Computer ändert Kennwort

Auch Computer als Domainmitglieder sind angehalten immer mal wieder ihr Kennwort zu ändern. Das passiert meist alle 30 oder 60 Tage. Darauf zu warten ist natürlich wenig sinnvoll. Aber es gibt die PowerShell oder NETDOM, mit der die Vertrauensstellung aktualisiert werden kann. Ich bediene mich hier dem Commandlet "Test-Computersecurechannel".

Achtung: Starten Sie den "-Repair"-Option immer in einer Admin-Powershell, damit das neue Kennwort auch lokal hinterlegt werden kann. Ansonsten macht das "Repair" gerade das Gegenteil, d.h. es aktualisiert das Kennwort im Active Directory und kann dann das lokale Kennwort nicht setzen und der Computer ist gerade nicht mehr mit dem AD verbunden.

Ohne Parameter verspricht das Commandlet die Vertrauensstellung des Clients mit der Domain zu prüfen. Allerdings habe ich oftmals ein "true" bekommen, obwohl der Trust mangels Admin-Rechte gerade kaputt gemacht wurde. Das habe ich immer gemerkt, wenn ich mich danach nicht mehr anmelden konnte. Mit einer Admin-PowerShell sollte es Aber keine Probleme geben.

Test-Computersecurechannel -Repair

Mit dem Parameter "-repair" setzt das Comandlet den Trusted Channel zurück:

Indicates that this cmdlet removes and then rebuilds the channel established by the NetLogon service. Use this parameter to try to restore a connection that has failed the test.
Quelle https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel?view=powershell-5.1

Mit Wireshark sieht das dann wie folgt aus:

  • Paket 168: Der Client fordert zuerst ein Ticket für den Service "kadmin/changepwd" an
  • Paket 170: Die Antwort liefert ein Service Ticket und ist nicht sonderlich spektakulär
  • Paket 179 zeigt dann das Update des Kennworts über Kerberos
    Erwartungsgemäß sind auch hier alle Daten verschlüsselt.
  • Paket 183 enthält dann die Antwort
    Auch hier sehe ich nur Bytes aber keine Detailinformation.

In den AD-Properties ist aber zu sehen, dass das Kennwort geändert wurde:

AES statt RC4

DES ist zählt als geknackt und wird seit Windows Vista/2008 nicht mehr verwendet. Aber auch RC4 darf wohl nicht mehr als sicher angesehen werden und es mehren sich die Stimmen, RC4 zu vermeiden (Siehe Kerberos RC4 Abschaltung). Daher ist gerade der Prozess der "Kennwortänderung" natürlich ein Ziel für Angriffe. Sie können in Windows mittlerweile erzwingen, dass Kennwort-Änderungen nicht mehr über RC4 erfolgen.

Wir können über drei Optionen sicherstellen, dass das Kennwort nur per AES geändert werden kann.

  • Pro Benutzer über Smartcard-Einstellung
    Wenn Sie auf dem Konto die Option "Require Smartcard" aktivieren, wird damit auch RC4 abgeschaltet
  • RC4 auf allen DCs deaktivieren
    Wenn Sie per Gruppenrichtlinie oder Regedit die Einstellung "SupportedEncryptionTypes=24dez" setzen, dann nutzen die DCs generell kein RC4 mehr.
  • "Protected Users" Gruppe
    Seit Windows 2012R2 Forestmode gibt es diese Gruppe, deren Mitglieder besser geschützt werden. Für diese Mitglieder wird auch RC4 abgeschaltet. Aber prüfen Sie, welche Seiteneffekte dieser Weg noch hat.

Es gibt aktuell keine Gruppenrichtlinie oder Registrierungsschlüssel, mit denen Sie genau diese Funktion erzwingen können.

Entsprechend habe ich auf dem KDC meiner Lab-Umgebung einen AES-Zwang aktiviert und den Client mit folgendem RegKey auf RC4 festgelegt. (Siehe Details auf Kerberos Encryption und Kerberos RC4 Abschaltung)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
"SupportedEncryptionTypes"=dword:00000004

Wenn ich dann versuche, als Benutzer oder für den Computer das Kennwort auf dem Client zu ändern, dann schlägt dies fehl:

  • Paket 453 und 470
    Der Client versucht zweimal ein Token mittels RC4 (Arcfour) zu erhalten. Das Autorisierungticket selbst ist weiterhin AES.
  • Paket 456/473
    Zweimal liefert der KDC aber den Fehler, dass es keinen passenden EncryptionType gibt

Das ist nun leider keine perfekte Verifizierung, denn eigentlich hätte ich es noch zulassen müssen, dass der Client ein Service Ticket bekommt und dann den Fehler beim KPASSWD zu sehen. Leider ist das bei Windows miteinander verbunden, d.h. wenn ich auf dem Server RC4 generell oder für den Benutzer blockiere oder auf dem Client RC4 vorschreibe, dann betrifft das alle Kerberos-Zugriffe.

Kennwort mit RC4

Ich habe aber einmal RC4 auf dem Client vorgegeben und dann sehen wir schon, dass der Client auch per RC4 sein Kennwort ändern kann, wenn der Server dies erlaubt.

Der Request in Paket 149 zeigt deutlich RC4 sowohl für die Payload als auch Authenticator:

Zusammenfassung

Wenn Sie das Kennwort eines Kontos im Active Directory ändern möchten, dann können Sie dies zwar auch per LDAP oder NETLOGON/RPC machen. Dies ist auch der normale Weg, wenn ein Administrator das Kennwort für einen Benutzer neu setzt. Wenn ich aber als Inhaber selbst angemeldet bin dann kann ich mittels der Kerberos KPASSWD-Funktion mein Kennwort einfach und sicher ändern.

Wenn ich die sicherere Variante AES erzwingen möchte, dann ist das nicht alleine für den Kennwort-Prozess möglich, sondern betrifft jegliche Kommunikation per Kerberos. Dennoch erlaubt auch ein Windows 2016 Server mit Patchstand nach den Nov 2022 Security Updates (Siehe Windows Security Changes 2023)

Übrigens: Die Tickets für "kadmin/changepw" werden nicht mit KLIST angezeigt.

Weitere Links