Kerberos Encryption

Im Jahr 2023 unterstützt Windows sowohl RC4 als auch AES als Verschlüsselungsverfahren. Das Nov 2022 Update hat aber AES als neuen Default gesetzt. Auf dem Weg zur Abschaltung habe ich einige Wireshark Traces erstellt und wundersame Effekte beobachtet.

Beachten Sie dazu auch die Seite Kerberos Wireshark

Encryption Codes

Wenn Sie Kerberos etwas kennen, dann meldet sich der Benutzer an, u mein Ticket Granting Ticket TGT) zu bekommen und in der Folge dann vom Ticket Granting Service (TGS) ein Serviceticket zu erhalten. da aber weder Client noch Server voneinander wissen, was sie können, sehen wir in Wireshark mehrere Kerberos-Pakete, mit denen Protokolle ausgehandelt werden. Zum Schutz der Pakete werden Informationen mit Verwahren wie AES, RC4, DES, 3DES verschlüsselt und mit MD5, SHA-1, HMAC, CRC32 Prüfsummen versehen. Bei so viel Optionen müssen sich die Partner auf etwas einigen.

Hinweis: Wenn ihre Netzwerkkarte ein TCP Checksum Offloading macht, kann es sein, dass Wireshark die empfangenen Pakete nicht dekodiert
Wenn Sie nur Kerberos-Pakete analysieren, dann ist ein Capture Filter wie "udp port 88 or tcp port 88" direkt auf dem Interface hilfreich

Ähnlich wie beim TLS Handshake gibt es auch bei Kerberos eine Aushandlung, indem der Client beim Request eine Liste der von ihm verstandenen Verschlüsselung/Prüfsummen-Verfahren mit sendet und der Empfänger sich eine kompatible und hoffentlich die sicherste Version aussucht. Entsprechend finden wir im ersten Kerberos-Paket in Klartext eine Liste der vom Absender nutzbaren Verfahren:

• Windows 2016 Feb2023 SU
  

• RedHat 6
   

• Windows XP SP3!
  

Lassen Sie sich nicht verwirren: Manchmal wird "RC4"  auch als "ARCFOUR" ausgeschrieben.

Es gibt natürlich noch viel mehr Crypto-Verfahren und auch die Tabelle ist nur eine Momentaufnahme.

Sie sehen schon, dass es einige Verfahren gibt, die man definitiv nicht mehr einsetzen sollte. Insbesondere das DES-Verfahren ist so schwach, dass selbst Microsoft nur bis Windows 2003 genutzt hat und höhere Versionen es gar nicht mehr anbieten. Allerdings nutzt Windows im Jahr 2023 immer noch RC und AES, wobei durch das Nov 2022 Updates das Standardverfahren von RC4 auf AES umgestellt wurde.

Siehe dazu auch Kerberos RC4 Abschaltung

Hier war Microsoft wieder schnell, denn ich habe selbst im Jahr 2023 noch Wireshark-Traces gesehen, bei denen DES einem Windows DC/KDC angeboten wurde.

Even before RFC 6649 was formally published, Microsoft disabled (by default) DES with the release of server 2008 R2 Windows 7.  If you were supporting Active Directory in 2009, you most likely did not even notice DES had been disabled by your newly upgraded domain controllers because Active Directory is designed to select the highest level of encryption that is supported by the client and target of a Kerberos ticket.   Support for AES ticket encryption was introduced with the release of Server 2008 / Windows 7 but it was not automatically enabled on domain accounts in order to ensure backward compatibility.
Quelle: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797

• Retiring DES
  http://web.mit.edu/kerberos/krb5-latest/doc/admin/advanced/retiring-des.html
• MIT Kerberos Documentation - Encryption types
  https://web.mit.edu/kerberos/krb5-devel/doc/admin/enctypes.html
• MIT Kerberos Documentation - kdc.conf - Encryption types
  https://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/kdc_conf.html#encryption-types
