Impact of RPC Sealing Enforcement (Microsoft KB 5021130), RC4 (CVE-2022-37966), and Related Changes (CVE-2022-38023, CVE-2022-37967, CVE-2022-21913) on vCenter Server and ESXi

Products

VMware vCenter Server

Issue/Introduction

Beginning in November 2022, Microsoft released a number of security fixes addressing weaknesses in the NetLogon, Kerberos, and RPC protocols in Windows. One of the key attacks these fixes are intended to resolve is Kerberoasting. Broadly speaking, this is implemented by increasing encryption strength in a number of different areas within these protocols, along with other fixes. In particular, default settings have been revised to avoid the selection of the RC4 encryption and to ensure Remote Procedure Call (RPC) communications are encrypted. This is called sealing in RPC terminology. In some cases, RPC-encapsulated protocols such as MS-LSAD were modified directly as well.

The RC4-related changes are particularly difficult to navigate as they are in many closely related areas, such as:

Preauthentication: Individual fields of Kerberos authentication exchanges are encrypted.
Kerberos session ticket: The Kerberos session ticket itself is encrypted.
NetLogon: The body of Remote Procedure Calls over NetLogon, or SMB, must now be encrypted.

This document addresses concerns including but not limited to the following Windows patches:

Environment

VMware vCenter Server 8.0.x
VMware vCenter Server 6.x
VMware vCenter Server 7.0.x

Resolution

Q: What is the effect of Microsoft's RC4, RPC Sealing, PAC signature checking, and related security fixes on vCenter?

A: User authentication will continue to function without impact. Administrators may notice some event 5840s, clients using RC4, logged in the following cases:

IWA identity source and login attempt for nonexistent account
Any SmartCard login
If domain-joined, every 6 hours

No events should be logged when AD-over-LDAP(S) is used and the vCenter is not joined to the domain.
Active Directory Federated Services (ADFS) configurations are not affected.

VMware continues to evaluate these changes and will update this article based on new information.

Q: Do the RC4 events indicate authentication to vCenter will stop working when enforcement mode begins?

A: No, enforcement of RPC Sealing is separate from RC4. RC4 remains a usable cipher. If your organization decides to disable the usage of RC4, ensure that the vCenter/ESXi computer object in AD is configured to use other ciphers, such as AES128 or AES256.

Q: What does this mean for SSPI/EAP logins?

A: EAP, SSPI, and SmartCard logins continue to work.

Q: Can any of the new settings recommended in the Microsoft articles affect vCenter?

A: Yes, We do not recommend enabling the RejectMd5Clients at this time. Enabling it may break authentication. This setting is a part of the NetLogon protocol changes mentioned in Microsoft KB 5021130 How To Manage The Netlogon Protocol Changes Related To CVE-2022-38023.

Q: Is the Authentication Proxy affected by these changes?

A: No, the Authentication Proxy works properly when RPC sealing is required.

Q: What about ESXi?

A: ESXi also uses Likewise when joined to an Active Directory domain and was found to be unaffected by the RPC Sealing changes. The scenarios in this article which do not pertain to SSO Identity Sources also apply to ESXi's version of likewise.

Q: Does vCenter use RC4 for encryption of Kerberos tickets?

A: By default, vCenter offers AES128 and AES256 encryption. The type of encryption used is determined by the server. RC4 encryption is only used if the server does not support a better method.

Q: Is vCenter vulnerable to RC4 encrypted Kerberos tickets?

A: By default vCenter only uses RC4 for ticket encryption if that is the best encryption the Windows server permits.

Q: Does vCenter support RPC sealing?

A: vCenter functions correctly when RPC sealing is required.

Q: Is RC4 still commonly used?

A: It can be. In particular, it is used for both sides of trust accounts and for ticket encryption by machine/service accounts created under older versions of Windows. This value is not updated when a client or DC is upgraded. For more information, please see:

Q: Why is there so much concern about RC4?

A: Stopping the usage of RC4 has the potential to break logins within an organization. Traditionally, RC4 was a widely supported "lowest common denominator" encryption protocol that could be used between client and server. Older versions of Windows and many accounts still use RC4. Any environment should be audited and tested before RC4 is removed from production use.

Q: Wasn't the RC4 vulnerability fixed in Windows and vCenter long ago?

A: RC4 support was removed from the SSL/TLS stack used by Windows and vCenter long ago. The new changes affect the usage of RC4 by Kerberos and RPC calls. There is no global setting to disable RC4 usage everywhere in either Windows or vCenter.

Q: Have these Microsoft patches been tested in conjunction with other settings?

A: Yes. These include the following:

