Kerberos RC4 Abschaltung

Die zur Authentifizierung genutzten Kerberos Tickets werden digital signiert und verschlüsselt. DES, RC$, AES sind übliche und unterschiedlich sichere Algorithmen. DES ist unsicher und auch RC4 darf wohl als geknackt gelten, so dass heute AES gesetzt sein sollte. Diese Seite begleitet den Wechsel von DES/RC4 zu AES.

Auch wenn RC4 noch unterstützt wird, sollten sie schauen, dass Sie RC4 loswerden, ehe die Abschaltung irgendwann per Update erzwungen wird.

Diese Seite beschreibt am Anfang noch die Änderungen seit Nov 2022 und danach die Schritte zur geplanten RC4-Abschaltung.

Beachten Sie dazu auch die Seite Windows Security Changes 2023

Nov 2022 Probleme mit AES-Wechsel

Mit Windows 2000 wurde erstmals Kerberos zur Authentifizierung bereitgestellt aber schon mit dem Wechsel auf Windows Vista/Windows Server 2008 wurde DES per Default deaktiviert. Mit dem Windows Security Update Nov 2022 hat Microsoft RC4 zwar nicht abgeschaltet aber als neue Standard-Einstellung für ausgestellte Kerberos-Tickets nutzt. Diese Änderung habt aber durchaus Einfluss auf bestehende Umgebungen, wenn dort ältere Windows Systeme oder 3rd Party Lösungen integriert sind. Es kann an mehreren Stellen knirschen.

Das Schaubild zeigt die grundlegende Funktion eines Zugriffs des Clients zum Service. Wir gehen davon aus, dass der Client bereits angemeldet und ein gültiges Ticket Granting Ticket (TGT) hat wo natürlich auch schon RC4/AES-Probleme auftreten könnten:

  1. Anonymer Zugriff:
    Der Client weiß noch nicht, was der Server kann und greift anonym zu und fängt sich eine "Access Denied"-Meldung ein, die aber u..a die Information enthält, dass eine Anmeldung mit einem Kerberos Ticket möglich ist
  2. Ticket Request
    Der Client geht nun zum KDC um ein Ticket zu bekommen
  3. KDC erstellt Ticket
    Dazu sucht er das Konto anhand des angefragten SPN und wertet dort aus, welches Verfahren dieser Services unterstützt. Wenn nichts hinterlegt ist, dann ist das früher RC4 gewesen und seit Nov 2022 nun AES265. Sie können pro Konto aber Einfluss auf das ausgestellte Ticketformat nehmen.
  4. Ticket geht zum Client
    Das AES-Ticket landet nun bei Client. Ich hoffe ihr Client ist "jung" genug, dass er das Ticket verarbeiten kann. Ein Administrator kann hier aber z.B. AES auch irrtümlich deaktiviert haben. Sehr alte Systeme (z.B.: Windows 2000/XP können aber kein AES)
  5. Client mit Serviceticket zum Server
    Der Zugriff enthält nun das AES-Ticket, welches der Server decodieren und verstehen muss. Auch hier können aktuelle Windows Server meist damit umgehen aber bei Kunden hat mit SAMBA-Servern, NetApp-Boxen Apache etc. Probleme gegeben, wenn AES nicht konfiguriert war oder eine sehr alte Version im Einsatz war.

Dies ist nur die Beschreibung von Kerberos mit einem Client, Service und KDC. RC4 und AES kommen z.B. auch bei Windows Trusts zwischen Domänen vor. Siehe dazu auch die Seiten:

Lösung des AES-Problems

