MicrosoftHi WillAftring - you say:
Kerb3961 still leverages existing Kerberos etype configuration group policy: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos. However, it no longer honors the legacy registry key path of:
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Lsa\Kerberos\Parameters
REG_DWORD SupportedEncryptionTypes
So where does Windows Server 2025 now look to see what encryption types it's allowed to use, if not that path? From my understanding that value controls which encryption types the machine will accept for Kerberos tickets (whatever is set here is propagated to the msDS-SupportedEncryptionType attribute on the machine account), and is different to DefaultDomainSupportedEncTypes which controls which encryption types to use if the machine doesn't specify a value on msDS-SupportedEncryptionType.
Eg if we want to be able to configure our DCs to only support AES encryption even if a client claims to only support RC4 via it's msDS-SupportedEncryptionType attribute, where do we do that?
MicrosoftHello!
>So where does Windows Server 2025 now look to see what encryption types it's allowed to use, if not that path?
Kerb3961 reads the Kerberos supported encryption types from the group policy configured registry key instead. The recommended way to write to this registry key is by creating a Network security Configure encryption types allowed for Kerberos - Windows 10 | Microsoft Learn group policy and applying it to the machine in question.
However, if for one reason or another you are unable to leverage the group policy user interface, this is the registry key that the policy ultimately writes to.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
REG_DWORD SupportedEncryptionTypes
That being said, I strongly recommend leveraging group policy if possible for ease of configurability going forward.