• RFC6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos
  https://www.rfc-editor.org/rfc/rfc6649

Welche Verfahren von dem Client jeweils angeboten werden, kann ein Administrator natürlich konfigurieren. Bei UNIX ist dies in der Datei KRB5.CONF/KDC.CONF hinterlegt während bei Windows eine Gruppenrichtlinie bzw. ein Registrierungsschlüssel dies steuert:

Die Richtlinie ist per Default nicht aktiv, so dass die Windows Defaults zum Einsatz kommen.

Achtung: Sie können hier anscheinend auf einem Server auch "DES_CBC_CRC" und/oder "DES_CBC_MD5" einschalten. Dennoch wird ein Windows 2008 Server und neuer diese Einstellung zwar umsetzen aber nicht reagieren. Damit legen Sie Kerberos tot. Zumindest im weiter unten beschrieben Test mit Windows 2016 DCs kam kein Handshake zustande.

Zudem gibt es auch noch beim AD-Objekt das Feld "SupportedEncryptionTypes", welche einen Einfluss auf die ausgestellten Kerberos-Ticket hat.

Microsoft hat am Nov 2022 den Default von RC4 auf AES umgestellt.
KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966
https://support.microsoft.com/en-us/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d

Achtung
Wenn Sie diese Richtlinie setzen, dann aktivieren Sie IMMER auch die beiden AES-Suites. Windows 2008 und machen kein DES mehr, selbst wenn Sie es hier vorgeben und seit Windows 2008 Forest Functional Level wird immer AES für das TGT genutzt. Wenn AES abgeschaltet wird, werden keine TGT mehr ausgestellt.

• Kerberos RC4 Abschaltung
• Decrypting the Selection of Supported Kerberos Encryption Types
  https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797?WT.mc_id=M365-MVP-6771
• krb5.conf
  https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html

Anmeldung und Servicezugriff

Auf der Seite Kerberos Wireshark habe ich die verschiedenen Netzwerk-Mitschnitte erfasst, welche die Anmeldung eines Clients am Server als auch den Zugriff per LDAP und SMB zeigen und dabei auch die Standardverfahren bei der Verschlüsselung von Windows 2016 mit Security Update von Feb 2023 nutzen, so dass ich mich hier auf die eigentliche Anmeldung und den Handshake konzentrieren kann. Denn auch hier spielen einige Komponenten eine Rolle. Ein einfaches Active Directory mit einem DC, eine Dateiserver einem Client und einem Benutzer hat schon fünf Stellen, an denen Sie mit Kerberos eingreifen können.

Die folgenden Felder sind standardmäßig alle nicht gesetzt. Das bedeutet, dass dann die Standardwerte zum Einsatz kommen. Diese Werte können sich durch Security Updates ändern.

Damit ergeben sich einige Fragen. Ich wollte zuerst sehen welchen Einfluss dieses Feld hat, d.h. was bietet ein Client an und was akzeptiert dann ein Server. Was passiert, wenn zwei System z.B. nur AES können aber ein ein Service auf RC4 gestellt wurde. Was passiert, wenn zwei Endpunkte keine gemeinsamen Verfahren haben?

Wertebestimmung

Welche Encryption-Verfahren zur Wahl stehen, hat Microsoft auf mehreren Seiten beschrieben. Sie sollten aber auf zwei Dinge achten:

• HEX <> DEZ
  Nicht immer ist bei einer Zahl erkennbar, ob sie dezimal oder hexadezimal zu interpretieren ist. Nicht immer steht ein dez/hex dahinter oder ein "0x" davor.
• Auditing und Konfiguration
  Es gibt einmal eine Tabelle für die Konfiguration der erlaubten Verfahren und eine zweite Tabelle, die aber eine Nummer zum Verfahren im Eventlog beschreibt. Über diese Meldungen können Sie auswerten, er noch schwache Verfahren verwenden, die sie vielleicht bald abschalten wollen.