Wenn alle Clients und Server bereits Windows Vista oder neuer sind und per Gruppenrichtlinie nichts vorgegeben haben, dann sollte es keine Probleme geben. Wenn aber die ein oder andere Anmeldung z.B. an einem Webserver o.ä., nicht mehr möglich ist, dann kann hier eine mögliche Lösung für das Problem beschrieben sein:

  • Alle machen AES
    Sorgen Sie dafür, dass alle Clients und Server mit AES265 umgehen können, dann sind sie "am sichersten" und haben keine Probleme. Das funktionierst seit Windows Vista aber prüfen Sie die Gruppenrichtlinien, ob Sie die Verschlüsselungsverfahren vielleicht eingeschränkt haben. Es ist falsch auf dem Domain Controller und den Clients das AES-Verfahren abzuschalten, nur weil es ein Service nicht kann. Hier ist der korrekte Wet die Konfiguration der Verfahren auf dem AD-Objekte mit dem SPN.
  • Downgrade auf RC4
    Wenn Sie einen Service haben, der AES nicht kann und auch nicht aktualisiert oder anders konfiguriert werden kann, dann suchen Sie das Dienstkonto zu dem Computer oder Service anhand des Service Principal Namens (Siehe Kerberos SPN) und setzen Sie dort die Verschlüsselung auf einen kompatiblen Wert.
  • Windows 2000/XP-Clients
    Sollten Sie immer noch solch alte Clients haben, die kein AES unterstützen, dann müssen Sie auf AES verzichten. Sie können DCs durchaus dazu bringen auch nach der Installation der Security Updates vom November 2022 weiter mit RC4 zu arbeiten. Mit einer späteren Abschaltung von RC4 ist hier natürlich dann das finale Ende erreicht. Windows XP unterstützt sogar AES265 in SessionEncryptionkeys aber nicht bei Tickets

Eine Deinstallation des Nov 2022 Security Updates ist aus meiner Sicht keine Lösung. Zumal sie dann auch kein nachfolgendes Update mehr installieren dürfen, bis Sie alle Altlasten beseitigt haben.

Aber bis dahin können Sie durchaus eine Zusammenarbeit hinsichtlich Kerberos erreichen. Windows 2000 und Windows XP werden aber im Sommer 2023 dann durch die Aktivierung von RPC Sealing und PAC Signing wohl nicht mehr mitspielen dürfen. Höchste Zeit diese alten Systeme abzulösen oder aus der Domain in Einzelhaft zu verlagern und nur über kontrollierte Kommunikationswege einzubinden.

Kompatibilität

Microsoft hat schon deutlich dokumentiert, welches Produkt mit welchem Verfahren zurecht kommt. Die Einstellung befindet sich in der Gruppenrichtlinie, mit der sie auf Servern und Clients die erlaubten Verfahren konfigurieren können.

Diese Tabelle gibt die Default Einstellungen nach Betriebssystem zum Stand Feb 2023 wieder und bezieht sich auf das Kerberos Ticket Encryption aber nicht auf die SessionKeyEncryption

Betriebssystem DES_CBC_CRC DES_CBC_MD5 RC4_HMAC_MD5 AES128_HMAC_SHA1 AES256_HMAC_SHA1

Windows 2000

Supportet

Supportet

Supportet

Kein Support

Kein Support

Windows XP

Supportet

Supportet

Supportet

Kein Support

Kein Support

Windows 2003

Supportet

Supportet

Supportet

Kein Support

Kein Support

Windows Vista

Supportet

Supportet

Supportet

Supportet

Supportet

Windows 2008

Supportet

Supportet

Supportet

Supportet

Supportet

Windows 7

Deaktiviert

Deaktiviert

Supportet

Supportet

Supportet

Windows 2008R2

Deaktiviert

Deaktiviert

Supportet

Supportet

Supportet

Windows 10

Deaktiviert

Deaktiviert

Supportet

Supportet

Supportet

Windows 2012

Deaktiviert

Deaktiviert

Supportet

Supportet

Supportet

Windows 2012R2

Deaktiviert

Deaktiviert

Supportet

Supportet

Supportet

Windows 11

Deaktiviert

Deaktiviert

Supportet

Supportet

Supportet

Samba

Deaktiviert

Deaktiviert

Supportet

Supportet

Supportet

NetApp

Aktiv

Aktiv

Aktiv

Deaktiviert!

Deaktiviert!

Apache

Konfiguration

Konfiguration

Konfiguration

Konfiguration

Konfiguration

Für Systeme wie z.B. Apache habe ich keine Default-Einstellung gefunden, da Sie bei der Einrichtung hier explizit etwas konfigurieren müssen.

Auch wenn sie DES bei neueren Versionen per Gruppenrichtlinien reaktivieren könnten, rate ich davon dringend ab. DES ist nicht sicher!

Achtung: Windows 2000/XP/2003 verstehen kein AES und können auch nicht mehr aktiviert werden

However, since Windows 7 and Windows Server 2008 R2, DES_CBC_CRC and DES_CBC_MD5 are no longer supported as supported Kerberos encryption types
Quelle: https://dirteam.com/sander/2022/11/08/spend-some-time-on-properly-configuring-and-monitoring-your-domain-controllers-this-patch-tuesday/

To take advantage of the strongest security with Kerberos-based communication, you can enable AES-256 and AES-128 encryption on the SMB server. If you do not want the SMB server to select the AES encryption types for Kerberos-based communication with the Active Directory (AD) KDC, you can disable AES encryption. By default, AES encryption is disabled.
Quelle:https://docs.netapp.com/us-en/ontap/smb-admin/enable-disable-aes-encryption-kerberos-task.html

SupportetEncryptionTypes

Die Standardeinstellungen greifen natürlich nur, wenn Sie nicht die Konfiguration der Clients und Server durch die Registrierung oder Gruppenrichtlinien beeinflusse. Maßgeblich ist dazu der folgende Schlüssel:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\parameters]
„SupportetEncryptionTypes"=dword:00000024

Jedes Bit hat dabei eine besondere Bedeutung:

Bit dez-Wert hex-Wert Verfahren

0

1

0x01

DES_CBC_CRC

1

2

0x02

DES_CBC_MD5

2

4

0x04

RC4

3

8

0x08

AES128

4

16

0x10

AES256

Die weitere Bits sind für zukünftige Verfahren reserviert. Wen Sie also zur AES128/AES265 zulassen, dann ist 24dez der richtige Wert RC4 ist dann auch abgeschaltet. Die Einstellung ist über Gruppenrichtlinien sehr einfach zu setzen. Die folgende Einstellungen entspricht der Standardeinstellung und erlaubt AES127, AES256 aber auch RC4.

Diese Einstellung hat aber nichts mit "Default Encryption Typ" zu tun. Sie könnten Damit aber temporär z.B. AES128/AES256 blockieren. Das ist aber der falsche Weg.

Microsoft empfiehlt die Einstellung komplett zu deaktivieren, also nicht zu konfigurieren. Das ist auch meine Empfehlung, damit Sie sich vielleicht nicht mal selbst aussperren, wen zwei Systeme nicht zueinander kompatibel sind.

Audit: SPN-Konto und msDS-SupportedEncryptionTypes

Am Anfang der Seite habe ich beschrieben, dass der KDC im Active Directory anhand des "ServicePrincipalName" nach dem Konto sucht, um das Kerberosticket damit zu verschlüsseln. Über dieses Konto können Sie als Administrator dem KDC mitteilen, welche Verschlüsselungsverfahren das System versteht. Normalerweise ist das Feld leer und der KDC nutzt sein "Default Verfahren". Genau das wurde aber im November 2022 von RC4 auf AES256 umgestellt und wenn bislang andere Dienste mit RC4 zufrieden waren aber AES nicht verstehen, dann ist das der Ort um das Problem für genau diesen einen Dienst zu beseitigen. Sie schwächen damit nicht die gesamte Umgebung, die weiterhin AES nutzt aber die Tickets für diesen einen Dienst sind dann natürlich wieder mir RC4 codiert.

