Windows 2025 Domain with Windows 2022 member servers loosing (Red X) on Mapped drives overnight.

Hi bswhipp,

Based on the sequence of events you described, it really does point to a Kerberos encryption issue. The LSA warning with error code 0xC00002FD ("The encryption type is not supported by the KDC") indicates that during authentication, the Windows 2022 member server is attempting to use an encryption type that your Windows 2025 domain controller isn’t accepting. This mismatch can disrupt the secure channel, causing Group Policy refreshes to fail (as reflected in the subsequent Event ID 1030) and eventually leading to access issues on mapped drives — since the authentication tokens become invalid.

Here are some suggestions to troubleshoot and potentially resolve the issue:

• Confirm Kerberos Encryption Settings:
   – Check the msDS-SupportedEncryptionTypes attribute for your Windows 2022 member servers in Active Directory. Ideally, they should support strong encryption types like AES128 and AES256. If they’re defaulting to an older method (like RC4), the domain controller in Windows 2025 might be rejecting that as part of tighter security requirements.
• Review Group Policy and Local Security Policies:
   – Look for settings that control Kerberos encryption. There might be a policy (either local on the member server or via GPO) that explicitly restricts or allows certain encryption types. Ensure both domain controllers and member servers are aligned in their expectations.
• Update Domain Controllers and Member Servers:
   – Since Windows 2025 is relatively new, there might be patches or updates addressing these encryption negotiations. Verify that your Domain Controllers are fully up-to-date, as well as the affected Windows 2022 servers.
• Test Adjusting Encryption (Cautiously):
   – As a troubleshooting step, you might try temporarily enabling the older encryption type on one test server to see if it stops the downgrade attempt warning. (Keep in mind that enabling legacy algorithms like RC4 isn’t recommended for production, but it can help pinpoint the issue.)
• Registry Tweaks or Advanced Settings:
   – In some cases, adjusting registry settings under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters on the member server can help force the use of stronger encryption types. However, make sure to back up any settings before you make changes.

Since the mapped drives rely on consistent authentication, any disruption due to a Kerberos encryption mismatch can lead to errors like “You do not have access to logon from that workstation.” Rebooting temporarily clears the issue because a new sign-on reestablishes a secure session, but if the underlying encryption negotiation fails during a later refresh, the session will break again.

Given the complexity, if the issue persists, it might be a good idea to check Microsoft’s support channels or forums for any known issues or hotfixes regarding Windows 2025 environments interacting with older member servers.

Hope this helps clarify the scenario and points you in the right troubleshooting direction. Let me know if you need further guidance or if there are new developments!

ChatGPT

How do you check the encryption types? I ran get-adcomputer -properties msDS-SupportedEncryptionTypes -filter * and it shows 28 for all. Is that what I am to look for?
I don't think I set any GPO for this, where would i look?
All servers are up to date from Microsoft Windows update

Hi bswhipp,
Yes, checking the msDS-SupportedEncryptionTypes attribute is the correct approach. A value of 28 means the computer account is configured to support the combined encryption types represented by the bitmask:

• 
  [] 4 for RC4_HMAC
  [] 8 for AES128_CTS_HMAC_SHA1_96
• 16 for AES256_CTS_HMAC_SHA1_96

In decimal, 4 + 8 + 16 = 28, so that indicates your computer accounts are set for RC4, AES128, and AES256. This is typically what you'd expect unless you or a policy has specifically modified this to exclude certain encryption types.
Regarding Group Policy settings:

• 
  [] There isn’t usually a specific GPO for configuring Kerberos encryption types. These settings are generally managed via Active Directory attributes (like msDS-SupportedEncryptionTypes) or, in more advanced setups, through registry modifications (for example at HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters on the domain controllers or member servers).
  [] In your case, if you haven’t manually set anything in GPOs related to Kerberos or encryption, then the default behavior is being applied.

Since you’re seeing an error about “The encryption type is not supported by the KDC” on your Windows 2022 member servers, it could be that the Windows 2025 domain controllers are now enforcing stricter policies. One troubleshooting step could be to test changing the msDS-SupportedEncryptionTypes on a test computer to only include AES (AES128 and AES256). That would be a value of 8 + 16 = 24 instead of 28 (thereby excluding RC4). However, please be very careful with this change and test it in a non-production environment first, since removing RC4 may impact clients or services that still rely on it.
I hope this helps clarify what you’re seeing and where to look. Let me know if you have any more questions or need further assistance!