MathiasAndersso
Contributor
Contributor

LDAP server signing requirements security policy setting set to Require signing

Hi,

We would like to set LDAP server signing requirements = require signature (https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-...) in our Active Directory.

Is this setting supported in Horizon View, especially in version 7.6? Do we need to configure Horizon in some way to support LDAP server signing?

I can't find anything about this in "Preparing Active Directory", https://docs.vmware.com/en/VMware-Horizon-7/7.6/horizon-installation/GUID-F6075DF0-9614-4A81-B27A-7E....

VMware states that "Horizon Cloud supports the use of Active Directory Domain Controllers that have the Domain controller: LDAP server signing requirements security policy setting set to Require signing", https://docs.vmware.com/en/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-EBDCC0..., but that is for Horizon Cloud.

Regards,

Mathias

0 Kudos
13 Replies
vXav
Expert
Expert

Any news on this? Microsoft are to roll out the patch in mid-January 2020 and there's literally nothing that talks about this in a Horizon context.

https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirem...

0 Kudos
MathiasAndersso
Contributor
Contributor

Hi vXav,

I have a support case ongoing with VMware and I just got the following answer;

"I have received the update from our internal team that , We dont have to take any additional steps . View already uses signing for LDAP connections to local/global AD LDS instances, and to domain controllers.
So for cloud and on Premise deployments and View is ready for Microsoft updates for 2020."

Good news, but we still need to figure out what we need to do to secure the communication with Microsoft Active Directory from the Horizon View Connection Servers service accounts with either LDAP signing or via TLS.

We have activated log Event ID: 2889 according to "Identifying Clear Text LDAP binds to your DC’s", https://blogs.technet.microsoft.com/russellt/2016/01/13/identifying-clear-text-ldap-binds-to-your-dc...


In the Windows event log filtered by Event ID 2889 we can see information like this;
"The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection."

/Mathias

0 Kudos
vXav
Expert
Expert

Yeah not feeling overly confident on this one.. I received roughly the same answer from VMware support except they said "there shouldn’t be any negative side-effects"... Never says "Should be ok" to an IT guy.

Earlier in the year the AD team forced signing requests and our VDI environment became unavailable. Came back when they rolled back. That's the reason why I'm asking the VMware support to get it together on this one. There's nothing in the Horizon UI that suggests ldap/tls configuration.

0 Kudos
vXav
Expert
Expert

VMware support:

This is just a follow up email to let you know that we are working with the concerned team to release a public KB article regarding the 2020 LDAP channel binding and LDAP signing requirement for Windows in Horizon environment at the earliest.
MathiasAndersso
Contributor
Contributor

And I got this from VMware Support:

View uses  LDAP GSSAPI binds with signing, hence it’s already meets the “Require Signing” policy.

There would be a public KB article that would available regarding this. I would update you once it is available

vXav
Expert
Expert

And yet we both get 2889's on the DC.

I don't think so but I'm wondering if they think we're talking about the internal replicated LDAP DB... January sure is going to be fun.

0 Kudos
vMarkus
VMware Employee
VMware Employee

Hi vXav,

may I kindly ask for the support request number via PN? I tried messaging you via PN but it is not possible to send the message.

​Many thanks in advance

​Markus

0 Kudos
vXav
Expert
Expert

Also I suppose we will have to change the Identity Source in vCenter as "Integrated Windows Authentication" seems to make unsigned bind. See this thread : vCenter LDAP binding and signing

MathiasAndersso
Contributor
Contributor

Yeah, I suppose so.

I have got some new information from VMware,

"The KB publish is getting delayed due to App Volume. Though there is no impact with Horizon View, our Engineering team identified there is a little impact with App Volume. Hence, they are working to address this issue. It will be resolved soon. Once this issue is resolved, we will publish the KB with all the components."

I hope this will be resolved before mid-january...

vXav
Expert
Expert

Thanks for sharing. That is some last minute stuff going on.

Last time when our AD team enabled sign and encryption for LDAP connections the domain icon of Horizon was Red and provisioning failed. I wonder if it was because the identity source in vCenter is set to ldap instead of ldaps (given that according to them there is no impact on Horizon). I cannot get an answer from them on this...

It is supposedly possible to revert to the old setting after the update is installed. In case Horizon goes red for some reason...

Source:

ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing : sysadmin

https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/LDAP-Channel-Binding-and-LDA...

0 Kudos
vXav
Expert
Expert

FYI : VMware released KB 76062 saying that horizon supports the update.

However we still receive 2889 events on the instant clone admin service account.

So basically VMware's and Microsoft's statements are contradictory with regard to compliance and how to identify "problematic accounts".

This question is being escalated. I'll update here when more info comes up.

0 Kudos
imranswanuni
Contributor
Contributor

Despite what https://kb.vmware.com/s/article/76062 says it does look like it'll break in March.

0 Kudos
vXav
Expert
Expert

Pushed to August 2020.

By the way, I did some testing and the windows integrated identity source generates 2889 events but works regardless so VMware's statement is correct.

I'm following the topic in a blog...