Einen Teil der Konfiguration können Sie über Active Directory Benutzer und Computer einstelle. Als RC4 noch der Default war, konnten S hier z.B. AES128/AES256 aktivieren oder auch ein Downgrade auf DES erzwingen. Microsoft hat hier aber keinen eigenen Eintrag für z.B. RC4 in der GUI vorgesehen.

Wenn Sie nun also für einen Service die Nutzung von RC4 vorschreiben wollen, dann bleibt nur die Konfiguration des entsprechenden Feldes:

Bei den meisten Objekten sollte das Feld leer sein, damit die Standardwerte greifen. Wenn Sie nun aber RC4 vorgeben wollen dann müssen Sie ein 04dez als Werte eintragen. Auch hier gibt es wieder eine Bitmaske analog zu "SupportetEncryptionTypes" der Gruppenrichtlinien.

Bit Dez-Wert Hex-Wert Verfahren

0

1

0x01

DES_CBC_CRC

1

2

0x02

DES_CBC_MD5

2

4

0x04

RC4

3

8

0x08

AES128

4

16

0x10

AES256

Sie können auch "07dez" eintragen um neben RC4 auch beide schwächeren DES-Varianten zuzulassen. Allerdings müssen Sie dann auch auf dem Client und KDC das Feld "SupportetEncryptionTypes" entsprechend anpassen, dass auch DES erlaubt wäre. Eine Suche nach solchen Objekten ist dann per AD-PowerShell schnell gestartet

Get-ADObject `
   -Filter "msDS-SupportedEncryptionTypes -bor 0x7 -and -not msDS-SupportedEncryptionTypes -bor 0x18"

Dieser Aufruf zeigt alle Clients, die DES oder RC aktiv haben und explizit kein AES erlauben. Sie können auch einfach alle Elemente ausgeben, die manuell konfiguriert sind.

Get-ADObject `
   -Filter "msDS-SupportedEncryptionTypes -bor 0x1f"

Bitte aktivieren Sie nicht DES_CBC_CRC oder DES_CBC_MD5

DC: DefaultDomainSupportedEncTypes

Auf auf dem KDC, d.h. auf jedem Domain Controller können Sie steuern, welches Verschlüsselungsverfahren er zum Ausstellen des Kerberos-Tickets nutzen soll, wenn beim SPN-Konto nichts hinterlegt ist.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC]
"DefaultDomainSupportedEncTypes"=dword:00000039

Diese Einstellung hat Microsoft mit dem Nov 2022 Update von RC4 auf AES geändert. Wenn Sie den Wert ändern wollen, dann müssen Sie diesen aus einer Tabelle ermitteln, bei der jedes Bit eine eigene Funktion hat. Die Änderungen werden ohne Neustart sofort aktiv.

Details zum Update RC4 auf AES

Das November 2022 Security Update hat eine ganze Menge an Korrekturen mitgebracht und der Wechsel von RC4 auf AES als Standardverschlüsselung bei Kerberos ist nur ein Teil in dem Paket. Microsoft hat noch zwei weitere kritische Lücken gesichert, die ebenfalls die alten Windows Betriebssysteme wie XP, 2003, 2000 und älter aussperren.

  • RPC Sealing
    RPC-Pakete, wie sie bei WMI, SMB, NETLOGON etc. genutzt werden, werden zukünftig besser gesichert. Im Nov 2022 Update ist die Basis gelegt aber im Laufe des Jahres 2023 werden die Einstellungen schrittweise erzwungen und können auch nicht mehr rückgängig gemacht werden
  • PAC Signing
    Auch das PAC im Kerberos-Ticket wird gegen Veränderungen besser gesichert. Auch hier wird mit dem Nov 2022 Update die Basis gelegt und im Laufe des Jahres 2023 schrittweise erzwungen und können ebenfalls nicht rückgängig gemacht werden.

Diese Änderungen sind doch recht tiefgreifend und für die Sicherheit erforderlich. Allerdings sind auch hier ältere Betriebssysteme dann außen vor und können nicht mehr mit den aktualisierten Servern kommunizieren..

