Microsoft
Microsoft
MicrosoftHey All
It's been really busy for us in Directory Services support, so I have not had any free time to get to these questions. Let's see if I can get all these questions answered since Jan24th.
From MaxC0der:
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 authentication (Typically with KRB_AP_ERR_MODIFIED).- Now, I can login with my domain user to the legacy OS ? right? Just I won't be able to access the legacy devices from newer operating systems such as file share.
Also, will it work vice versa such as file share access from legacy OS to newer OS ?
So, the answer is that the KDC will hand the user a Kerberos ticket that still has the Session Key encrypted with AES256. So if the end application servers Kerberos client DOES NOT understand AES256 it will not work. It does not matter what OS version requests the Kerberos ticket it is the function of the KDC to generate the Session Key and then for it to encrypt it.
2- There are on service accounts which have a SPN set such as ADFS , SCCM.Is there any extra setting for this ?
also , defined as not set for msDS-SupportedEncryptionTypes.
e.g SCCM Account :
is it occurring any Kerberos authentication issue?
We have not changed how Kerberos works. Service Principal name values that are required are application specific and not tied to Kerberos client or KDC. So there is nothing changing this with this update.
from Marc Laflamme:
One of the objects detected in our environment that do not have msDS-SupportedEncryptionTypes configured or is set to zero is the Azure AD SSO Account which was created during installation of Azure AD Connect. How can I ensure that our AD Connect won't break when this is enforced?
This unfortunately would be better answered b y Azure AD Connect support team. Keep in mind that if it is NULL / 0 for the attribute The KDC follows the default behavior listed in the blog here. If the KDC has the DefaultDomainSupportedEncTypes then it would use one of those encryption types.
From R_INNOXY:
Another question: For AES128_CTS_HMAC_SHA1_96 and AES256_CTS_HMAC_SHA1_96 support, you would set the value to: 0x18
Why 0x18 and not 0x38 for DefaultDomainSupportedEncTypes?
0x18 is AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96
0x38 is 0x18 is AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96-SK
This is a very good question. However there are certain things that we are not allowed to talk about.
@MikeUnibz
Thank you so much for your efforts on the XML query text and giving back to the community.
from UncleJBones916
Hope this thread is still alive...
I have installed all current updates on my 2016 DC's, levels are 2008 r2. I am receiving Event ID 42, none of the others. The GPO is not configured, nor defined. I have run, the command.
If you are getting an Event 42 it is most likely that you just need to update / change the user password from a computer that has the supported encryption types enabled on them and that should resolve the issue once AD replication happens.
You also might want to look at the last time the password was changed on the account via: Repadmin /ShowObjMeta [DC NAME] "DN OF USER OBJECT"
there are three attributes you can look at: unicodePwd, dBCSPwd, pwdLastSet
Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= === =========
16497 Default-First-Site-Name\FAB-RT-DC01 16497 2022-07-15 19:29:18 2 dBCSPwd
16497 Default-First-Site-Name\FAB-RT-DC01 16497 2022-07-15 19:29:18 2 unicodePwd
the Ver tells you how many times the attribute value has changed, and the org.Time/Date tells you the last time the attribute was changed on the object.
If this is the krbtgt account, I would recommend that you follow the following article to update the password.
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/faqs-from-the-field-on-krbtgt-reset/ba-p/2367838
https://www.microsoft.com/en-us/security/blog/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/
From KenFarrell:"My devices running an unsupported version of Windows are no longer able to access resources in my environment. Also, these devices are unable to be accessed from updated Windows devices in my environment. What can I do?
Unsupported versions of Windows includes Windows XP, Windows Server 2003, Windows Server 2008 SP2, and Windows Server 2008 R2 SP1 cannot be accessed by updated Windows devices unless you have an ESU license. If you have an ESU license, you will need to install updates released on or after Novem...Next Steps Install updates, if they are available for your version of Windows and you have the applicable ESU license. If updates are not available, you will need to upgrade to a supported version of Windows or move any application or service to a compliant device."
I am trying to understand the impact as we do not have or have ever had ESU. I know 2003 Server will be broken after 11th of April as the krbtgtFullPacSignature=0 key will be gone (or moved to 1), we are currently using DES on User accounts to get us past the RC4 issue.
Would it be possible to tell me the impact and timeline for 2008 and 2008 R2 that were last patched 14/01/2020?
So the simple answer is you should be replacing any currently unsupported operating system that you have. Microsoft IS NOT testing security updates or changes to currently supported operating systems for functionality with these operating systems.
The IMPACT is that any legacy OS XP/2003 and older will fail Kerberos authentication and there is nothing that can be done to make this work. We are not looking to make this work in any future security update release either. Windows Vista/2008 and higher operating systems DO support AES256 Session Keys and will continue to function. If you are having problems with a 3rd party appliance you need to speak to that vendor. If you are having a problem with Linux OS or Java application first thing is to contact the vendor and see what version of their product supports AES256 session keys. Then upgrade to that and I would assume you should be good. Or in some instances you might need to generate new Keytab files using KTPass.exe specifying the use of AES based Cryptography.
The November Kerberos security update that changes the Kerberos Session Key encryption type is not related to the PAC Signature changes that have been in the works now for over a year at this time. So, I guess I need to understand what you are wanting help with here. Again, though we are not going to be able to discuss anything related to 2003 and recent security changes. As far as the November Security update to change the Session Key encryption type to AES256 Windows Vista and higher will work fine with this. I would recommend that you either replace those operating systems (2003 / 2008 / 2008 R2) with a supported OS or move those systems to Azure IAAS solution as you do get ESU support (2008 R2 No support for 2003) for those OS's when running in the cloud.