Does Microsoft KB5021131 break vCenter login?

  • 14 December 2022
  • 6 comments
  • 1468 views

Userlevel 7
Badge +13

Microsoft published a security update for Windows. 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 Editor.

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.

After I applied the patch, 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.

 

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. This is also recommended in the official VMware KB article (90227)

For more details of my testing, visit my blog post.


6 comments

Userlevel 7
Badge +14

For what it's worth, I cannot reproduce this myself with the latest patches in my lab. To be on the safe side, I applied the encryption type changes in my AD.

Userlevel 7
Badge +9

Great post @vNote42, thank you!

Userlevel 7
Badge +20

I will be sure to test this on my homelab to ensure things don’t break.  Thanks for sharing this one and giving us the heads up.  👍🏼

Userlevel 7
Badge +14

As the integrated windows Authentication is deprecated, this is another reason to move to LDAPS. Thanks for the hint @vNote42 

Userlevel 7
Badge +13

As the integrated windows Authentication is deprecated, this is another reason to move to LDAPS. Thanks for the hint @vNote42 

fully agree 😁

I set ours to 28 decimal. I will be updating our DCs tomorrow. 

Comment