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:
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.
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.
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:
- 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:
- 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.
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 cifs/2k8-dc-1.domain.win2k8.netapp.com kadmin/2k8-dc-1.domain.win2k8.netapp.com ldap/2K8-DC-1.domain.win2k8.netapp.com/ForestDnsZones.domain.win2k8.netapp.com ldap/2K8-DC-1.domain.win2k8.netapp.com/DomainDnsZones.domain.win2k8.netapp.com TERMSRV/2K8-DC-1 TERMSRV/2K8-DC-1.domain.win2k8.netapp.com Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/2K8-DC-1.domain.win2k8.netapp.com DNS/2K8-DC-1.domain.win2k8.netapp.com GC/2K8-DC-1.domain.win2k8.netapp.com/domain.win2k8.netapp.com RestrictedKrbHost/2K8-DC-1.domain.win2k8.netapp.com RestrictedKrbHost/2K8-DC-1 HOST/2K8-DC-1/DOMAIN HOST/2K8-DC-1.domain.win2k8.netapp.com/DOMAIN HOST/2K8-DC-1 HOST/2K8-DC-1.domain.win2k8.netapp.com HOST/2K8-DC-1.domain.win2k8.netapp.com/domain.win2k8.netapp.com E3514235-4B06-11D1-AB04-00C04FC2DCD2/277b3b64-265b-4612-a5ac-b06adf2a39b8/domain.win2k8.netapp.com ldap/2K8-DC-1/DOMAIN ldap/277b3b64-265b-4612-a5ac-b06adf2a39b8._msdcs.domain.win2k8.netapp.com ldap/2K8-DC-1.domain.win2k8.netapp.com/DOMAIN ldap/2K8-DC-1 ldap/2K8-DC-1.domain.win2k8.netapp.com ldap/2K8-DC-1.domain.win2k8.netapp.com/domain.win2k8.netapp.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.
C:\>nslookup 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 = 10.228.225.120 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 firstname.lastname@example.org)
- 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 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:
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: