Active Directory

The Netlogon service encountered a client using RPC signing instead of RPC sealing.

The message “The Netlogon service encountered a client using RPC signing instead of RPC sealing” is an error message that can appear in the Windows Event Log on a domain controller running Windows Server.

This error message indicates that the Netlogon service received a connection request from a client that was using a different security mechanism than expected. Specifically, the error message indicates that the client was using RPC (Remote Procedure Call) signing, which provides message integrity and authentication, but not encryption, instead of RPC sealing, which provides both message integrity and encryption.

This error message may indicate a security issue, as it suggests that the client may not be properly configured to use the expected security mechanism. In some cases, this error message can also indicate that there is a compatibility issue between the client and the server.

To resolve this error message, you may need to update the configuration of the client to use the expected security mechanism, or update the server to support the security mechanism used by the client. You may also need to investigate whether there is a compatibility issue between the client and the server, and whether any updates or patches are available to address this issue.

Important Starting June 2023, Enforcement mode will be enabled on all Windows domain controllers and will block vulnerable connections from non-compliant devices. At that time, you will not be able to disable the update, but may move back to the Compatibility mode setting. Compatibility mode will be removed in July 2023, as outlined in the Timing of updates to address Netlogon vulnerability CVE-2022-38023 section.

How do the Microsoft patches phases impact NAS

Microsoft Phases What changed How did this impact on NAS? What options do we have?
Nov 2022 – Initial Deployment Phase Windows updates on or after November 8, 2022 address security bypass vulnerability of CVE-2022-38023 by enforcing RPC sealing on all Windows clients.
  • No impact to ONTAP 9
Workaround: Set Registry to RequireSeal:1 Compatibility mode on Domain Controllers to prevent an issue in June
Apr 2023 – Initial Enforcement Phase Windows updates released on or after April 11, 2023 will remove the ability to disable RPC sealing by setting RequireSeal:0
Default value is also set to RequireSeal:1
  • If customers previously set RequireSeal:2, then impact to ONTAP 9 would be seen unless ONTAP 9 is already on fixed versions of RFE 1514175
  • Upgrade to a fixed version of RFE 1514175
  • Workaround: Set Registry to RequireSeal:1 Compatibility mode on Domain Controllers to prevent an issue in June
June 2023 – Enforcement by Default If RequireSeal is not configured, this update will by default assume that RequireSeal:2

If workaround is applied, this value is set to 1, thus compatibility mode is configured and used.

  • All NTLM authentication will fail unless workaround is performed.
  • Upgrade to a fixed version of RFE 1514175
  • Workaround: Set Registry to RequireSeal:1 Compatibility mode on Domain Controllers
  • Ensuring clients utilize Kerberos authentication will avoid dependency on Netlogon/NTLM domain authentication
July 2023 – Enforcement Phase The Windows updates released on July 11, 2023 will remove the ability to set RequireSeal:1

RequireSeal is forced to be to 2, contents of the registry value are ignored.

  • All NTLM authentication will fail unless you upgrade to a fixed version of RFE 1514175
  • See below: How ONTAP is impacted once RequireSeal:2 is set
  • Upgrade to a fixed version of RFE 1514175
  • Ensuring clients utilize Kerberos authentication will avoid dependency on Netlogon/NTLM domain authentication

Summary of the issue

Microsoft requires a new, higher level of Netlogon security for Windows Domain Controllers in order to address a vulnerability in the Windows Netlogon RPC code (details are in CVE-2022-38023).
During regularly scheduled monthly Windows update activity, this new level of Netlogon security is being enabled on Microsoft Domain Controllers in a phased manner.
Windows’ vulnerability only affects NTLM/Netlogon-based domain authentication. The patches being released by Microsoft to resolve CVE-2022-38023 do not affect Kerberos or FIPS authentication, which are not susceptible to this vulnerability.

When the Windows updates to fix this vulnerability are installed, NetApp storage systems running versions of ONTAP without a code change to support this higher level of Netlogon RPC security will experience domain user authentication errors if authenticating via Netlogon, and access to resources shared via CIFS will be impacted.