Hier geht es um den Wert für die Konfiguration, der sowohl für die Richtlinie in "SupportedEncryptionTypes" als auch das AD-Property "msDS-SupportedEncryptionTypes" gilt. Letztlich hat jede Verschlüsselung ein Bit und sie müssen einfach die Bits nach der Wertigkeit aufaddieren:

Wenn kein Bit gesetzt und die Summe damit "0" ist, dann kommt die Default-Einstellung zum Einsatz. Das war bis Nov 2023 noch RC4 und danach AES. 0x18 = 24dez steht dann für AES128+AES256

Das TGT Ticket wurde allerdings seit dem Windows 2008 Forest Functioal Mode als AES-Ticket ausgestellt.

Wenn Sie inkompatible Einstellungen zwischen dem Client, dem Server oder auch dem AD-Objekt für die Zielticket haben, dann lohnt sich ein Blick ins System-Eventlog. Hier z.B. eine Meldung, wenn ein

Log Name:      System
Source:        Microsoft-Windows-Kerberos-Key-Distribution-Center
Date:          23.02.2023 22:22:32
Event ID:      16
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DC01.msxfaq.de
Description:
While processing a TGS request for the target server host/PC2.carius.de, 
the account Admin2@msxfaq.DE did not have a suitable key for generating a Kerberos ticket 
(the missing key has an ID of 8). The requested etypes were 18  17  23  24  -135. 
The accounts available etypes were 23  18  17. 
Changing or resetting the password of PC2$ will generate a proper key.

Ich hatte im Feld "SupportedEncryptionTypes" leider nicht 24Dez sondern 24Hex eingegeben, was dann zu einem Mismatch geführt hat. Die hier aufgezählten Nummern 18,17,23,24,-135 haben aber nichts mit den Bits von Windows zu tun, sondern sind die ENCTypes im Kerberos-Protokoll. Sie dazu den Abschnitt Encryption Codes am Anfang dieser Seite.

• Decrypting the Selection of Supported Kerberos Encryption Types
  https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797

Tipps zum Testen

Wenn Sie die folgenden Szenarien nachstellen wollen, dann brauchen Sie einen Domain Controller mit Wireshark und einen Client und einen dritten Server um diesen als Ziel für Dienstzugriffe zu nutzen. Da der Client diesen Server natürlich erst einmal kontaktiert um die erlaubten Anmeldeverfahren zu erhalten, muss er auch laufen. Zudem müssen Sie ja immer wieder neue Tickets anfordern und verwerfen, damit die Ergebnisse nicht verfälscht werden. Daher hier noch ein paar Hinweise und Tipps:

• KLIST als Admin starten
  Wenn Sie KLIST als Benutzer starten, sehen Sie keine Kerberos-Tickets
• KLIST PURGE
  Damit lassen sich sehr schnell alle Tickets samt dem TGT entfernen. Das triggert aber keine Neuanforderung und alle nachfolgende Anmeldungen werden per NTLM o.ä. durchgeführt. Sie müssen sich ab- und neu anmelden oder zumindest einmal den Desktop sperren und wieder entsperren, um ein neues TGT zu bekommen
• Sperren/Entsperren
  Generell ist dieser Weg elegante als KLIST PURGE. Durch den Entsperrvorgang wird immer ein neues TGT geholt, was anhand des Zeitstempels gut zu sehen ist und alle anderen Tickets werden verworfen. Siehe dazu auch Kerberos Lockscreen.
• Falle SMB
  Der Test per "dir \\server\share" ist sehr einfach und elegant. Allerdings wird die SMB-Session dann auch gehalten, wenn Sie die Tickets wegwerfen. Eine SMB-Connection können Sie mit "Get-SMBSession" anzeigen aber nur durch eine Abmeldung entfernen.
• SupportedEncryptionTypes Verzögerung
  Änderungen Am Feld SupportedEncryptionTypes in der Registrierung werden sofort vom KDC und vom Kerberos-Client erkannt. Bestehende Tickets werden aber nicht entfernt, selbst wenn sie nicht mehr verwendet werden dürfen. Löschen Sie hier alle Tickets mit KLSIT PURGE o.ä.
