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

Gilberto Lima de Oliveira 6 Reputation points
2022-12-22T01:55:54.397+00:00

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:
273095-share1.png

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.

273096-reg1.png

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

Active Directory
Active Directory
A set of directory-based technologies included in Windows Server.
5,832 questions
Windows Server Security
Windows Server Security
Windows Server: A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.Security: The precautions taken to guard against crime, attack, sabotage, espionage, or another threat.
1,721 questions
Windows Server Infrastructure
Windows Server Infrastructure
Windows Server: A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.Infrastructure: A Microsoft solution area focused on providing organizations with a cloud solution that supports their real-world needs and meets evolving regulatory requirements.
511 questions
{count} vote

4 answers

Sort by: Most helpful
  1. Marco Paglioni 26 Reputation points
    2023-01-12T11:52:20.89+00:00

    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?

    1 person found this answer helpful.

  2. Kevin M 5 Reputation points
    2023-02-04T18:44:02.36+00:00

    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!

    1 person found this answer helpful.
    0 comments No comments

  3. Demian Rodriguez 1 Reputation point
    2022-12-26T23:37:27.37+00:00

    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! :)

    0 comments No comments

  4. Sean O'Brien 11 Reputation points
    2022-12-29T14:06:33.503+00:00

    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--