Chapter 13 LDAP Troubleshooting (Reference)

This chapter describes configuration problems and suggests solutions for resolving them.

The LDAP service is managed by the Service Management Facility. Administrative actions on this service, such as enabling, disabling, or restarting, can be performed by using the svcadm command. See LDAP and the Service Management Facility for more information about using the Facility with LDAP. For an overview of the Facility, refer to Chapter 17, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

Monitoring LDAP Client Status

The following sections show various commands to help determine the state of the LDAP client environment. Also see the man pages for additional information about the options that can be used.

For an overview of the Service Management Facility, refer to Chapter 17, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

Verifying ldap_cachemgr Is Running

The ldap_cachemgr daemon must be running and functioning correctly at all times. Otherwise, the system doesn't work. When you start the LDAP client, the client starts ldap_cachemgr daemon automatically. So, if the ldap_cachemgr is not running, the LDAP client will be disabled. Following are two methods for determining if the LDAP client is online.

• Use the svcs command.

  # svcs \*ldap\* STATE STIME FMRI disabled Aug_24 svc:/network/ldap/client:default

  or

  # svcs -l network/ldap/client:default fmri svc:/network/ldap/client:default enabled true state online next_state none restarter svc:/system/svc/restarter:default contract_id 1598 dependency require_all/none file://localhost/var/ldap/ldap_client_file (-) dependency require_all/none svc:/network/initial (online) dependency require_all/none svc:/system/filesystem/minimal (online)

• Pass the -g option to ldap_cachemgr.

  This option provides more extensive status information, which is useful when you diagnose a problem.

  # /usr/lib/ldap/ldap_cachemgr -g cachemgr configuration: server debug level 0 server log file "/var/ldap/cachemgr.log" number of calls to ldapcachemgr 19 cachemgr cache data statistics: Configuration refresh information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:43:28 Server information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:36:08 server: 192.168.0.0, status: UP server: 192.168.0.1, status: ERROR error message: Can't connect to the LDAP server Cache data information: Maximum cache entries: 256 Number of cache entries: 2

For more information about the ldap_cachemgr daemon, see the ldap_cachemgr(1M) man page.

Checking the Current Profile Information

Become superuser or assume an equivalent role, and run ldapclient with the list option.

# ldapclient list
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com
NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f
NS_LDAP_SERVERS= 192.168.0.1, 192.168.0.10
NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_SEARCH_REF= TRUE
NS_LDAP_SEARCH_SCOPE= one
NS_LDAP_SEARCH_TIME= 30
NS_LDAP_SERVER_PREF= 192.168.0.1
NS_LDAP_PROFILE= pit1
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=people,?sub
NS_LDAP_SERVICE_SEARCH_DESC= group:ou=group,dc=west,dc=example,dc=com?one
NS_LDAP_BIND_TIME= 5

Currently the /var/ldap files are in ASCII format. Because the files could change to binary at some time, concatenating the files would cause problems. ldapclient list is the supported method for accessing this information. See the ldapclient(1M) man page for more information.

Verifying Basic Client-Server Communication

The best way to show that your client is talking to the LDAP server is with the ldaplist command. Using ldaplist with no arguments dumps all the containers on the server. This works as long as the containers exist, and do not have to be populated. See the ldaplist(1) man page for more information.

If the first step works, you can try ldaplist passwd username or ldaplist hosts hostname but if they contain lots of data you might want to pick a less populated service, or pipe them to head or more.

Checking Server Data From a Non-Client Machine

Most of the commands in the previous sections assume you already have created an LDAP client. If you have not created a client and want to check the data on the server, use the ldapsearch command. The following example lists all of the containers.

# ldapsearch -h server1 -b "dc=west,dc=example,dc=com" -s one "objectclass=*"

In Solaris 9 and earlier releases, the ldapsearch command, by default, produced output in a nonstandard textual representation. The default output for ldapsearch in later Solaris releases is the industry standardized LDIF format that is defined by RFC-2849. All versions of ldapsearch can output LDIF format using the -L option.