• msDS-SupportedEncryptionType Verzögerung
  Änderungen am AD-Objekt werden ebenfalls vom KDS bei der nächsten Anfrage gelesen. Es scheint keinen Cache zu geben. Allerdings sollten Sie die AD-Replikation berücksichtigen. Eine Testumgebung mit genau einem DC erleichtert die Tests.
• TGT neu ausstellen
  Wenn sie kein TGT haben, können Sie z.B.: per PowerShell mit "Test-ComputerSecureChannel -Repair" ebenfalls eine Kerberos-Anmeldung erzwingen.

Damit sollte nun ihren Tests nicht mehr im Wege stehen.

Ob es aber ein "Kerberos"-Problem oder vielleicht das darunterliegende Protokoll ist, können Sie oft einfach testen, indem Sie über die IP-Adresse statt des DNS-Namens zugreifen. Eine IP-Adresse ist meist nicht im Zertifikat und nicht im SPN hinterlegt. Ein Zertifikatswarnung zeigt aber, dass der TLS-Handshake funktioniert und ein SMB-Zugriff per IP-Adresse nutzt NTLM und schließt SMB1-Probleme aus
SMB1 Abschaltung, TLS 1.2 Enforcement

SupportedEncryptionTypes und DES

Zuerst habe ich eine direkte Verbindung zwischen einem Client und der Anmeldung am Server durchgespielt. Das lässt sich durch ein "Sperren/Entsperren" des Desktops einfach prüfen.

Änderungen an der Einstellung zu "supportedencryptiontypes" wurden nach meiner Erfahrung sofort und ohne Neustart aktiv.

DC erlaubt nur DES_SBS_CRC

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
"supportedencryptiontypes"=dword:00000001

DC und Client auf DES_CBC_CRC

Nun wollte ich den Client ebenfalls auf DES trimmen und haben den DC noch auf DES gelassen

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
"supportedencryptiontypes"=dword:00000001

DC erlaubt nur DES_CBC_MD5, Client mit DES_CBC_MD5

Als nächstes habe ich den Client angewiesen, dass er nur DES-CBC-MD5 nutzen soll.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
"supportedencryptiontypes"=dword:00000002

DC und Client erlauben nur DES

Also werde ich als nächstes den Server auf DES-CBC-MD5 umstellen, denn ich erwarte, dass der Server mit DES-CBC-CRC einfach nie ein Kerberos-Ticket ausstellen kann.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
"supportedencryptiontypes"=dword:00000002

Das ist von Microsoft auch so dokumentiert:

Quelle https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos

Der Spruch " Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, and later operating systems don't support DES by default" sollten sie streng auslegen. Ich konnte zwar sehen, dass ein Client zumindest DES_CRCR_MD5 angeboten hat aber der Server trotz explizierter Konfiguration nicht drauf eingegangen ist. Mangels Gegenstelle konnte ich nicht prüfen, wie der Client auf eine DES_CBC_MD5 Antwort reagiert hätte.

• Network security: Configure encryption types allowed for Kerberos
  https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos

Client SupportedEncryptionTypes RC4Only

Zu DES beim AD-Objekt folgt später noch einer Testserie. Zuerst habe ich den Client auf RC4 eingebremst.

Windows Registry Editor Version 5.00

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

Die Konfiguration "supportedencryptiontypes" habe ich danach wieder leer gemacht, so dass der Default beim Client genutzt wird.

Server SupportedEncryptionTypes RC4Only

Nach den DES Only Tests lassen wir nun das wahrscheinlich unsichere RC4 zu

DC mit RC4_HMAC_MD5

Nun habe ich den Server angewiesen, er möcht doch bitte nur RC4 machen.

Windows Registry Editor Version 5.00

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

AD: msds-supportedencryptiontype

