What happened to Kerberos Authentication after installing the November 2022/OOB updates?

Hi,

DC's are 2016 as is functional level.

DCs are 2016.

We have a legacy systems like XP,2000,2003,2008 server.

I know everyone says to decom the old servers, but our go live to replace them is like First week of april

I have not applied the patches to our DC. I also our network security:configure encryption types allowed GPO is NOT defined. and NOT configured DefaultDomainSupportedEncTypes registry.

 I have skipped November and December Updates. Now I will install January 2023 patch.

AFAIK , January 2023 update doesn't change any default behaviour.

My questions are :

1 - Lets say , when applying Microsoft's January patch it would break the Kerberos authentication for Legacy OSes ?

2 - In ADUC, can I resolve the issue by explictly setting RC4 (0x4 (RC4_HMAC_MD5)) in msDS-SupportedEncryptionTypes for the computer objects of the target ( legacy OS) ?

3- I have noticed that when I run the script I get a report that There are 63 objects that do not have AES Keys generated. How should I interpret this?
Only is it enough password reset ? how happened computer objects ? rejoin ?

4 - Do I have to change the DefaultEncryptionType in the DCs registry settings ?

HKLM\System\CurrentControlSet\Services\KDC
Value Type: REG_DWORD
Value Name: DefaultDomainSupportedEncTypes
Value : 0x3C ( AES256_CTS_HMAC_SHA1_96_SK (Session Key))

5 - AFAIK, Support for AES256_CTS_HMAC_SHA1_96_SK (Session Key) based session keys started with Windows Vista/2008, so any legacy OS prior to this date will not support this encryption type. is it enough below reg setting for legacy OS?

Value Name: DefaultDomainSupportedEncTypes
Value : 0x3C ( AES256_CTS_HMAC_SHA1_96_SK (Session Key))

6 - I have eliminated all legacy systems. After , For AES128_CTS_HMAC_SHA1_96 and AES256_CTS_HMAC_SHA1_96 support, I will set the value to: 0x18 for DefaultDomainSupportedEncTypes. Correct ?

7 - According to the MS, After November we do not allow RC4 Session keys to be used any longer. the KDC is only going to generate session keys that are AES256_CTS_HMAC_SHA1_96_SK (Session Key) Support for AES256_CTS_HMAC_SHA1_96_SK (Session Key) based session keys started with Windows Vista/2008, so any legacy OS prior to this date will not support this encryption type.
I have 2003 / 2000 legacy OS.

This patch will happen the issue with Windows Server 2000 / 2003. correct ?

8 -  I will be able to receive RC4 tickets on the legacy devices, but I won't be able to access the legacy devices from newer operating systems.  correct ?

9-   As far as I can tell, the OOB (and subsequent rollups, for now...) reverted the DCs to the pre-November behavior that will generate RC4 or AES keys as needed.

However, if I set DefaultDomainSupportedEncTypes, the patch seems to start strictly enforcing the post-November behavior described in their blog, of RC4 ticket + AES session if I don't have msDs-SupportedEncryptionTypes explicitly set on an AD object.  Correct ?

I ran the script, https://github.com/takondo/11Bchecker

Output :

Legacy OS detected: CN=srv01,CN=Computers,DC=contoso,DC=local
This OS is not compatible with the new behavior, and authentication to this computer will fail after installing Windows Update released on November 2022 or newer on DCs.
======================================

======================================
There were no objects with msDS-SupportedEncryptionTypes configured without any etypes enabled.
======================================

There are 63 objects that do not have AES Keys generated.
This can occur if the account's password has not been changed after adding Server 2008 or newer DCs
Authentication to this target can fail if AES is required by either the client or the KDC.
Please change/reset the accounts' password, and AES keys will be automatically generated.
Here are the objects with no AES keys

-----redacted for privacy-----

======================================
A common scenario where authentication fails after installing November 2022 update or newer on DCs is when DCs are configured to only support AES.
Example: Setting the 'Configure encryption types allowed for Kerberos' policy on DCs to disable RC4 and only enable AES

No DCs were detected that are configured for AES only
======================================

======================================
There are 57 objects that do not have msDS-SupportedEncryptionTypes configured or is set to zero.
When authenticating to this target, Kerberos will use the DefaultDomainSupportedEncTypes registry value on the authenticating DC to determinte supported etypes.
If the registry value is not configured, the default value is 0x27, which means 'use AES for session keys and RC4 for ticket encryption'
- If this target server does not support AES, you must set msDS-SupportedEncryptionTypes to 4 on this object so that only RC4 is used.
(Please consider working with your vendor to upgrade or configure this server to support AES. Using RC4 is not recommended)
- If this target server does not support RC4, or you have disabled RC4 on DCs, please set DefaultDomainSupportedEncTypes on DCs to 0x18
or msDS-SupportedEncryptionTypes on this object to 0x18 to specify that AES must be used. The target server must support AES in this case.
Here are the objects that do not have msDS-SupportedEncryptionTypes configured

-----redacted for privacy-----

======================================

======================================
There are 1 objects that are configured for RC4 only.
Authentication to this target can fail if AES is required by either the client or the DC.
We do not recommend the use of RC4. Please consider working with your vendor to upgrade or configure this server to support AES.
Here are the objects that are configured for RC4 only:
CN=srv111,DC=contoso,DC=local