LDAP Configuration Problems and Solutions

The following sections describe LDAP configuration problems and suggests solutions to the problems.

Unresolved Hostname

The Solaris platform LDAP client back end returns fully qualified host names for host lookups, such as host names returned by gethostbyname() and getaddrinfo(). If the name stored is qualified, that is, contains at least one dot, the client returns the name as is. For example, if the name stored is hostB.eng, the returned name is hostB.eng.

If the name stored in the LDAP directory is not qualified (it does not contain a dot), the client back end appends the domain part to the name. For example, if the name stored is hostA, the returned name is hostA.domainname.

Unable to Reach Systems in the LDAP Domain Remotely

If the DNS domain name is different from the LDAP domain name, then the LDAP naming service cannot be used to serve host names unless the host names are stored fully qualified.

Login Does Not Work

LDAP clients use the PAM modules for user authentication during login. When using the standard UNIX PAM module, the password is read from the server and checked on the client side. This can fail due to one of the following reasons:

1. ldap is not used by the passwd service in the /etc/nsswitch.conf file.

2. The user's userPassword attribute on the server list is not readable by the proxy agent. You need to allow at least the proxy agent to read the password because the proxy agent returns it to the client for comparison. pam_ldap does not require read access to the password.

3. The proxy agent might not have the correct password.

4. The entry does not have the shadowAccount object class.

5. No password is defined for the user.

   When you use ldapaddent, you must use the -p option to ensure that the password is added to the user entry. If you use ldapaddent without the -p option, the user's password is not stored in the directory unless you also add the /etc/shadow file by using ldapaddent.

6. No LDAP servers are reachable.

   Check the status of the servers.

   # /usr/lib/ldap/ldap_cachemgr -g

7. pam.conf is configured incorrectly.

8. The user is not defined in the LDAP namespace.

9. NS_LDAP_CREDENTIAL_LEVEL is set to anonymous for pam_unix, and userPassword is not available to anonymous users.

10. The password is not stored in crypt format.

11. If pam_ldap is configured to support account management, login failure could be the result of one of the following:

    • The user's password has expired.

    • The user's account is locked out due to too many failed login attempts.

    • The user's account has been deactivated by the administrator.

    • The user tried to log in using a nonpassword-based program, such as rsh, rlogin, ssh, or sftp.

12. If per-user authentication and sasl/GSSAPI are being used, then some component of Kerberos or the pam_krb5 configuration is setup incorrectly. Refer to the System Administration Guide: Security Services for details on resolving these issues.

Lookup Too Slow

The LDAP database relies on indexes to improve search performance. A major performance degradation occurs when indexes are improperly configured. The documentation includes a common set of attributes that should be indexed. You can also add your own indexes to improve performance at your site.

ldapclient Cannot Bind to Server

ldapclient failed to initialize the client when using the init option with the profileName attribute specified. Possible reasons for failure include the following:

1. The incorrect domain name was specified on the command line.

2. The nisDomain attribute is not set in the DIT to represent the entry point for the specified client domain.

3. Access control information is not set up properly on the server, thus disallowing anonymous search in the LDAP database.

4. An incorrect server address passed to the ldapclient command. Use ldapsearch to verify the server address.

5. An incorrect profile name passed to the ldapclient command. Use ldapsearch to verify the profile name in the DIT.

6. Use snoop on the client's network interface to see what sort of traffic is going out, and determine to which server it is talking.

Using ldap_cachemgr for Debugging

Using ldap_cachemgr with the -g option can be a useful way to debug, as you can view the current client configuration and statistics. For example,

# ldap_cachemgr -g

would print current configuration and statistics to standard output, including the status of all LDAP servers, as mentioned previously. Note that you do not need to become super user to execute this command.

ldapclient Hangs During Setup

If the ldapclient command hangs, pressing Ctrl-C will exit after restoring the previous environment. If this happens, check with the server administrator to ensure that the server is running.

Also check the server list attributes in either the profile or from the command line and make sure that the server information is correct.