Does Microsoft KB5021131 break vCenter login?
Microsoft published a security update for Windows. If you see my blog posts, you will see, I am no Microsoft-guy. But there are some rumors about KB5021131. Does it break VMware vCenter login?
What is KB5021131 about
Microsoft will enforce applications to use the more secure AES algorithm for Kerberos encryption instead of the unsecure RC4-HMAC. For sure a good idea! Statement from KB5021131:
This update will set AES as the default encryption type for session keys on accounts that are not marked with a default encryption type already.
If you don’t know – as I did before I heard about this problem – you can configure encryption type for Active Directory (AD) objects individually. With KB5021131 there is a new registry-key (DefaultDomainSupportedEncTypes
) that can be used to defines the default, if no encryption type is set for an object.
When and why is it important
As you probably know, it is possible to join vCenter to a Microsoft AD domain. This is widely used. If you do so, VMware talks to AD for authenticating users. This is done by using Kerberos protocol. Therefore it can hit vCenter login when there are unwanted changes in the way Microsoft used Kerberos.
Configuration options
As mentioned, encryption can be configures for AD objects. Object attribute is msDS-SupportedEncryptionTypes
. Default is <not set>
. You can use Active Directory Users and Groups administration tool to change this attribute.
Note: Enable Advanced Features in View to show Attribute Editior.
Read more about supported encryption types and in more detail.
My tests and results
I did some testing in my lab. For monitoring results there are two Windows events: 4768 and 4769. They show the used encryption type for Kerberos tickets.
First, I looked at the used encryption type without patch. Furthermore my vCenter object in AD had no special encryption type set. So this is pretty sure the default for the most environments. To my surprise I could see encryption type 0x12
. According to the description of event 4769 this means AES256-CTS-HMAC-SHA1-96 which sounds good to me.
Second test was to change encryption type for my vCenter AD object to the value KB5021131 will implement as new default. So I changed msDS-SupportedEncryptionTypes
to 27
. This does not change encryption type in event 4769.
Next, I patched my DC. After this, I got a new encryption type: 0x17
. Which was also surprising. Because this means RC4-HMAC. So exactly what Microsoft wanted to avoid.
Here comes the suggested workaround from VMware support into play. Support recommends to set encryption type for vCenter objects in AD to 24
(decimal). According to Microsoft this means AES 128, AES 256.
Works well, I could see 0x12
again in event 4769.
Conclusion
I could not spot any problems in my lab. I personally would recommend to set encryption type for vCenter AD objects to 24
before implementing patch KB5021131. To get an official support statement from VMware, open a support request.
As I mentioned, I am not a Microsoft expert. Please feel free to correct me!
Notes
- This post is based on my research and testing. This is no official VMware support statement! Test it, before you implement it!
[update] Official VMware KB Article - Keep in mind, Integrated Windows Authentication is deprecated in vSphere 7.
- Implement VMware Skyline and let it constantly check your environment.
Hi
Nice wrap up and test. Is this the same for ldap authentication against AD instead of joining the vcenter.
Good question, Dries!
As far as I know, vCenter does not use Kerberos for authentication when AD is connected with LDAP. But I did not test it.
Hi,
If your Vcenter is an appliance VSCA running vCenter Server 7.0.3.01500,
the only action to do is to set encryption type for the vCenter object in AD to 24 (decimal) ( in the msDS-SupportedEncryptionTypes attribut)
That’s all?
Regards