An issue exists between the Ubiquiti Networks Unifi software controller v5.10.19 and a Microsoft Radius or Network Policy Server (NPS) when NTLMv2 responses are forced on all Domain Controllers. When this condition exists, radius calls from the Unifi controller fail with error event that indicates the password is invalid. The security logs on the radius server report the following failure:
Failure Reason: Unknown user name or bad password.
Sub Status: 0xC000006A (Account logon with misspelled or bad password)
The issue is limited only to VPN connections. WiFi connections using the same Radius connection profile and user account succeed.
Applying the registry key in Microsoft KB 2811487 to the Radius server resolves the issue.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Enable NTLMv2 Compatibility = 1
When applying the security enhancements in Microsoft KB 4034879, we noted that the VMware App Volumes desktop agents in our VDI environment stopped functioning. After setting the value LdapEnforceChannelBinding=1 on all Domain Controllers, desktop sessions returned an App Volumes error “NTLM Authentication Invalid: Authentication failed” and no app stacks were attached to the user session.
VMware KB 2146459 provides a workaround to the specific error by disabling NTLM authentication. The KB article stated that disabling the NTLM authentication challenge would reduce security. We reached out to support to clarify the risks imposed and they were able to confirm our suspicion that skipping this check would leave the environment exposed to a potential session impersonation attack, potentially exposing another user’s App Volumes assignments. I haven’t tested the theory, but we assume that an impersonated logon message could be sent to the App Volumes manager API for a different user, and that the manager would then comply by attaching any volumes assigned to the impersonated user.
According to VMware support, the issue exists because the App Volumes manager must be able to intercept and man-in-the-middle the NTLM authentication process. Enabling channel binding on NTLM effectively disables the man-in-the-middle approach.
There were no other workarounds available at this time.
I ran into a bug where the VMware Identity Manager / VMware WorkspaceONE virtual appliances (188.8.131.52) would not persist changes to network settings across reboots. Attempting to update the DNS resolver addresses were reverted when the appliance rebooted. It didn’t seem to matter whether the changes were applied on the vApp tab in vCenter, directly onto the appliance using vami_config_net, or by directly editing network configuration settings in the OS; all methods reverted the appliance’s DNS resolvers to the previous entries at reboot.
After some back and forth with VMware’s Business Critical Support, we determined that KB 54981 resolved the issue. The KB article is specific to changing IP addresses in a cloned system, but it applied to our case as well. Deleting the three backup files allowed the new resolver addresses to persist across reboots.
A bug exists in the FIPS version of the VMware Unified Access Gateway 3.3.1 appliance that causes the local Blast services to fail to properly initialize due to a cipher suite mismatch between local services on the appliance. The issue appears to be exclusive to the 3.3.1 release, as the issue did not exist in 3.3.0 and is said to be patched in 3.4.0.
To resolve the issue, a single line needs to be edited in a configuration file on the appliance.
Open the following file in an editor:
Locate the line for ‘localHttpsCipherSpec’ and replace it with the following:
Save the file. Disable and enable the Blast service in the web administration UI. Restart the appliance.
VMware vRealize Operations Manager 6.6.1 may return an error stating “Keyfile is not valid” when attempting to install a new SSL certificate. The appliance does not properly convert timezone data on the “valid from” attribute of a certificate and may believe the certificate is outside it’s validity period.
The solution was to try again the following day.