Applies to

  • Microsoft Windows Server 2012 Domain Controller
  • Microsoft Windows Server 2016 Domain Controller
  • Microsoft Windows Server 2019 Domain Controller

Recommendation

Prior to the “Enforcement by Default” phase beginning on June 13, 2023, either (preferred) Upgrade all ONTAP-running systems to one of the versions listed under “Solution” in this advisory (or a later version, as soon as it becomes available). or
All Windows domain controllers must have the “Compatibility mode” RequireSeal = 1 registry key value.
Upgrade all systems running ONTAP to one of the releases listed in the “Solution” part of this advisory (or later, as available) before the July 11, 2023 “Enforcement” phase, if they haven’t already.
For systems running ONTAP 9, there is no solution after the “Enforcement” phase on July 11, 2023. Upgrades to one of the releases listed in the “Solution” section of this advisory are REQUIRED for ONTAP 9 systems.

Issue Description

Updates will be released in several phases: the initial phase for updates released on or after November 8, 2022 and the Enforcement phase for updates released on or after July 11, 2023.

November 8, 2022 – Initial deployment phase

The initial deployment phase starts with the updates released on November 8, 2022 and continues with later Windows updates until the Enforcement phase. Windows updates on or after November 8, 2022 address security bypass vulnerability of CVE-2022-38023 by enforcing RPC sealing on all Windows clients.

By default, devices will be set in Compatibility mode. Windows domain controllers will require that Netlogon clients use RPC seal if they are running Windows, or if they are acting as either domain controllers or as trust accounts.

April 11, 2023 – Initial enforcement phase

The Windows updates released on or after April 11, 2023 will remove the ability to disable RPC sealing by setting value to the RequireSeal registry subkey.

June 13, 2023 – Enforcement by Default

The RequireSeal registry subkey will be moved to Enforced mode unless Administrators explicitly configure to be under Compatibility mode. Vulnerable connections from all clients including third-parties will be denied authentication. See Change 1.

July 11, 2023 – Enforcement phase

The Windows updates released on July 11, 2023 will remove the ability to set value to the RequireSeal registry subkey. This enables the Enforcement phase of CVE-2022-38023.

All domain uses of the Netlogon protocol (NTLMv1 and NTLMv2) are impacted by these changes.

There is no workaround for ONTAP-based SVMs that authenticate to a Microsoft domain controller using Netlogon/NTLM once the “enforcement” phase is in place (after July 11, 2023). Prior to July 11, 2023, all ONTAP systems hosting SVMs that log in to a Microsoft domain controller using Netlogon/NTLM MUST be upgraded to one of the ONTAP releases listed in the Solution section of this advisory (or later, as available). If you fail to perform this before the July 11, 2023 Windows updates are deployed, CIFS data services will cease to function.

Symptom

When a Windows Domain Controller has enabled Netlogon RPC Sealing, it will return “Access Denied” to an ONTAP-based SVM when it tries to send NTLM authentication data through Netlogon.

The Windows Domain Controller will record event ID: 5838

Log Name:      System
Source:        NETLOGON
Date:          6/16/2023 3:17:28 PM
Event ID:      5838
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DC31.windowstechno.local
Description:
The Netlogon service encountered a client using RPC signing instead of RPC sealing.  

Machine SamAccountName: CIFSNA01

Workaround

RequireSeal registry key

RequireSeal is a security setting in Windows that controls whether RPC (Remote Procedure Call) traffic is encrypted using a mechanism called “sealing”. When RequireSeal is enabled, RPC traffic must be encrypted using sealing, and if sealing is not used, the RPC traffic will be rejected.

Sealing is a security mechanism that provides both message integrity and encryption for RPC traffic. When sealing is used, the RPC message is encrypted to prevent eavesdropping and tampering, and a cryptographic signature is applied to ensure that the message has not been modified during transmission.

