Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
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: Microsoft KB 5021130 How To Manage The Netlogon Protocol Changes Related To CVE-2022-38023Microsoft KB 5020805 How To Manage Kerberos Protocol Changes Related To CVE-2022-37967Microsoft KB 5021131 How To Manage The Kerberos Protocol Changes Related To CVE-2022-37966Microsoft KB 5010265 Adds AES Encryption Protections To The MS-LSAD Protocol For CVE 2022-21913Microsoft KB 5025230 OS Build 20348
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 accountAny SmartCard loginIf 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: Microsoft: Unsupported etype error when accessing a resource in a trusted domainMicrosoft: msDS-SupportedEncryptionTypes Episode 1: Computer accountsMicrosoft: Decrypting the Selection of Supported Kerberos Encryption Types: Do's and Dont's 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. Microsoft security advisory: Update for disabling RC4 - Microsoft SupportVMWare KB 1018510: Ciphers supported on ESX/ESXi and vCenter Server Q: Have these Microsoft patches been tested in conjunction with other settings? A: Yes. These include the following: NetLogon RequireSeal=2msDS-SupportedEncryptionType set to 18Domain controller: LDAP server channel binding token requirements->AlwaysDomain controller: LDAP server signing requirements->RequireDomain member: Digitally encrypt or sign secure channel data (always)->EnabledDomain member: Digitally encrypt secure channel data (when possible)->EnabledDomain member: Digitally sign secure channel data (when possible)->EnabledMicrosoft network client: Digitally sign communications (always)->EnabledMicrosoft network client: Digitally sign communications (if server agrees)->EnabledMicrosoft network server: Digitally sign communications (always)->EnabledMicrosoft network server: Digitally sign communications (if client agrees)->EnabledNetwork security: LAN Manager authentication level->Send NTLMv2, refuse LM/NTLMNetwork security: LDAP client signing requirements->RequireNetwork security: Minimum session security for NTLM SSP based (including secure RPC) clients->NTLM2/128Network security: Minimum session security for NTLM SSP based (including secure RPC) servers->NTLM2/128Network security: Restrict NTLM: Incoming NTLM traffic->Deny allNetwork security: Restrict NTLM: NTLM authentication in this domain->Deny allNetwork 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.conf2. 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-HMAC3. 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 LearnWindows 2008R2 DC's - Enable Use DES encryption for legacy applications (microsoft.com) 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. LogEvent IDMessage TextReferenceSystem16While 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 DisabledSystem27While 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 DisabledSystem42The Kerberos Key Distribution Center lacks strong keys for account: accountname.Microsoft KB 5021131 See KB article to scan for vulnerable accountsSystem43The Key Distribution Center (KDC) encountered a ticket that it could not validate the full PAC Signature. Microsoft KB 5020805System44The Key Distribution Center (KDC) encountered a ticket that did not contained the full PAC Signature.Microsoft KB 5020805System4768A Kerberos authentication ticket (TGT) was requested.Windows Audit Log: Audit Kerberos Authentication ServiceSystem4769A Kerberos service ticket was requested.Windows Audit Log: Audit Kerberos for Service Ticket OperationsSystem5838The Netlogon service encountered a client using RPC signing instead of RPC sealing.Microsoft KB 5021130System5839The Netlogon service encountered a trust using RPC signing instead of RPC sealing.Microsoft KB 5021130System5840The Netlogon service created a secure channel with a client with RC4.Microsoft KB 5021130System5841The 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
Other helpful information about RC4 removal: The RC4 Removal Files Part1: What's In An Error Message?The RC4 Removal Files Part 2: In AES We TrustThe RC4 Removal Files Part 3: The “Everything Else” Of ItGroup Policy setting Network security: Configure encryption types allowed for Kerberos