Microsoft
Microsoft
Microsoft1 - Lets say , when applying Microsoft's January patch it would break the Kerberos authentication for Legacy OSes ? Any Security or Cumulative update installed on the domain controllers past October 2022 will have the code changes in place and when this happens yes legacy OS's 2003/XP and below are NOT going to work with Kerberos authentication. The KDC will still issue RC4 encrypted service tickets, however the session key within the service ticket MUST use AES256 encrypton which legacy OS's do not support.
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) ? No it will not fix this as this is not a service ticket issue this is a session key encryption issue.
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 ? You will need to determine what will need to be done to allow AES Service tickets. It could be that you just need to change the password. But if these are not windows vista/2008 or higher systems you might need to change MIT Kerberos configuration / Keytab files to include AES256 encryptoin.
how happened computer objects ? Again cannot answer this in general, there should not be a reason for any vista/2008 systems to have an issue but legacy OS and non-windows systems could have an issue.
rejoin ? Don't know
4 - Do I have to change the DefaultEncryptionType in the DCs registry settings ? When the January Cumulative / Security update is installed on the KDC's you should not need to do anything.
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? We are not entertaining customers with how to get RC4_HMAc_MD5 session keys working after this security update as it defeats what the security update is released for, and it would affect all users and computers in the domain.
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 ? Again you should not need to do anything after the January update as it should change the default encryption type supported when msDS-SupportedEncryptionTypes is blank (NULL) or set to 0.
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 ? This update and all later updates will cause legacy OS's to fail to authenticate via Kerberos authentication. We are currently NOT addressing workarounds with unsupported operating systems at this time, so creating a case asking for a workaround will not get you anything other than to document that you are having this issue. We are also not entertaining a workarounds for 3rd party devices / operating systems that do not support AES256 session keys either.
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 ? Again RC4 service tickets are going to be handed out, however the session key will be AES256 and if that is a legacy windows OS then it will fail authentiation (Typically with KRB_AP_ERR_MODIFIED).
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. No it does not revert to Pre-November updates. November updates and beyond have the Session key encryption type change implemented in them.
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 ? In correct it will start enforcing the new behavior.