In my time in technical support and as the Technical Marketing Engineer at NetApp, I’ve come to realize that LDAP is one misunderstood technology, which is unfortunate, because I am seeing a large uptick in people who are using it in enterprise environments. As a result, I plan on starting a series of LDAP related posts based on this one, which was originally posted in February of 2015. These will be listed in TECH and LDAP Categories on this blog.
Some topics I’ll be covering (which will become links as they are written):
- General LDAP (covered in this post)
- LDAP binds – Part 2
- LDAP schema attributes – Part 3
- LDAP Distinguished Names – Part 4
- LDAP servers and clients – Part 5
- LDAP and DNS
- Integrating RedHat LDAP with Active Directory LDAP
NOTE: I’m going to keep this real high-level and not bore you with all the details because we could get into the weeds real fast. You can always find copious amount of less interesting information out there in my Technical Reports or on your preferred search engine. If you have specific questions or want me to add something to this entry, hit me up on Twitter @NFSDudeAbides.
What is LDAP?
LDAP is also known as “Lightweight Directory Access Protocol.” It is, essentially, a database that acts as a phone book for all sorts of information for clients and servers in enterprise NAS environments. Some of these include:
- Phone numbers
- Unique numerical identifiers (SID, UID, GID, UUID, etc)
- And many more!
Is Microsoft Active Directory LDAP?
Yes. And no. And maybe.
Microsoft Active Directory uses LDAP for its backend. It leverages LDAP RFC-2307 schema standards and populates records in its database with all sorts of good information about its objects.
For example, this machine account:
However, while Microsoft is a using LDAP and technically could be called LDAP, it’s not LDAP in the traditional sense. That is reserved for the use of UNIX style attributes for users, groups, netgroups and so on. By default, Microsoft does not apply these schema attributes to its implementation of LDAP. However, the schema can be modified or extended to add attributes to populate things like UID, GID, etc.
How does it work?
LDAP functionality works like this, in a simplistic view.
- A database is populated with objects and schema attributes.
- LDAP clients are configured to connect to the LDAP server. This normally means they use port 389 or 636 (LDAP over SSL). Sometimes, the Global Catalog port 3268 can be used when using AD LDAP.
- When a client connects to LDAP, it tries to bind based on the configuration. This can be SASL (such as GSSAPI, DIGEST-MD5, etc), simple or anonymous, depending on what the client and server are configured for/support.
- After a bind, a lookup is done via RFC standards using ldapsearch commands and filter strings.
- If the object and requested attributes exist, they are returned to the client.
Pretty straightforward. The hard part is remembering it. 🙂
What is it used for?
LDAP is used for enterprise NAS environments that want to centralize their identity management rather than keeping track of n number of passwd, group, netgroup and other files. Having LDAP service the clients allows standardized and automated client rollout. All atomic updates are done from the server side and replicated across multiple servers. All a client has to do is connect and search.
In TR-4073: Secure Unified Authentication, I cover LDAP as it pertains to NetApp’s clustered Data ONTAP. It focuses mainly on Microsoft Active Directory as an LDAP server, but also includes information on RedHat’s Directory Server (which is THE best UNIX-based LDAP server I’ve used so far).
Additionally, a new name service best practice guide was just released today. Check out TR-4379: Name Services Best Practices for more info.