If your company has an Ivanti Secure Access VPN device (former Pulse Secure) and uses Kerberos authentication then this will stop working after the April Windows update when RequireSeal will be moved to enforce mode.
Every time a user logs in to the VPN it triggers this event with ID 5838: The Netlogon service encountered a client using RPC signing instead of RPC sealing.
Microsoft article about this: https://support.microsoft.com/en-us/topic/kb5021130-how-to-manage-the-netlogon-protocol-changes-related-to-cve-2022-38023-46ea3067-3989-4d40-963c-680fd9e8ee25
Ivanti is releasing a new firmware but it’s probably not going to be released on time.
From their website: https://forums.ivanti.com/s/article/Netlogon-Protocol-Changes?language=en_US
" Ivanti Dev team has made changes in the code and fix will be available in ICS’s firmware releases tentative for April 2023.
Workaround: To workaround this issue, we need to set the below registry value to “1” for compatibility mode on domain controller, until Ivanti releases the fixed version of this:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters"
The Ivanti article workaround doesn’t list the actual value you need to set in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters but it is in Microsoft’s article
The value that needs to be set to 1 is RequireSeal
We use pulse secure for VPN however when I look into the event logs on our DCs I dont see any of the event IDs Microsoft states Events IDs (5838-5841) logged at all.
Is this only for pulse secure vpn devices or for the pulse secure client?
Another appalling Ivanti KB article.
So if your Pulse only uses LDAP and is not domain joined and if you do not see any event IDs 5838-5841 in the System Event Log on your domain controllers do you need to do anything?
Thank you for the reminder. I looked at our logs and saw 5840 codes being flagged from some storage devices and from a few network devices, so I have reached out to the device owners so they can contact their vendors.
If you have 5838=5841 event codes in your System logs on your DCs, there is work to done.
Oh thanks for letting me know. I’ve some other device causing an event that I can’t figure out.
At least there’s a work around with this but still
Strange, because all the Microsoft and 3rd party articles I read regarding CVE-2022-38023 seem to only mention NTLM authentication, and not Kerberos authentication - or they do and say Kerberos kept working?
Hah - and when we asked, they said our appliance was on an “unaffected” build. Lies!
It’s for the VPN device… It uses Machine Operating System Service Pack: Samba 4.5.10 . Do you use AD or LDAP Auth or do you use Radius in stead? There are no issues with Radius.
Also I’m assuming you installed the Nov/Dec Microsoft updates? Are you checking the System event log?
In the same boat. Did you find anything specific in regards to this scenario?
I will have to reach out and ask unfortunately the VPN is managed by our network team and I have no access.
On the windows side we are patched up to date on the DCs and everything else. We are currently on February 2023 patch level. After this week well be at march level.
I am checking the system log and I know we are getting the events because i see a handful of the RC4 notifications for our vcenter servers. So I know were enabled for them.
Looks like ill be having a talk with our network guys today.
No man I just know those event IDs don’t appear anywhere on any domain controller!
Ok the only other thing I can think of (which you probably already did) is to be sure to check the event logs of the DC’s in the same site where your VPN device is located.
Yea were forwarding all our DC logs to splunk so I see the logs from all DCs in all sites. I am going to spot check some DCs with event viewer and ill see if anything comes up.
Last thing i want to do is get bit in the ass and have VPN not work. Wouldnt make for a fun day after patchday.