After installing November 2022 windows patches on our domain controllers, some vcsa computer accounts started logging event id 5840
Event Log | System |
Event Type | Warning |
Event Source | NETLOGON |
Event ID | 5840 |
Event Text | The Netlogon service created a secure channel with a client with RC4. |
If you find Event 5840, this is a sign that a client in your domain is using weak cryptography.
Whats weird is none of our other vCenters produce this event. They are all joined to AD. The computer accounts are all default in AD, no custom GPO or attributes added to enforce non-standard encryption baseline.
This is a known issue already. Microsoft as usually screwed up with thier primitive patches.
This may be more of an issue then you think. I am still researching but this is what I have found.
After the November update initial patch broke Kerberos and out-of-band was released to resolve, the Netlogon 5838, 5829, 5840 and 5841 events may be logged because the following registry key has been created and set to "audit" mode.
Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value: RequireSeal
This is to help identify issue you face once the setting is enforced for CVE-2022-38023
https://support.microsoft.com/help/5021130
Important Starting April 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.
November 8, 2022 -
• Windows updates address security bypass vulnerability 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 -
• Will remove the ability to disable RPC sealing by setting value 0 to the RequireSeal.
• RequireSeal 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.
July 11, 2023 - Will remove the ability to set value 1 to the RequireSeal subkey. This removes Compatibility mode and enables the Enforcement mode.
This may be more of an issue then you think. This is what I have found so far.
After the November update initial patch broke Kerberos and out-of-band was released to resolve, the Netlogon 5838, 5829, 5840 and 5841 events may be logged because the following registry key has been created and set to "audit" mode.
Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value: RequireSeal
This is to help identify issue you face once the setting is enforced for CVE-2022-38023
https://support.microsoft.com/help/5021130
Important Starting April 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.
November 8, 2022 -
- Windows updates address security bypass vulnerability 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 -
- Will remove the ability to disable RPC sealing by setting value 0 to the RequireSeal.
- RequireSeal 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.
July 11, 2023 - Will remove the ability to set value 1 to the RequireSeal subkey. This removes Compatibility mode and enables the Enforcement mode.
I wanted to check in on this. I haven't been able to find a way to fix this and I'm still seeing these errors. Anyone have any luck?
I opened a case with VMware support. They said remove the vcsa from the domain, it no longer requires domain join and integrated windows auth is deprecated. Once we removed vcsa from domain the events stopped. We use LDAPS anyway, at one point IWA was configured which VMware support says relied on domain joining the vcsa.
Do you know if this 'breaks' the ability to use the Enhanced Authentication plug-in for the "Use Windows session authentication" option when logging in?
Yes, removing vcsa from the domain breaks "Use Windows Session Authentication" aka the enhanced authentication plug-in. According to VMware support this feature will sunset along with IWA at some future date.
Thanks for the confirmation. Just wanted to know if I needed to give some engineers a heads up before I removed it. I think July will be when this would be forced regardless since that's when Microsoft begins enforcing the encryption changes if I remember correctly.
Hi,
Did this resolve your issue?
Did removing the VCSA from the Domain break the ability to add Domain Groups for permissions & roles?
Und wie immer liegts du völlig falsch damit.
If you set up LDAPS, with the base DN for groups filled out, then you will still be able to manage AD groups.
I just removed my vC from AD and added access via LDAPS. So while a user can log in with DOMAIN.COM\user, my domain service accounts are all set to DOMAIN\service_acct.
Is there a way to allow the short NETBIOS name to authenticate without having to change every account tied into vCenter? -- EDIT: Never mind - I had to make it the default, even though it was the only provider there.
After moving to LDAPS, service accounts cannot log into vCenter. Users can. The only workaround we can see is to remove and re-add the service account where it is being used. There has to be a better way.
Has anyone else run into this?