LDAP:: In a bind? LDAP can help! – Part 2

This post is part 2 of the new LDAP series I’ve started to help people become more aware of what LDAP is and how it works. Part one was posted here:

What the heck is an LDAP anyway?

This post will focus on the bind portion of LDAP.

What is a “bind”?

Not to be confused with BIND (the DNS server), bind in LDAP is essentially authenticating to the LDAP server to allow access to query for schema attributes. You “bind” to the server and start LDAP-ing.

Binds can occur in one of three main ways.

1. Anonymous

This type of bind is, as the name suggests, extremely insecure. Anonymous binds allow everyone and anyone who has the LDAP server information to query for users, groups, etc. There is no username or password needed. While this is much easier to set up and likely much faster (since we don’t have to ask any questions/give any answers), it’s also not recommended. In fact, many vendors, including Microsoft Active Directory and RedHat, disable anonymous binds by default.

2. Simple

Simple binds are more secure than anonymous binds in that the require a valid user in LDAP with read-only permissions, as well as a password. However, simple binds still aren’t *that* secure, as the password is passed over the wire. In plain text.



With simple binds, it’s possible to use SSL to encrypt the bind to prevent that. In the example below, I connected to my LDAP server over SSL on port 636 using ldp.exe:


My Windows 2008R2 LDAP server supports GSSAPI, GSS-SPNEGO, EXTERNAL and DIGEST-MD5 for SASL. Even though we’re doing simple bind, we still encrypt using the strongest available enctype possible on the LDAP server. In this case, we end up using AES:


And a packet trace shows no LDAP packets – only TLSv1:


Some caveats:

  • Setting up LDAP over SSL on your LDAP server isn’t  the most intuitive thing in the world, but it’s not hard. For Windows, use the following links:

LDAP over SSL Certificate

Using ldp to test connectivity

  • When you use LDAP over SSL, good luck troubleshooting LDAP queries via packet trace. They’re all encrypted now.
  • LDAP clients must have the certs installed as well.


Simple Authentication and Security Layer (SASL) is a security mechanism that allows a variety of different encryption types to be used without the need for setting up certificate services on a LDAP server. It splits the authentication mechanism out and allows more integrated mechanisms to be used. A list of these can be found on the SASL wiki page.

Using our existing setup as an example, I can leverage Kerberos to bind to my LDAP server rather than SSL. Ldp.exe is a great tool to use for this, as I can control how my binds occur. Be on the look out for future posts on that tool…

When I bind via SASL, I see LDAP packets, but my bind doesn’t come across with a username/password. Instead, I am able to use Kerberos to bind. I didn’t even need to provide a username/password at all!

The following query was done from a cluster running clustered Data ONTAP 8.2.3:


In the trace, we’re doing AES-256 (strongest enctype available) to bind using SPNEGO (SPN negotiation). To do this, you would need a SPN with the LDAP server information available.

For example:

C:\>setspn /Q ldap/2k8-dc-1.domain.win2k8.netapp.com
Checking domain DC=domain,DC=win2k8,DC=netapp,DC=com
CN=2K8-DC-1,OU=Domain Controllers,DC=domain,DC=win2k8,DC=netapp,DC=com
Existing SPN found!

Additionally, you’d need a LDAP SRV record in DNS for the specified LDAP server. In this case, I use “domain.win2k8.netapp.com” as my LDAP server.

Default Server: UnKnown
Address: ::1
> set type=all
> _ldap._tcp.dc._msdcs.domain.win2k8.netapp.com
Server: UnKnown
Address: ::1
_ldap._tcp.dc._msdcs.domain.win2k8.netapp.com SRV service location:
 priority = 0
 weight = 100
 port = 389
 svr hostname = 2k8-dc-1.domain.win2k8.netapp.com
2k8-dc-1.domain.win2k8.netapp.com internet address =
2k8-dc-1.domain.win2k8.netapp.com AAAA IPv6 address = fd20:8b1e:b255:8599:5457:61d9:fc87:423f

As luck would have it (ok, design), Microsoft Active Directory is perfect for UNIX based LDAP because it already includes things like SRV records, SPNs, etc. The only time things get hard is when you have to get more customized with the configuration.

You can also do many of the same things with any LDAP server that supports the RFC-2307, RFC-2251, etc. standards.

What can be used to bind?

For authenticated binds, the options for what can be used for binding to LDAP depend on the client. For details, contact the owner of the LDAP client or the docs.

Some of the options include:

  • Name in LDAP DN format. (ie, CN=ldapuser,OU=Users,DC=domain,DC=com)
  • Simple user name. (ie, ldapuser)
  • User principal name (UPN, ie ldapuser@domain.com)
  • Service principal name. (SPN, ie root/fqdn.domain.com)
  • Blank user name. (anonymous binds or binds that negotiate protocols via Kerberos/DNS)
  • CIFS/SMB Machine account. (Often in storage vendors where CIFS is also present)

If using a user to bind with simple or SASL, then the user has to have readonly access to the LDAP schema.

Troubleshooting binds

Troubleshooting binds should be pretty straightforward – you are essentially troubleshooting a login.

The following things should be considered when dealing with binds that are not working properly:

  • Is the LDAP client connecting to the server? (check network, ports, IP, DNS, etc.)
  • Is the LDAP server/hostname correct?
  • Is the bind level correct? Does the client configuration for bind level match what the server supports? (SSL? SASL?)
  • If using SSL, is the LDAP port configuration correct? (Port 389 for LDAP, port 636 for SSL, port 3268 for Active Directory Global Catalog searches)
  • Is the bind user correct? The bind password?
  • If intending to use Kerberos for binds, is there a SPN configured? Are there forward (A/AAAA) and reverse (PTR) DNS records for the LDAP server/domain?

Some tools that come in handy for troubleshooting LDAP:

  • Ping
  • Telnet (to check for ports)
  • Netstat (to check for ports)
  • Nslookup/dig
  • Ldp.exe
  • Ldapsearch
  • Wireshark/tcpdump (my personal favorite)
  • Various logs (Event viewer in MS, /var/log in Linux) – try debug level!

For more detailed information on LDAP configuration (particularly with NetApp clustered Data ONTAP), see TR-4073: Secure Unified Authentication.

Also, stay tuned for more in the series of LDAP basics on this blog! Links to other sections can be found on the first post in this series:

What the heck is an LDAP anyway?

3 thoughts on “LDAP:: In a bind? LDAP can help! – Part 2

  1. Pingback: LDAP::What the heck is an LDAP anyway? – Part 1: Intro | Why Is The Internet Broken?

  2. Pingback: LDAP::LDAP servers and clients and bears, oh my! – Part 5 | Why Is The Internet Broken?

  3. Pingback: LDAP::LDAP Servers and Clients – Part 5 | Why Is The Internet Broken?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s