Kommen wir nun zu den AD-Objekten. Wenn immer ein KDC ein Ticket für einen Service ausstellt, sucht er im Active Directory nach einem ServicePrincipalName und wertet das Feld "msds-supportedencryptiontype" aus. Dies hat daher direkten Einfluss auf die ausgestellten Tickets, die dem Anwender zugeleitet werden. Microsoft schreibt dazu:

Once your domain functional level (DFL) is 2008 or higher, you KRBTGT account will always default to AES encryption. For all other account types (user and computer) the selected encryption type is determined by the msDS-SupportedEncryptionTypes attribute on the account.  You can modify the attribute directly or you can enable AES using the checkboxes in the Account tab.
Quelle: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797

Die Einstellungen befindet sich am AD-Objekt zum Computer oder dem Dienstkonto, welches den SPN hat. Bei Benutzerkonten können Sie einen Teil der Einstellungen per MMC Active Directory Benutzer und Computer machen.

Die vier Felder würde 16 mögliche Varianten erlauben. Im Ergebnis wirken aber nur die beiden AES-Einstellungen auf das Feld "msds-supportedencryptiontype":

Wenn Sie einmal AES128 oder AES256 aktiviert und am Ende wieder deaktiviert haben, wird das Feld auf "0" gestellt und ist nicht mehr "leer" wie vorher. So können Sie nachträglich erkennen, bei welchen Objekten schon jemand nur über die GUI an den Einstellungen gedreht hat.

Die Einstellung "Use only Kerberos DES encryptiontypes for this account" setzt das Bit 21 (2097152dez) und "Do not require Kerberos preauthentication" das Bit 22 (4194304dez) im Feld "UserAccountControl".

Die Einstellmöglichkeiten über die MMC sind schon etwas beschränkt, so dass ich die Einstellung in der Regel immer direkt mache. Dabei kann ich dann auch Werte verwenden, die nicht über die GUI erreichbar sind. Siehe dazu den Abschnitt Wertebestimmung.

Noch einfacher geht es sogar per PowerShell mit "Set-ADComputer". Es gibt extra den Parameter "KerberosEncryptionType", der die Werte DES, RC4, AES128, AES256 annehmen kann.

# RC$ Only für einen Computer vorgeben
Set-ADComputer <computername> -KerberosEncryptionType RC4

# RC4 auf jeden Fall deaktivieren. Ist seit Nov2023 SecUpdate aber obsolet da 
neuer Default
Set-ADComputer <computername> -KerberosEncryptionType AES128,AES256

# Defaulteinstellungen wieder aktivieren
Set-ADComputer <computername> -KerberosEncryptionType 0
# oder
Set-ADComputer hyperv2 -clear msds-supportedencryptiontypes

Nur beim Auslesen werden dann wieder die numerischen Werte ausgegeben:

(get-adcomputer <computername> -Properties "msds-supportedencryptiontypes")."msds-supportedencryptiontypes"

• Set-ADComputer
  https://learn.microsoft.com/en-us/powershell/module/activedirectory/set-adcomputer
• Get-ADComputer
  https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputer

Bei Computerkonten fehlt die Karteikarte und es bleibt nur die direkte Bearbeitung mittels ADSIEDIT oder die erweiterte Anzeige in MMC für Benutzer und Computer.

Testserie mit msds-supportedencryptiontype

Die Testserie ist nun aber etwas vereinfacht, da ich nur noch die ausgestellten Tickets prüfen muss. Auch gibt es keine zwei Partner, die ich gegenseitig testen muss.

Zielserver im AD auf DES_CBC_CRC/DES_CBC_MD5

Alle Endpunkte sind erst einmal wieder auf "Default" gestellt, wie es bei vermutlich den meisten Firmen sein dürfte.

Übrigens hat diese Einstellung anscheinend keine Auswirkung auf die TGT-Tickets eines Anwender, der sich auf dem Server selbst anmeldet. Er bekommt weiterhin AES-Tickets