Siehe dazu auch Windows Security Changes 2023

Es gibt daher für den Nov 2022 Update ein "Out of band" Hotfix, um Probleme bei betroffenen Umgebungen zu lösen.

Allerdings löst das nicht auf allen Umgebungen die Probleme, speziell wenn Systeme nur RC4 können und ihre Clients AES anfordern und bekommen. Sie könnten nun z.B. per Gruppenrichtlinie alle Clients anweisen, RC4-Tickets anzufordern. Ratsam finde ich das nicht. Die Schlüssel sind eher interessant, um nur sichere Verfahren zuzulassen.

Audit: klist - Kontrolle auf dem Client

Wenn Sie nun ihre Konfiguration entsprechend umgesetzt haben dann sollten Sie auf einem Client einfach mit KLIST die erhaltenen Kerberos-Tickets für den Benutzer und den entsprechenden Service kontrollieren:

Sie sehen hier direkt das genutzte Verfahren. Dies ist insbesondere hilfreich, wenn Sie auf den Service nicht zugreifen können. Wenn Sie kein Kerberos-Ticket bekommen, dann hat der Service entweder gar nicht mitgeteilt, dass er "NEGOTIATE" anbietet oder der Client konnte den KDC nicht fragen oder KDC hat den SPN nicht gefunden. Wenn der Client aber ein Ticket hat, dann sind all diese Punkte erledigt und es stellt sich nur noch die Frage, warum der Service das Ticket nicht akzeptiert.

Audit: KDC Eventlog

Der zweite Ort ist das Eventlog, welches Sie auf dem DC, genauer dem KDC, erst noch aktivieren müssen. Ich nutze dazu gerne die "Default Domain Controller"-Policy, damit alle Server auch abgedeckt sind.

Sie finden dann auf den Servern, die als Kerberos Distribution Center (KDC) genutzt werden, d.h. alle DCs, verschiedene Meldungen im Security Eventlog. Dort suchen Sie dann nach Meldungen der EventID 4768 und werten den "Ticket Encryption Type" aus.

Ticket Encryption Type (hex) Ticket Encryption Type (Dez) Status Beschreibung

0x1

01

DES-CBC-CRC

Sollte nicht erscheinen, da es seit Windows 7 / Windows 2008R2 by Default deaktiviert ist

0x3

03

DES-CBC-MD5

Sollte nicht erscheinen, da es seit Windows 7 / Windows 2008R2 by Default deaktiviert ist

0x11

17

AES128-CTS-HMAC-SHA1-96

Seit Windows 2008/Vista möglich und "sicher"

0x12

18

AES256-CTS-HMAC-SHA1-96

Seit Windows 2008/Vista möglich und "sicher"

0x17

23

RC4-HMAC

Standardverfahren vor Windows 2008/Vista und immer noch möglich

0x18

24

RC4-HMAC-EXP

Standardverfahren vor Windows 2008/Vista und immer noch möglich

0xFFFFFFFF

 

-

Fehlermeldung

Sie sehen aber auch, dass seit Windows 2008/Vista schon AES128/AES256 der Standard ist und mittlerweile alle System es können. Wer heute noch RC4 nutzt, sollte prüfen warum dem so ist.

# Suche nach TGT Ausstellung
Get-WinEvent `
    -LogName Security `
    -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=4768)]]" `
| where {$_.properties[7].value -notin (17,18)}
# Suche nach Ticket Ausstellung
Get-WinEvent `
    -LogName Security `
    -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=4769)]]" `
| where {$_.properties[5].value -notin (17,18)}

Denken Sie daran, dass Sie vielleicht die Größe des Security-Eventlog vergrößern müssen, um länger in die Vergangenheit zu blicken.

Bei der Menge der Events ist es sicher nicht sinnvoll, jedes mal per Event Action ein PowerShell-Skript zur Meldung zu starten. Da gibt es andere Weg wie Event Subscriptions, Syslog-Forwarding, SIEM etc.

