UPDATE: I realized today that I wrote this same topic twice, in two different posts. This one should be considered the older effort. The newer, up-to-date post is here:
This post is part 5 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.
We’re off to see the Wizard of LDAP!
Clients vs. Servers
LDAP isn’t unlike other protocols, such as HTTP, NFS, etc. There is a client and server relationship. And just like any successful relationship, there needs to be someone talking and someone listening.
I have a two year old son. He talks, but most of it is just practice for him. He’ll say things like “dada, bird truck.” And I’ll say “Bird? Truck? Cool!” It’s mostly a one-sided conversation where I essentially ACK his SYNs. (I need to get out more)
Sometimes, it’s “dada read book.” And I comply.
LDAP client/server conversations aren’t much different. The client is my two year old. The LDAP server is me.
“LDAP, find user information”
“User information? Cool! Here ya go!”
At its very base, LDAP conversations are nothing more than TCP SYNs and ACKs. So, when configuring or troubleshooting, they should be treated as such.
LDAP clients can be anything running software that can query LDAP via RFC-2307 standards. Windows, Linux, storage system OSes, etc can all act as clients. Some operating systems contain built-in LDAP functionality (such as Windows) that doesn’t require you to install anything special. Some storage systems, such as NetApp’s clustered Data ONTAP, fully support LDAP that adheres to the RFC-2307 standard. For more information, see TR-4073: Secure Unified Authentication.
Others, like Linux OSes, need you to install packages to run client operations. Some common Linux-based LDAP clients include:
And many more!
When you install a client, you are far from done. You now have to configure that client to talk to the LDAP server. This requires a plethora of necessary information, including:
Basic network information.
Remember, at its base, it’s a simple TCP conversation.
- LDAP server names, URI or IP addresses (is the server in DNS? Are there SRV records for LDAP?)
- LDAP port (default ports are 389 for LDAP, 636 for LDAP over SSL, 3268 for Global Catalog; did you change the server port?)
- Can the client talk to the server (routing?)
This will depend on type of bind supported by the server. Can be username/password, Kerberos SPN, anonymous, etc. For more detailed info on binds, see part 2 of this series.
LDAP Search Information
This tells the client where to start looking for information in the LDAP server.The format for this information is Distinguished Names (DNs), which I cover in part 4. You can set a base DN and then specific DNs for users, groups, netgroups, etc. You can even specify multiple locations to search. The idea here is to filter our searches to speed things up for the clients.
Fun fact: Apple auto-corrects DNs to DNS. Not cool, Apple. Not cool.
LDAP schema information
I cover schemas in detail on part 3. Many clients know about the default schemas LDAP uses, such as RFC-2307, RFC-2307bis, etc. In most cases, the schemas on the server will not stray from that. But in some instances, such as through manual intervention or 3rd party tools like Dell Vintela (also known as Centrify, Quest, etc), there may be need to make adjustments. This can be done on the client. This allows the client to ask for the right information from the server, which then allows the server to find the information and respond to the client.
Many clients offer specific options like caching of users/groups, credentials, Kerberos configuration, etc. These are generally optional, but should be looked into on a per-client vendor basis.
Sample client configuration
The following is an example of what a clustered Data ONTAP LDAP client would look like:
cluster::*> ldap client show -client-config DOMAIN
Client Configuration Name: DOMAIN
LDAP Server List: 10.228.225.120
Active Directory Domain: domain.win2k8.netapp.com
Preferred Active Directory Servers: -
Bind Using the Vserver's CIFS Credentials: false
Schema Template: WinMap
LDAP Server Port: 389
Query Timeout (sec): 3
Minimum Bind Authentication Level: sasl
Bind DN (User): ldapuser
Base DN: dc=domain,dc=win2k8,dc=netapp,dc=com
Base Search Scope: subtree
User DN: cn=users,dc=domain,dc=win2k8,dc=netapp,dc=com
User Search Scope: subtree
Group DN: cn=users,dc=domain,dc=win2k8,dc=netapp,dc=com
Group Search Scope: subtree
Netgroup DN: -
Netgroup Search Scope: subtree
Vserver Owns Configuration: true
Use start-tls Over LDAP Connections: false
Allow SSL for the TLS Handshake Protocol: -
Enable Netgroup-By-Host Lookup: true
Netgroup-By-Host DN: -
Netgroup-By-Host Scope: subtree
This is what my client configuration running SSSD looks like:
# cat /etc/sssd/sssd.conf
cache_credentials = True
case_sensitive = False
config_file_version = 2
services = nss, pam
domains = DOMAIN
debug_level = 7
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
filter_groups = root
id_provider = ldap
auth_provider = krb5
case_sensitive = false
chpass_provider = krb5
cache_credentials = false
ldap_uri = _srv_,ldap://domain.win2k8.netapp.com
ldap_search_base = dc=domain,dc=win2k8,dc=netapp,dc=com
ldap_schema = rfc2307
ldap_sasl_mech = GSSAPI
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_group_member = memberUid
ldap_group_name = cn
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
ldap_user_search_base = cn=Users,dc=domain,dc=win2k8,dc=netapp,dc=com
ldap_group_search_base = cn=Users,dc=domain,dc=win2k8,dc=netapp,dc=com
ldap_sasl_authid = root/centos64.domain.win2k8.netapp.com@DOMAIN.WIN2K8.NETAPP.COM
krb5_server = domain.win2k8.netapp.com
krb5_realm = DOMAIN.WIN2K8.NETAPP.COM
krb5_kpasswd = domain.win2k8.netapp.com
If you want somewhere for the clients to ask for information, you need a server. The server needs to have a valid RFC-2307 schema to contain the necessary LDAP objects. If you’re doing UNIX-based LDAP and want to use Microsoft Active Directory to serve UNIX-based authentication, then you’d need to ensure the server has UNIX attributes in the schema. While Microsoft Active Directory runs on a LDAP backend, it’s not true UNIX-based LDAP server until you extend the schema. I talk a bit about this in my blog post on IDMU.
As mentioned in the client section, you need a bunch of information to configure clients. The server is where this information comes from. Here’s the stuff you need to check on the server to ensure you configure your clients correctly:
- Server network info (IP address, hostname, DNS entries, SRV records, LDAP server ports, etc.)
- Supported bind level (use the strongest available, if possible)
- Valid bind user or SPN
- DN information
- Schema type/attributes
LDAP servers can host tons of information. UNIX user creds, Windows creds, netgroups, IP addresses, SPNs, name mapping rules…. It just depends on what the clients support that determines what you can use.
If you are using multiple LDAP servers and a client is not able to find an object in the specified LDAP server’s domain, it may attempt to use an LDAP referral to look in the other servers. Essentially, it takes information in the LDAP server about other servers we know about and attempts to connect to them via LDAP URI until it either a) finds the object or b) runs out of servers to try. This can happen in both Windows and non-Windows LDAP servers. Some LDAP clients do not support “referral chasing,” so it’s important to know if this is happening in your environment and if your client is able to chase referrals.
Global Catalog Searches
In Active Directory, it is possible to store a copy of attributes from multiple domains in a forest on local domain controllers acting as Global Catalog servers. By default, UNIX attributes don’t get replicated to the Global Catalog, but you can change that behavior as needed. I cover how to do this in TR-4073. If you need to query multiple domains in the same forest and want to avoid LDAP referrals, you can simply replicate the necessary attributes and change the LDAP port to 3268 to let the servers know to use the Global Catalog instead!
In my environment, I use Active Directory LDAP with Identity Management. But I’ve been known to use OpenLDAP and RedHat Directory Services. Both are perfectly valid to use. However, if you’re intent on doing multiprotocol NAS (CIFS/SMB and NFS), I strongly suggest using Microsoft Active Directory for authentication for UNIX and Windows users. Makes life infinitely easier.
If you are already using Linux-based LDAP, that’s fine. If possible, try to ensure the UNIX user names (uid LDAP attribute) match the Windows user names (sAMAccount attribute). That way, if you are using multiprotocol NAS, you don’t have to worry about name mapping.
If you want to see anything added to this post regarding LDAP servers and clients, feel free to comment or follow me on Twitter @NFSDudeAbides!