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
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.
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.
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
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.
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!
- 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.