gMSA und SupportedEncryptionType

Bei der Installation des AzureAD Cloud Sync auf einem DC, bei dem SupportedEncryptionTpe=0x18, also AES128/AES256, stand, konnte AzureAD Connect Cloud Sync kein GroupManagedServiceAccount anlegen.

Zuerst war ich unschlüssig, woran es lag aber im Eventlog habe ich dann auch eine passende Meldung gefunden:

Log Name:      Microsoft-Windows-Security-Netlogon/Operational
Source:        Microsoft-Windows-Security-Netlogon
Event ID:      9002
Task Category: MSA
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      DC01.carius.de
Description:
Netlogon failed to add provAgentgMSA$ as a managed service account to this local machine. The provided context did not match the target.

Die ersten Treffer der Suchmaschine haben schon den richtigen Hinweis gegeben:

A managed service account is dependent upon Kerberos supported encryption types.When a client computer authenticates to a server using Kerberos the DC creates a Kerberos service ticket protected with encryption both the DC and server supports. The DC uses the account's msDS-SupportedEncryptionTypes attribute to determine what encryption the server supports and, if there is no attribute, it assumes the client computer does not support stronger encryption types. If the host is configured to not support RC4, then authentication will always fail. For this reason, AES should always be explicitly configured for MSAs.
Quelle: https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview#BKMK_SOFT

Ich muss hier zumindest temporär RC4 aktivieren, damit das Setup das Konto anlegen kann. Danach sollte ich aber auf dem gMSA den EncryptionType aus AES stellen.

Set-ADServiceAccount `
   -Identity provAgentgMSA `
   -KerberosEncryptionType AES128,AES256

Überwachen und Anpassen

Nun heißt es etwas "warten" und kontrollieren und anpassen. Sie müssen quasi jedem Event aus dem Eventlog nachgehen, warum ein Client vom KDC ein RC4/DES-Ticket für einen Service angefordert hat und die Ursache finden und beheben. Das ist eine mühsame Arbeit, insbesondere wenn 3rd Party-Produkte involviert sind, die per KEYTAB und anderen Einstellungen mit dem Active Directory verbunden wurde.

Moving forward with enforcing AES for Kerberos will require analysis and one of the best inputs for that assessment are 4769 events from the domain controller security log which show the encryption type (Ticket Encryption Type field) of issued service tickets. Event 4768 will show the same information for issued TGTs. If you have the luxury of having centralized log collection and analysis tool, then getting a quick handle on your ticket encryption types will be achievable
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797

Knifflig wird es mit Client und Services, die kein AES128/AES256 können und nur RC4/DES verstehen. Dazu gehören z.B.: Windows XP und ältere Versionen, die maximal RC4 verstehen.

Ich weiß auch, dass es immer wieder Spezialfälle gibt, bei denen so alte Systeme noch genutzt werden und nicht einfach ersetzt werden können. Da hilft auch die Drohung mit "kein Support, Keine Security Updates" nicht weiter und die Firmen werden schon selbst solche Geräte in ein eigenes Subnetz mit strenger Abschottung verbannt haben.

Aber wenn sie ihr aktive primäres Active Directory auf AES umstellen und vielleicht auch noch TLS 1.2 erzwingen, SMB 1 abschalten, NTLMv1 und BasicAuth verbieten und andere Mindestvorgaben umsetzen, dann werden diese alten Schätzchen nicht mehr mitspielen. Einen allgemeinen Plan B gibt es hier leider nicht. Natürlich können Sie auf Kerberos verzichten und hoffen, dass eine Anmeldung per NTLMv2 noch möglich ist. Vielleicht läuft es am Ende auf ein wirklich komplett abgeschottetes eigenes Netzwerk hinaus, zu dem es nur ganz wenig klar definierte Übergabepunkte gibt die keine der beiden Seiten in Gefahr bringt.

Sonderfall XP