RequireSeal is typically used in environments where security is a top priority, such as in government or military organizations. However, enabling RequireSeal can also introduce compatibility issues, as some older applications or devices may not support sealing. In some cases, it may be necessary to disable RequireSeal to ensure compatibility with legacy systems.

To enable or disable the RequireSeal setting, you can use the Registry Editor on a Windows Server. Here are the steps:

Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value RequireSeal
Data type REG_DWORD
Data – Disabled

– Compatibility mode. Windows domain controllers will require that Netlogon clients use RPC Seal if they are running Windows, or if they are acting as either domain controllers or Trust accounts.

– Enforcement mode. All clients are required to use RPC Seal.

Restart required? No
  • Open the registry editor.
  • Expend the settings – “Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters”
  • Click on Parameters
  • Right-click on the right window, from the context menu, choose “New”, and then “DWORD (32-bit) Value
  • On the new DWORD, type “RequireSeal” and click Enter

    Note: It is very important to ensure that the R and S is capitalized and there is no space, if not, the key will not be recognized

  • Next, double-click the key to open the key editor, from the editor, set the value under “Value data:” to 1, and then click “OK”

NAS

Permanent Solution

Update or upgrade the NAS devices to latest technology which support the higher encryption and compatible with AD Kerberos authentication.

Frequently Asked Questions (FAQ)

Q:  Who is vulnerable for the issue listed in CVE-2022-38023?

All domain-joined, machine accounts are affected by this CVE. Events will show who is most impacted by this issue after the November 8, 2022 or later Windows updates are installed, please review the Event Log errors section to address the issues.

To help detect older clients that are not using the strongest available crypto, this update introduces event logs for clients that are using RC4.

Q:  What is RPC signing and RPC sealing?

RPC signing is when the Netlogon protocol uses RPC to sign the messages it sends over the wire. RPC sealing is when the Netlogon protocol both signs and encrypts the messages it sends over the wire.

Q:  How do Windows Domain Controllers determine whether a Netlogon Client is running Windows?

Windows Domain Controller determine whether a Netlogon client is running Windows by querying the “OperatingSystem” attribute in Active Directory for the Netlogon client and checking for the following strings:

  • “Windows”, “Hyper-V Server”, and “Azure Stack HCI”

We do not recommend nor support that this attribute be changed by Netlogon clients or domain administrators to a value that is not representative of the operating system (OS) that the Netlogon client is running. You should be aware that we may change the search criteria at any time.

Q:  Will the Enforcement phase reject RC4 Netlogon clients?

The enforcement phase does not reject Netlogon clients based on the type of encryption that the clients use. It will only reject Netlogon clients if they do RPC signing instead of RPC Sealing. Rejection of RC4  Netlogon clients is based on the “RejectMd5Clients” registry key available to Windows Server 2008 R2 and later Windows Domain Controllers. The enforcement phase for this update does not change the “RejectMd5Clients” value. We recommend that customers enable the “RejectMd5Clients” value for higher security in their domains.

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

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.

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 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:  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:  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:

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) KDC Event Logged if DES for Kerberos Disabled
System 42 The Kerberos Key Distribution Center lacks strong keys for account: accountname. Microsoft 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

So, that’s all in this blog. I will meet you soon with next stuff. Have a nice day!!!

Guys please don’t forget to like and share the post. Also join our WindowsTechno Community and where you can post your queries/doubts and our experts will address them.

You can also share the feedback on below windows techno email id.

If you have any questions, feel free to contact us onadmin@windowstechno.com also follow us on facebook@windowstechno to get updates about new blog posts.

How useful was this post?

Click on a star to rate it!

As you found this post useful...

Follow us on social media!

Was this article helpful?
YesNo

Vipan Kumar

He is an Active Directory Engineer. He has been working in IT industry for more than 10 years. He is dedicated and enthusiastic information technology expert who always ready to resolve any technical problem. If you guys need any further help on subject matters, feel free to contact us on admin@windowstechno.com Please subscribe our Facebook page as well website for latest article. https://www.facebook.com/windowstechno

Leave a Reply

Back to top button