NetLogon RequireSeal=2
msDS-SupportedEncryptionType set to 18
Domain controller: LDAP server channel binding token requirements->Always
Domain controller: LDAP server signing requirements->Require
Domain member: Digitally encrypt or sign secure channel data (always)->Enabled
Domain member: Digitally encrypt secure channel data (when possible)->Enabled
Domain member: Digitally sign secure channel data (when possible)->Enabled
Microsoft network client: Digitally sign communications (always)->Enabled
Microsoft network client: Digitally sign communications (if server agrees)->Enabled
Microsoft network server: Digitally sign communications (always)->Enabled
Microsoft network server: Digitally sign communications (if client agrees)->Enabled
Network security: LAN Manager authentication level->Send NTLMv2, refuse LM/NTLM
Network security: LDAP client signing requirements->Require
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients->NTLM2/128
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers->NTLM2/128
Network security: Restrict NTLM: Incoming NTLM traffic->Deny all
Network security: Restrict NTLM: NTLM authentication in this domain->Deny all
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers->Deny all

Q: What does DefaultDomainSupportedEncTypes do?

A: This defines the Kerberos ticket encryption type to use if the per-account ADSI attribute msDS-SupportedEncryptionType is not set. For more information, see What happened to Kerberos Authentication after installing the November 2022/OOB updates? - Microsoft Community Hub.

Q: Does VMWare recommend a value for DefaultDomainSupportedEncTypes?

A: We recommend using 24 decimal or 0x18 (hexadecimal) so Kerberos tickets are encrypted with AES 128 or AES 256.

Q: Should I disable vCenter's support for RC4 encryption of Kerberos tickets?

A: This will slightly improve security, but may break interoperability. It will not improve ticket encryption where the server has already been configured to use AES128/256.

Q: How do I disable vCenter's RC4 support?

A: To do so:

1. Make a backup copy of /etc/krb5.conf

2. Edit /etc/krb5.conf, removing the keyword "RC4-HMAC" from the lines configuring default_tgs_enctypes, default_tkt_enctypes, and preferred_enctypes.
For example:
    [libdefaults]
      default_tgs_enctypes = AES256-CTS AES128-CTS RC4-HMAC
      default_tkt_enctypes = AES256-CTS AES128-CTS RC4-HMAC
      preferred_enctypes = AES256-CTS AES128-CTS RC4-HMAC

3. Restart vCenter.

Q: What is msDS-SupportedEncryptionTypes and what is it used for?

A: This is an attribute of Active Directory Computer, User, and Trust account objects in Active Directory accessible via ADSIEdit. It's purpose is to configure the Kerberos ticket encryption methods on a per-account basis. See this article for more information. Active Directory uses it in conjunction with the DefaultDomainSupportedEncTypes value as described here.

Q: Has a similar change occurred in the past?

A: Yes. In 2008, Microsoft disabled use of the DES algorithms for the same usage and the same reason. For more information, please see the following articles:

KDC event ID 16 or 27 is logged if DES for Kerberos is disabled - Windows Server | Microsoft Learn

Q: How do I audit my environment for RC4 usage, lack of RPC sealing, or other insecure activity addressed by these Microsoft patches?

A: Please see Microsoft for complete information on how to audit Active Directory for usages of RC4. Microsoft has added a large number of system events that can be used to detect this activity. We have provided the following event list as a starting point.

Log	Event ID	Message Text	Reference
System	16	While processing a TGS request for the target server %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3).	KDC Event Logged if DES for Kerberos Disabled
System	27	While processing a TGS request for the target server %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3)	K DC Event Logged if DES for Kerberos Disabled
System	42	The Kerberos Key Distribution Center lacks strong keys for account: accountname.	M icrosoft KB 5021131 See KB article to scan for vulnerable accounts
System	43	The Key Distribution Center (KDC) encountered a ticket that it could not validate the full PAC Signature.	Microsoft KB 5020805
System	44	The Key Distribution Center (KDC) encountered a ticket that did not contained the full PAC Signature.	Microsoft KB 5020805
System	4768	A Kerberos authentication ticket (TGT) was requested.	Windows Audit Log: Audit Kerberos Authentication Service
System	4769	A Kerberos service ticket was requested.	Windows Audit Log: Audit Kerberos for Service Ticket Operations
System	5838	The Netlogon service encountered a client using RPC signing instead of RPC sealing.	Microsoft KB 5021130
System	5839	The Netlogon service encountered a trust using RPC signing instead of RPC sealing.	Microsoft KB 5021130
System	5840	The Netlogon service created a secure channel with a client with RC4.	Microsoft KB 5021130
System	5841	The Netlogon service denied a client using RC4 due to the ‘RejectMd5Clients’ setting.	Microsoft KB 5021130

In addition, the following articles provide useful guidance to identify RC4 usage within your environment:
Decrypting the Selection of Supported Kerberos Encryption Types - Microsoft Community Hub

Additional Information

Other helpful information about RC4 removal: