LDAP Proxy Failing to Connect


#1

Hi All,

I’m running into a problem where I can’t seem to make my ldap proxy work. I have several proxies behind an F5 load balancer doing Layer 4 load balancing. They’re all running CentOS with minimum specs (1g of mem, 2 cpu, plenty of drive space).

When I try to ldapsearch against it I just get ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1). I don’t get a push notification. Appending a code also fails.

An odd thing I noticed is I was able to ldapsearch on the server against itself via 127.0.0.1 and that returned something but it never prompted for 2fac.

Things I’ve verified:

  • telnet works between each point
  • firewalls are open between all
  • ad_client works because I have radius proxies working that leverage i
  • certificate is good and signed by our CA

Example Config:

[main]
client=ad_client

[duo_only_client]

[ad_client]
host=ldap.contoso.com
search_dn=DC=CONTOSO,DC=COM
service_account_username=SERVICEACCOUNT
transport=ldaps
ssl_ca_certs_file=ca_certs.pem
ssl_verify_hostname=true
service_account_password=REMOVED

[ldap_server_auto]
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
client=ad_client
failmode=safe
ssl_port=636
ssl_key_path=ldap_server.key
ssl_cert_path=ldap_server.pem
skey=REMOVED
ikey=REMOVED

[radius_server_auto]
...

Is there anything I’m missing? Someway I can try to auth against it and verify.


#2

Hey HeyItsGilbert,

When you try your ldapsearch (that fails) does the Duo Authentication proxy log show any errors? Does the proxy even see the incoming request?

I’d also suggest testing plain LDAP connections (unsecured 389) just to verify the proxy is listening and responding at all.

You may find our instructions for enabling authentication proxy debug logging and our guide to interpreting log output useful.

Thanks for trying Duo!


#3

Agreed on trying un-encrypted port 389. Is your F5 doing any SSL termination? Any chance you can try layer 7 just to see? I’m interested in what you find as I’ve toyed with this idea as well.


#4

Here’s what I get when I run: ldapsearch -x -H ldap://duoproxy01.contoso.com:389 -b "dc=contoso,dc=com" -W -D "contoso\gsanchez" '(cn=gsanchez)' SamAccountName

# extended LDIF
#
# LDAPv3
# base <dc=contoso,dc=com> with scope subtree
# filter: (cn=gsanchez)
# requesting: SamAccountName
#

# search reference
ref: ldaps://ForestDnsZones.contoso.com/DC=ForestDnsZones,DC=contoso,D
 C=com

# search reference
ref: ldaps://DomainDnsZones.contoso.com/DC=DomainDnsZones,DC=contoso,D
 C=com

# search reference
ref: ldaps://contoso.com/CN=Configuration,DC=contoso,DC=com

# search result
search: 2
result: 0 Success

# numResponses: 4
# numReferences: 3

The odd part is that I don’t get prompted for a duo push.


#5

There’s no SSL termination although that would make things easier for us long term. At this point I’m just trying against a specific machine to remove the F5 from the equation. I’m running an older version of the app so I’m gonna go upgrade to see if that fixes the issue.


#6

By default we exempt the first bind from Duo auth to support a service account binding to search for user who initiated the authentication attempt. If you check your authentication proxy’s logs you should se an event to that effect logged when you bound ldapsearch as contoso\gsanchez.

For your ldapsearch test you probably want to set exempt_primary_bind to false. Learn more about that option here.