Upgraded Windows DC and domain to 2025. I have a few 2022 21H2 servers having issues with drive mappings

Question

Every few days or so, My 2022 servers loose there mappings (Red X) on the drives. Sometimes I can click on them and they come back to green and sometimes a message pops up stating that the user can not logon from this Workstation which is BS. A reboot fixes. Now with that said I have narrowed it down to an event viewer event that has to do with LSA. Event ID 40970 "The Security System has detected a downgrade attempt when contacting the 3-part SPN" ldap/Servername.domainname/domainname@domainname "with error code "" The encryption type requested is not supported by the KDC. (0xc00002fd)"". Authentication was denied." I do not see any events on the Domain controller around the same times.

Then immediately after an error for Group Policy Event ID 1030. The processing of Group Policy failed..."

I am sure that this is the issue, I just don't know how to fix it.

Answer 1

Hello @Bill Whipple

Your Windows Server 2022 (21H2) servers are intermittently losing drive mappings, and you’ve correlated this with an LSA error (Event ID 40970) that states:

"The Security System has detected a downgrade attempt when contacting the 3-part SPN" … "The encryption type requested is not supported by the KDC. (0xc00002fd)"

This means that when those servers or their logon scripts try to authenticate using Kerberos (for example, when connecting to their mapped network shares via a Group Policy drive mapping), the client is requesting an encryption type that your updated Domain Controllers (now running Windows Server 2025 functional level) no longer support. In our environment, Windows Server 2025 has been hardened to allow only newer, stronger encryption types (such as AES128 or AES256), while older methods (like RC4) might be disallowed.

When the client requests an outdated encryption type, Kerberos rejects the request, and authentication for things like drive mappings fails—resulting sometimes in a “cannot logon from this Workstation” error and then a subsequent Group Policy processing error (Event ID 1030). A reboot forces a refresh of credentials, which is why sometimes the mappings come back temporarily.

Steps to Resolve the Issue

1. Verify and Update Kerberos Encryption Policies
   • Check Group Policy Settings: Go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options in your Group Policy Management Editor. Look for the policy: "Network security: Configure encryption types allowed for Kerberos" – Make sure that it allows only strong encryption types (AES128 and AES256) and does not include older or deprecated types such as RC4 or DES.
   • Local Registry Settings (if needed): On a problem server, open the Registry Editor and navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters If you have a value named SupportedEncryptionTypes, its value must represent the bitmask for the allowed encryptions. To allow AES128 (0x8) and AES256 (0x10) for example, the combined value would be (0x8 + 0x10 = 0x18). Note: If this value is missing or set to an old bitmask that includes RC4, update accordingly. Always back up the registry before making changes.
2. Examine the Service Principal Names (SPNs)
   • Run the command:

          setspn -L <ServerName>
     

     on the affected servers and on your Domain Controllers. Confirm that the SPNs (especially for LDAP, CIFS, etc.) are properly registered. Sometimes duplicate or misconfigured SPNs can prompt Kerberos to negotiate using fallback encryption types.
3. Force a Group Policy Update and Credential Refresh
   • On the affected servers, run:

          gpupdate /force
     

   • Also, consider logging off and back on (or scheduling a reboot after your changes); this ensures that any cached Kerberos tickets are refreshed with the correct encryption settings.
4. Check for Windows Updates
   • Ensure that all Windows Server 2022 (21H2) servers have the latest updates and hotfixes. Microsoft periodically releases updates to align Kerberos implementations and encryption settings. It’s possible that a recent update has tightened the encryption defaults on your DCs, necessitating changes on the clients.
5. Monitor and Validate
   • After implementing the above changes, monitor the Event Viewer for any recurrence of Event ID 40970 or Group Policy Event ID 1030 errors.
   • Validate that drive mappings are stable over the next few days. If the issue persists, a more detailed packet capture (using tools like Network Monitor or Wireshark) might reveal which authentication requests are requesting unsupported encryption.

😊 If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily. Thanks!

Answer 2

Is SupportedEncryptionTypes String with 0x18 or Dword with decimal value 18

Answer 3

OK So I did the Group Policy thing only and now I am locked out of my network,. No one can logon. I am getting either incorrect password on all logins from other machines or The encryption type requested is not supported. I do have another 2025 member server that I was able to install group policy management on and remove the object and then powershell the gpupdate on the domain controllers but still no way to get on to any computer after they logoff.

Answer 4

Well I was lucky enough to get in and remove the GPO I created that had the encryption and do a gpupdate. So I am back to square 1. But what I don't understand is I applied that GPO to only the DC computers, why did it affect some users and not some users. I was unable to login with the domain admin account I always use, but then I used a backup domain admin and that allowed me in to make the changes back to square 1. Then I was able to log back on with the domain admin I always use.