Natürlich ist Windows XP schon lange nicht mehr supportet aber das soll auch nur ein Beispiel sein . Es könnte auch ein Samba-Server o.ä. sein. Als die Windows Security Changes 2023 installiert wurden, trat folgendes Fehlerbild in Erscheinung:

Richtung

Status

Beschreibung

XP-Client ->  Windows Server 2016

OK

Der Windows XP Klient kann ein AES und erhält vom DS noch ein RC$-Ticket, weil AES nicht erzwungen ist. Der Client kann damit auf den Server zugreifen.

Windows Server 2016 -> Windows XP Client

Fail

Natürlich ist ein Windows XP-System kein "Server" aber es kann ja sein, dass ein Administrator aus der Ferne auf einen Client per "C$" zugreifen möchte. Auf einem neuen Client bekommt der Administrator ein AES-Token für den Client. Windows XP versteht aber kein AES und die Verbindnug kommt nicht zustande.

Dieses Problem können Sie gut mit KLIST auf dem Admin-Client sehen, welcher ein AES-Token hat:

Auch ohne RC4-Abschaltung kann schon der Wechsel des Default Verfahrens zu Problemen beim Zugriff auf alte Systeme führen. 

Aber selbst dann kann es passieren, dass ein Windows XP Gerät im Active Directory mittels msds-supportedEncryptionType=4 einen RC4 Ticket bekommt aber sie dennoch nicht auf den Windows XP Client remote zugreifen können. Dann kann es daran liegen, das der Session Key dennoch AES ist.

Windows XP ist nun mal kein guter Server und dieses Problem können Sie nur lösen, indem Sie auf RC4 als Default zurückstellen.

... Server 2000, Server 2003 and XP do not support either version of AES. Therefore, if you have those legacy operating systems still in your domain you are not ready to remove RC4 support from your domain controllers.
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797 

RC4 deaktivieren

Wenn Sie sichergestellt haben, dass kein Computer/Benutzer-Objekte mehr RC4 oder DES anfordert und auch das Eventlog über einige Zeit hinweg keine RC4/DES-Tickets mehr ausgestellt hat, dann können Sie im nächsten Schritt auf allen Domain Controllern die Nutzung von RC4 deaktivieren. Dazu ist mindestens Windows 2008 und Windows Vista erforderlich. Frühere Versionen von Windows können noch kein AES. Aber heute sollten alle Versionen mit AES zurecht kommen.

Prüfen Sie bitte das Kennwort ihres KDC-Service Account und führen Sie ggfls. einen KRBTGT Key Rollover durch. Speziell wenn das Kennwort vor 2005 gesetzt wurde kann dies die Nutzung von AES blockieren.

Für Windows 2012/2012R2 Domain Controller benötigen Sie ggfls. einen Hotfix:

Sie können auch diese Härtung aber schrittweise umsetzen, indem Sie nicht gleich auf dem DC die Nutzung von RC4 abschalten, sondern per Gruppenrichtlinie auf den Clients die Nutzung von Kerberos auf AES128/AES256 und neuer beschränken:

GPO: Computer Configuration\Windows settings\Security Settings\Local Policies \Security Options

Damit verhindern Sie auf den so konfigurierten Clients und Servern die Nutzung von RC4 und DES. Die Einstellungen landen in der Registrierung unter:

Windows Registry Editor Version 5.00

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

Achtung: Stellen Sie den Werte nie auf "1" oder die GPO nur auf "DES_CBC_CRC" denn dieses Verfahren ist zumindest bei Windows 2016 deaktiviert. Siehe auch Kerberos Encryption. Selbst die Einstellung "3", die "DES_CBC_MD5" erlauben sollte, bringt einen Server nicht dazu, damit zu antworten.

So können Sie schnell kontrollieren, ob die Richtlinie gezogen hat. Den Schlüssel manuell zu setzen ist nicht empfehlenswert, da Richtlinien überschreibend wirken.

Weitere Links