Windows Server 2003 share fails to authenticate after install cumulative update 11-2022 on DCs

Question

Hi Everyone,

I had a issue on my environment after install cumulative update November 2022 on my Domain Controllers.
Clients running any version of Windows had a issue when try access network share or any resource use Kerberos when the server is Windows 2003
Example share:

On the client with this error, open cmd and run:
Klist
KRBTGT you will have a Ticket with encryption and Session key with AES-256-CTS-HMAC-SHA1-96
The SPN of the Windows Server 2003 will have a Ticket with encryption RSADSI RC4-HMAC(NT) and session key AES-256-CTS-HMAC-SHA1-96
Because the session key AES-256-CTS-HMAC-SHA1-96 this authentication fails
Windows Server 2003 doesn’t support this encrypt protocol on Kerberos
To mitigate this issue you can create Dword32 DefaultDomainSupportedEncTypes on the path HKLM:\SYSTEM\CurrentControlSet\Services\Kdc with value 0x7
The Default value after install KB 11-2022 is 0x27.
The explanation of value:

6cfc7b50-11ed-4b4d-846d-6f08f0812919

Convert to binary, check the bits will be enable and convert to Hexadecimal to set Dword DefaultDomainSupportedEncTypes.
In the simple way, 0x27 enable to force the Session key to be AES-256-CTS-HMAC-SHA1-96 when legacy encrypt protocol like RC4-HMAC(NT) is requested.

Reboot on DC is not required, but run the command klist purge (doesn’t execute as administrator, it need be run on the user session) on the client, or logoff and logon.
After change, the ticket and session key will be encrypted with RSADSI RC4-HMAC(NT) and the authentication will work normally.

If you have this issue with another unsupported operational System and doesn’t work after this change, try to add attribute msDS-SupportedEncryptionTypes with value 7 or 4 to computer object.
You can use the powershell command:
Set-ADComputer NameSERVERWithUnsupportedSO -Add @{'msDS-SupportedEncryptionTypes'=4}
Or
Set-ADComputer NameSERVERWithUnsupportedSO -Add @{'msDS-SupportedEncryptionTypes'=7}
I had this issue only with Windows server 2003 on my envionment, and I could not test this last solution.
More Details on:
3696351

Regard
Gilberto Lima

Answer 1

I can also confirm this worked for me. Before installing these updates in my prod environment I created a test environment that consists of a Windows Server 2012 R2 DC (fully patched), a Windows Server 2003 file server (fully patched), a Windows Server 2019 file server (fully patched), a Windows 7 client (fully patched), and a Windows 10 22H2 client (fully patched).

I added that registry entry --> HKLM\SYSTEM\CurrentControlSet\Services\KDC\DefaultDomainSupportedEncTypes with a value of 0x7 on the DC

and

On the computer object in AD for the Windows Server 2003 file server I gave the msDS-SupportedEncryptionTypes attirbute a value of 4.

On the Windows 7 and the Windows 10 client I'm getting appropriate Kerberos tickets for both the Windows Server 2019 file server (AES256 Kerberos tickets) and the Windows Server 2003 file server (RC4 Kerberos tickets).

Thanks for this post!

Answer 2

Thank you for sharing this information!

I was having problems with the November update and with this I was able to solve it.

Best regards! :)

Answer 3

Hi guys
i have the exact same problem, having 2 DC with 2019 and 2 machines with 2003R2.

I did add the registry value to both DC machines and they are now able to open shared folders on both 2003R2 machines
but all other win10/11 domain computers still arent able to. I did "klist purge", but after retrying, the klist still has AES-256-CTS-HMAC-SHA1-96 tickets

What i need to do?
simply wait? reboot clients? Change some reg keys on all of them? anything else?

Answer 4

Hello,

This has been detected and reported earlier in November. It seems that Microsoft have released already a fix, as documented in the Known Issues section of this rollup:

https://support.microsoft.com/en-us/topic/november-8-2022-kb5020019-monthly-rollup-092af8f8-a11d-4bb4-9612-b7cb74a254d6

------------------------------------------------------------------------------------------

--If the reply is helpful, please Upvote and Accept as answer--

Answer 5

Thank you for that tip.

In our case this solution solved the problem that was caused by some more recent Microsoft updates that disable RC4 encoding for Kerberos. One of our servers in local domain still required RC4 for authentication and by following exactly the instructions of this article and setting HKLM:\SYSTEM\CurrentControlSet\Services\Kdc\DefaultDomainSupportedEncTypes to 0x7 on domain controller restored access to still very much needed other server in local domain.