LDAP lb and Microsoft ADV190023

[Joost Sannen]

Hi,

 

We have this SSL_TCP load balancer for LDAPS with a public certificate. The backend Windows 2019 domain controllers use it's internal PKI. When we enable 

LDAP channel binding and LDAP signing according to Microsoft's ADV190023 we still can connect but a bind with credentials fails. This is tested with LDP.exe

 

Our ADC is running 13.0 71.44 and the error is 

 

53 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 1)
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3
    {NtAuthIdentity: User='xxxx'; Pwd=<unavailable>; domain = 'xxxx.xx'}
Error <49>: ldap_bind_s() failed: Invalid Credentials.
Server error: <empty>
 

How should we solve this?

[Martin Meier]

If ldp fails it seems to be a LDAP problem and not a ADC problem.

 

On the ADC you only need to change the LDAP Server “Security Type” to SSL or TLS if you still use plaintext.

 

check: https://support.citrix.com/article/CTX269461

 

[Joost Sannen]

HI @Martin Meier, thanks for your answer.

 

We already have the LDAP Authentication Server you are referring to setup as SSL/636. My findings are with the LDAPS load balancer like https://www.carlstalhood.com/netscaler-menu/citrix-adc-13/ . 

[CarlStalhood]

Does it work if the LB vServer is TCP instead of TCP_SSL?

[Joost Sannen]

Hi Carl,

 

Thanks for your response. With TCP it does work with the internal FQDN but it doesn't with the public FQDN. It fails with an "Cannot open connection". The response in LDP for the latter one are

 

ld = ldap_sslinit("ldap.xxxx.xx", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 81 = ldap_connect(hLdap, NULL);
Server error: <empty>
Error <0x51>: Fail to connect to ldap.xxxx.xx.
 

And LDAP diagnostic events on the DC are

 

Event 1535: Internal event: The LDAP server returned an error. 
Additional Data 
Error value:
00000057: LdapErr: DSID-0C0C0095, comment: Error decoding ldap message, data 0, v4563

 

Event 1216 Internal event: An LDAP client connection was closed because of an error. 
 Client IP:
x.x.x.x:xx 
 Additional Data 
Error value:
87 The parameter is incorrect. 
Internal ID:
c0c0095

 

Do you know a solution of a working setup with a public FQDN?

[Martin Meier]

I think SSL_TCP is the better choice for public facing LDAPS because of SSL-Offloading and possibility for the client to validate the LDAPS LB certificate.

 

If it fails using TCP there seems to be another problem outside the ADC because using TCP the LB only "forwoards" the traffic/request.

Maybe there is some interaction with a firewall when using the public LDAPS LB?

 

Is a connection Test using an Authentication LDAP Server on the ADC  possible?

[Joost Sannen]

I have this scenario tested in a small lab. For the public FQDN I use a pinpoint zone in DNS and there is no firewall between the test client, the ADC and the DC. I've seen the difference between the use of TCP and SSL_TCP on Carl's website, https://www.carlstalhood.com/domain-controller-ldaps-load-balancing-citrix-adc/.

 

I prefer SSL_TCP but it does not work when tested with LDP (and some other applications as well).

 

Can you perhaps check if it breaks with both settings LDAP signing and LDAP channel binding enabled in the domain?

 

 

 

[Martin Meier]

19 hours ago, Joost Sannen said:

ld = ldap_sslinit("ldap.xxxx.xx", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 81 = ldap_connect(hLdap, NULL);
Server error: <empty>
Error <0x51>: Fail to connect to ldap.xxxx.xx.

 

I can reproduce this if I delete the CA-Certificate / Chain of my ldap (load balancer) certificate.

 

[Martin Meier]

EventViewer on the client where I am using LDP.exe showed me why it wasnt working using the public FQDN:

"The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is xcxcxcxcxc.myfritz.net. The TLS connection request has failed. The attached data contains the server certificate."

 

I was using a CNAME-Record to point my public FQDN to my FritzBox.

After I deleted the CNAME and added a A-Record everything works:

ld = ldap_sslinit("grafana.kekse-lab.de", 636, 1);
Error 81 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 0 = ldap_connect(hLdap, NULL);
Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
Host supports SSL, SSL cipher strength = 256 bits
Established connection to xvxcvvxcv.kekse-lab.de.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)

Maybe the cert is your issue aswell? Check EventViewer on the client.

[Joost Sannen]

Hi @mmeijer440, thanks for testing! 

 

You mention you can reproduce when you delete the CA-Certificate / Chain of the ldap (load balancer) certificate. That's when you remove the CA certificate which issued your public certificate for ldap?

 

And your second finding. Have you tried to do a bind? I can connect successfully but cannot bind. I already use a A-record.

 

The bind produces an informational event 3039 on the DC under Directory Service:

 

The following client performed an LDAP bind over SSL/TLS and failed the channel binding token validation.  Either the client did not pass channel binding tokens to the server, or the channel bindings did not match. 
Client IP address:
x.x.x.x:64867 
Identity the client attempted to authenticate as:
NT AUTHORITY\ANONYMOUS LOGON 
For more details and information on channel binding token validation for LDAPS, please see https://go.microsoft.com/fwlink/?linkid=2102405.

[Joost Sannen]

So my setup is quite simple. Still missing something?

 

DC with private wildcard certifcate on Active Directory Domain Services

ADC config

 

add server DC1 x.x.x.x
add lb monitor LDAPS_mon LDAP -scriptName nsldap.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -password xxxx -encrypted -encryptmethod ENCMTHD_3 -LRTM DISABLED -secure YES -baseDN "dc=xxxx,dc=local" -bindDN svc.ldap@xxxx.local -filter cn=builtin
add serviceGroup LDAPS_svcg SSL_TCP -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -cltTimeout 9000 -svrTimeout 9000 -CKA NO -TCPB NO -CMP NO
bind serviceGroup LDAPS_svcg DC1 636
bind serviceGroup LDAPS_svcg -monitorName LDAPS_mon
add lb vserver LDAPS_SSL_TCP SSL_TCP x.x.x.x 636 -persistenceType NONE -cltTimeout 9000
bind lb vserver LDAPS_SSL_TCP LDAPS_svcg
bind ssl vserver LDAPS_SSL_TCP -certkeyName [public wildcard certificate)

[Martin Meier]

-----------
res = ldap_simple_bind_s(ld, 'Administrator@kekse-lab.de', <unavailable>); // v.3
Authenticated as: 'KEKSE-LAB\Administrator'.
-----------

I can do a Simple Bind.

[Joost Sannen]

Thanks again Martin. Unfortunately I cannot. Do you have the same ADC config?

[Martin Meier]

2 hours ago, Joost Sannen said:

Thanks again Martin. Unfortunately I cannot. Do you have the same ADC config?

 

my config looks as yours without LDAP based monitor:

add server dc01.kekse-lab.de 172.16.100.10
add lb vserver LDAPS-kekse-lab.de SSL_TCP 192.168.101.44 636 -persistenceType NONE -cltTimeout 9000
add serviceGroup svcgrp-LDAPS-kekse-lab.de SSL_TCP -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -cltTimeout 9000 -svrTimeout 9000 -CKA NO -TCPB NO -CMP NO
bind serviceGroup svcgrp-LDAPS-kekse-lab.de dc01.kekse-lab.de 636
bind serviceGroup svcgrp-LDAPS-kekse-lab.de -monitorName tcp-ecv
bind lb vserver LDAPS-kekse-lab.de svcgrp-LDAPS-kekse-lab.de
bind ssl vserver LDAPS-kekse-lab.de -certkeyName xxxxx.myfritz.net

 

[CarlStalhood]

The Active Directory fully qualified domain name of the domain controller appears in one of the following locations:

The common name (CN) in the Subject field.

The Subject Alternative Name (SAN) extension in the DNS entry.

 

https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/ldap-over-ssl-connection-issues

[Joost Sannen]

Thanks Carl, Martin,

 

I did some more testing after your posts. Imported the public certificate on the Active Directory Domain Services certificate store. Then I can successfully connect and bind through the lb SSL_TCP with the public FQDN. I cannot directly connect to the DC with it's internal FQDN. That's something you don't want.

 

According to the link Carl posted it seems what I want is not possible or at least not supported. There's no way I can get the requirements on a public certificate.

 

The current setup with a public certificate on the lb SSL_TCP and default config of the DC does function till we raise the LDAP settings for the domain controllers

• Domain controller: LDAP server channel binding token requirements - Always
• Domain controller: LDAP server signing requirements - Require signing

Any options left?

[Martin Meier]

So I have a DNS entry (grafana.kekse-lab.de) on my current public IP of the FritzBox.

There I created a port forwarding to the Load Balancing Virtual Server for port 636.

A self-signed SSL certificate is bound to this load balancer that only contains the external FQDN as CN and SAN (grafana.kekse-lab.de).

I installed the self-signed on the external test system as a Trusted Root CA certificate.

The domain controller only knows its own internal certificate from its own CA (dc01.kekse-lab.de).

 

What would be different with a public certificate except that I don't have to install the certificate because the chain should already be valid?

 

 

[Joost Sannen]

Sorry Martin, I missed your response. It probably works because you internal domain has the same kekse-lab.de

[Martin Meier]

53 minutes ago, Joost Sannen said:

Sorry Martin, I missed your response. It probably works because you internal domain has the same kekse-lab.de

 

also works with another domain:

[Sean Bolding1709162698]

On 2/5/2021 at 4:22 AM, Carl Stalhood1709151912 said:

The Active Directory fully qualified domain name of the domain controller appears in one of the following locations:

The common name (CN) in the Subject field.

The Subject Alternative Name (SAN) extension in the DNS entry.

 

https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/ldap-over-ssl-connection-issues

I can confirm that when I created a certificate that listed the LDAPS load balancer fqdn as the common name in the certificate AND added in DNS subject alternative names of all the domain controllers in fqdn format that it works with SSL-TCP. Kudos to Carl! Thanks dude!

[Hugh Lee1709162956]

  

On 2/2/2021 at 4:23 PM, Joost Sannen said:

Error value:

00000057: LdapErr: DSID-0C0C0095, comment: Error decoding ldap message, data 0, v4563

 

Hello.

I got that error code when trying to connect from a linux client (PHP or ldapsearch) to some windows AD server through TLS and authenticate using kerberos / gssapi. Worked fine without TLS.

Solution was to specify "-O maxssf=256" (or less) on ldapsearch or calling ldap_sasl_bind($ldap, null, null, "GSSAPI", null, null, null, "maxssf=256"); in php.