Zielserver im AD auf RC4_HMAC_MD5

Wenn DES wie erwartet nicht geht, habe ich als nächstes RC4 eingestellt.

Set-ADComputer hyperv2 -KerberosEncryptionType rc4

Zielserver im AD auf RC4, KDC auf AES128/AES256

Nun bleibt natürlich die Frage, ob dies auch noch möglich ist, wenn der KDC gar kein RC4 mehr nutzen darf.

Blackhat

Man muss kein Hacker sein, aber Vorträge auf der Blackhat liefert oft viele Hintergrundinformationen. Sie zeigen aber auch, dass gefährlich ist, schwache Verschlüsselungsverfahren oder unsichere Clients zuzulassen. Programme wie Mimikatz u.a. versuchen z.B. das TGT abzugreifen, um damit weitere Tickets ohne Beisein des Benutzers zu erstellen. Angreifer können aber auch PAC umgehen, wenn der DC PAC nicht erzwingt.

Watching The Watchdog: Protecting Kerberos Authentication with Network Monitoring
https://www.blackhat.com/docs/eu-15/materials/eu-15-Beery-Watching-The-Watchdog-Protecting-Kerberos-Authentication-With-Network-Monitoring-wp.pdf

Watching The Watchdog: Protecting Kerberos Authentication with Network Monitoring
https://www.youtube.com/watch?v=7qbSFYVQJ7A&ab_channel=BlackHat

Zwischenergebnis

Diese lange und intensive Testserie hat mir viele Erkenntnisse gebracht, die bei der Fehlersuche mit Kerberos und Windows, insbesondere mit "alten Clients", Fremdsystemen oder bei Überlegungen zur RC4-Abschaltung weiter helfen. Ich merke mir:

• Wenn zwei Partner keine gemeinsame Encryption-Suite finden, gibt es keine Tickets
  Das überrascht mich nicht aber wenn sie Vorgaben machen und jede Vorgabe ungleich Default ist immer ein Verbot bestimmter Suiten
• Windows macht kein DES-CBC-CRC oder DES-CBC-MD5
  Ich habe es in keinem Fall erreicht, dass die Angabe von DES auch zu einem Erfolg geführt hat. Allerdings gibt es Fälle, wo ein Client noch -CBC-MD5 anbietet. Der KDC ignoriert es aber Wer DES erzwingen will oder erwartet, bekommt kein Ticket
• RC4Only auf dem Server ist eine schlechte Idee
  Seit Windows 2008 Forest-Mode sind alle TGTs mit AES verschlüsselt. Wer AES auf dem KDC abschaltet, deaktiviert faktisch den KDC.
• Clients, die kein AES-KRGTGT verstehen sind raus
  Laut Kompatibilitätsmatrix kann Windows Vista und Windows 2008 und höher mit AES umgehen. Kniffliger wird es für ältere Windows Versionen (XP/2003 etc.) die kein Kerberos mehr nutzen können und auf SMB1 hoffen. Was aber auch hoffentlich abgeschaltet ist. Eventuell trifft es unpassend konfigurierte Linux-Systeme. Kontrollieren Sie einfach den beim KDC eingehende AS-REG /TGT-REG auf die angebotenen Verfahren.

Ich hoffe, dass diese Ergebnisse ihnen bei der Fehlersuche mit Kerberos weiter helfen.

Weitere Links

• Kerberos Lockscreen
• Kerberos Wireshark
• TLS Handshake mit NetMon
• TLS 1.2 Enforcement
• PPAC Signing mit Kerberos
• SMB1 Abschaltung
• Kerberos (Protokoll)
  https://de.wikipedia.org/wiki/Kerberos_(Protokoll)
• Further Exploration Of KB5019964 Kerberos Changes
  https://geekmungus.co.uk/?p=3593
• NetApp Running SMB Version 1 Impacted By Microsoft Windows (KB5019964) For CVE-2022-37967
  https://geekmungus.co.uk/?p=3532