Troubleshooting
This chapter describes configuration problems and suggested solutions.
Monitoring Client Status
This section shows various commands that can be used to help determine the state of the LDAP client environment. For more information see the section on troubleshooting which will give more information on common problems and how to solve them. Also see the man pages for additional information on the options that can be used.
Verifying ldap_cachemgr is running
The ldap_cachemgr daemon must be running and functioning correctly at all times. Otherwise, nothing works. There are two ways to check if ldap_cachemgr is running.
Use ps -ef.
# ps -ef | grep ldap_cachemgr
Pass the -g option to ldap_cachemgr.
This causes it to dump the following status information, which is useful when you must 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
Checking the Current Profile Information
Become superuser 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.0, 192.168.0.1 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.0 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, but that could change to binary at some time and cating the files would cause problems. ldapclient list is the supported method for accessing this 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. The simplest form, ldaplist with no arguments will dump all the containers on the server. This works as long as the containers exist, and do not have to be populated. 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 above assume you are already 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=*"
Configuration Problems and Solutions
The following discussion briefly describes LDAP configuration problems and suggested solutions to the problems.
Unresolved Hostname
The Solaris operating environment LDAP client backend returns fully qualified hostnames for host lookups, such as hostnames returned by gethostbyname(3N) and getipnodebyname(3N). 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 any dot), the client backend 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(3) modules for user authentication during the logins. 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.
ldap not used by the passwd service in the /etc/nsswitch.conf file
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
Proxy agent might not have correct password
The entry does not have the shadowAccount objectclass
There is no password 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 used ldapaddent without using the -p option, the, users's password will not be stored in the directory unless you also add the /etc/shadow file using ldapaddent.
None of the LDAP servers are reachable.
Check the status of the servers.
# /usr/lib/ldap/ldap_cachemgr --g
pam_conf is configured incorrectly.
The user is not defined in the LDAP namespace.
NS_LDAP_CREDENTIAL_LEVEL is set to anonymous for pam_unix and userPassword attribute is not available to anonymous users.
Password is not stored in crypt format.