Troubleshooting Tips

Murphy's law states that whatever can go wrong, will go wrong. While it is impossible to anticipate every conceivable misconfiguration or malfunction that can cause LDAP failures, there are common pitfalls, and the following sections offer some suggestions on how to recognize and correct these common problems:

• "Directory Server Configuration Problems" on page 260

• "Sun ONE Console Problems" on page 263

• "Server Configuration Problems" on page 266

• "Secured LDAP Client Problems" on page 268

• "Authentication Problems" on page 270

The suggestions describe how to use the following tools:

• Directory server access and error logging

• The Solaris OE snoop command

• Process tracing

• Solaris OE ldapclient and ldaplist commands

A detailed discussion on the use of these tools appears in Chapter 6 "Management Tools and Toolkits" and Appendix C, "Using snoop with LDAP." If you are unfamiliar with the tools discussed here, consult that chapter first.

Directory Server Configuration Problems

Directory server installation is not a common area in which to experience trouble, especially if you are installing the bundled version. However, there are four common problems that you might encounter:

1. The Solaris OE is missing a critical patch.

2. The DNS Fully Qualified Name (FQN) specified during the setup procedure is not resolvable by the host it is being installed on.

3. The directory server port that was selected is already in use.

4. The 64-bit version is being installed on a system running a 32-bit kernel.

These problems usually result in error messages during the installation or during the final step when the directory server is started for the first time. To diagnose these problems, perform the following procedures. After you fix the problem you should run setup or configure again.

To Troubleshoot a Missing Solaris OE Patch

1. Watch for possible errors displayed during the installation .

   The errors might also be observed by examining the directory server error log, either through the Directory Console, or the /var/mps/serverroot/slapd instance/ logs/error file. Directory Server errors have numbers associated with them so they can be cross-referenced.

2. Rerun the idsktune program on the system where the directory server is being installed .

   Before installing the directory server, you should run the idsktune command and make sure all the required patches are applied. The command does not actually modify anything, so it can be rerun after the installation to verify that the required patches were indeed applied. More details on idsktune are in "To Run the idsktune Command" on page 216.

3. Check SunSolve ^sm services for the latest patches .

   If you are running the bundled Solaris 9 OE directory server, a missing patch should not be an issue. However, if you have downloaded an older version of the directory server, it is conceivable that the version of idsktune you run will not be aware of newer required patches. You can always download the latest version of idsktune from the directory product page on the sun.com web site if you are unsure of the version you are running. The Solaris Patch Manager Tool and PatchPro utility are also useful for managing patches. Information on these utilities can be found at http://sunsolve.sun.com.

To Troubleshoot DNS FQN Failures

1. When the directory server is started for the first time (at the end of the setup program), watch for errors .

   A common error looks like the following example:

    Start Slapd Starting Slapd server configuration. ERROR: Ldap authentication failed for url ldap://myserver.example.com:389/o=NetscapeRoot user id admin (151:Unknown error.) Fatal Slapd Did not add Directory Server information to Configuration Server. ERROR. Failure installing iPlanet Directory Server. Do you want to continue [n]? 

   Notice the third line where the FQN is shown ( myserver.example.com , in this example).

2. Make sure you can ping the FQN as a default for the host name during setup .

   Example:

    #  ping -s myserver.example.com 56 1  PING example: 56 data bytes 64 bytes from myserver.example.com (129.148.181.98): icmp_seq=0. time=0. ms ----example PING Statistics---- 1 packets transmitted, 1 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/0 

If you get a response such as ping: unknown host myserver.example.com , check the /etc/nsswitch.conf file to see if it is set up to search DNS. You can also add the FQN as an alias in the local /etc/ hosts file, then rerun setup .

What to Do When the Directory Server Port Is Already in Use

This situation usually exhibits itself during setup when the default port number of the directory server is displayed. If the displayed number in brackets is not [ 389 ], chances are there is another directory instance running on that port. Another reason that port 389 may not listed as the default is if the installation is being performed as a non-root user. In this case, only ports above 1024 are available for configuration.

1. Check to see if another directory service instance is running .

   Run the following command:

    #  ps -elf  grep ns-slapd  8 R root 2039 1804 . . . . . ./ns-slapd -D /opt/iplanet/servers/ 

   If a process is running, the abbreviated output shows you the installation directory. The pathname to the right of the output pinpoints the process from which it was started. You can then go to that location and issue the appropriate stop-slapd command to stop the other instance.

2. Check to see if a process is running on the port you wish to use for the directory server .

   For example, to check port 389:

    #  netstat -an  grep 389  . . . *.  389  *.* 0 0 24576 0 LISTEN 192.9.200.1.33611 192.9.200.1.  389  32768 0 32768 ESTABLISHED 

   The output of the netstat command shows you if the port number is listening to, or has a connection to, the port you specified. You can also use this check to make sure the directory server you are running is really listening on the port you think it is. If another process is already listening on the port, you can use the open source lsof utility to identify the process using that port.

To Recognize an Incompatible Installation of the 64-Bit Version on a 32-Bit System

This problem presents itself when the package dependencies are checked. If you ignore the messages and proceed with the installation, the directory configuration fails.

Remove all the packages you just installed and only install the packages without a trailing x in their name .

Sun ONE Console Problems

The Sun ONE Console can fail to start for several reasons. Problems in this area often have to do with the Console having dependencies on other processes. If the Console is started from a window shell that is logged in as a different user than the desktop, the user must be granted permission (with xhost + ) to access the display. In addition, the administration and directory servers must be running before the Console can start.

Some of the potential problems are:

• You are invoking the console on a display you do not have permission to access.

• The administration server is not running, or the address or port number is not correct.

• The directory server is not running or having problems.

To Invoke startconsole on a Protected Display

The console is an X-based application and the X-server must permit access. This situation is a common one because it is typical to log in, then switch to another user, (for example, root) to perform administrative functions. When you try to start the Console, you receive the following error:

 #  /usr/sbin/directoryserver startconsole &  Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server Console: Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable. 

To fix this problem, type the following command as the user to which the desktop display belongs.

 $  xhost +  access control disabled, clients can connect from any host 

Note

For production use, you should not use just the "+" sign. Instead, specify the IP address of the system you are granting access to or connect to the system running the Console with Secure Shell (SSH).

To Troubleshoot Console Login Rejections

1. Run the startconsole command .

   You should see this screen:

   

2. Check the address in the Administration URL field to make sure it is correct .

   The address that appears by default is obtained from the Console.4.0.Login.preferences file located in the .mcc directory in your home directory. This file is not removed when you uninstall the directory server, so the file might exist from an earlier directory server installation. If you type in the correct address, the console preference file is automatically updated.

3. Make sure the administration server is running .

    #  ps -elf  grep ns-httpd  8 S root 580 579 . . .0:01 ns-httpd -d /var/mps/serverroot/adm 

   By specifying the -el options, the command path name (or at least part of it) is displayed.

4. View the parameters the administration server is using by looking at the adm.conf file .

    #  cd /var/mps/serverroot/admin-serv/config  #  cat adm.conf  ldapHost:  myserver.example.com ldapPort:    389 sie:  cn=admin-serv-myserver, cn=Netscape Administration Server, cn=Server Group, cn=myserver.example.com, ou=example.com, o=NetscapeRoot siepid:  admin isie:   cn=Netscape Administration Server, cn=Server Group, cn= myserver.example.com, ou=example.com, o=NetscapeRoot port:   20000 ldapStart: slapd-veda/start-slapd 

   You can see from this file that the LDAP host containing the required configuration data is myserver.example.com on port 389 . It also shows that the administration server is running on port 20000 .

5. Make sure the directory server is running .

    #  ps -ef  grep slapd  root 6329 1 0 Feb 27 ? 0:34 ./ns-slapd -D /var/mps/serverroot/ slapd-myserver -i /var/mps/serverroot/slapd-my 

6. Verify the URL used to connect with begins with https if the administration server is set up to listen on a secure port (FIGURE 4-3) .

   Figure 4-3. Sun ONE Server Console Login Dialog Box

   

Server Configuration Problems

To Troubleshoot idsconfig Failures

If the idsconfig script is run after the directoryserver configure command provided with Sun ONE Directory Server 5.2, you should not encounter problems. However, if you run the script against an unbundled version of the Sun ONE Directory Server, you might have a problem. One known issue is with the 5.1sp1 release. For example, you might see the error message:

 ERROR: update of schema attributes failed! 

1. If you see this error, add a comment symbol (#) to the lines shown below in the schema files located in the ./config/schema/10rfc2307.ldif directory .

     #  attributeTypes: ( 1.3.6.1.1.1.1.25 NAME 'automountInformation' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4. 1.1466.115.121.1.26 X-ORIGIN 'RFC 2307' )  #  objectClasses: ( 1.3.6.1.1.1.2.9 NAME 'automount' DESC 'Standard LDAP objectclass' SUP top MUST ( cn $ automountInfo rmation ) MAY ( description ) X-ORIGIN 'RFC 2307' ) 

2. After the changes are made, stop, then restart the directory server .

To Diagnose Other idsconfig Problems

Watch for the following database- related problem .

The following error is usually caused by using a back-end database name other than userRoot . The problem can be fixed by modifying the idsconfig script and commenting out the check database back ends. Contact Sun service for additional information.

 ERROR: Cannot determine the top of the tree 

Other script failures can be debugged by running the idsconfig script with the -x option and observing the commands that were being run at the point where the idsconfig script failed.

 #  vi /usr/lib/ldap/idsconfig  . . . #!/bin/sh  -x  . . . 

Secured LDAP Client Problems

These client problems might exhibit any of the following symptoms:

• Client fails to initialize.

• Client initializes, but cannot access data.

• Client can see data, but users cannot log in.

To Troubleshoot Client Initialization Problems

1. Watch for profile or domain name errors .

   A common problem is that either the profile name entered on the command line or the domain name the client is set to does not match the server setting. A common error message might look like this:

    NOTFOUND:Could not find the nisDomainObject for DN dc=example, dc=com findDN: __ns_ldap_list(NULL, "(&(objectclass= nisDomainObject)(nisdomain=foo))" 

   In this example, the client either had its /etc/defaultdomain value set to foo or foo was specified with the ldapclient -d argument.

2. Check the value set in the directory with the ldapsearch command .

   Example:

    #  ldapsearch -h myserver -b dc=example, dc=com nisdomain=\*  dc=example objectClass=top objectClass=organization objectClass=nisDomainObject dc=example nisDomain=notfoo 

The problem can be fixed by specifying notfoo as the domain name or by modifying the value of the nisDomain attribute on the directory server.

To Troubleshoot Client Data Access Problems

If an initialized Solaris LDAP client cannot access naming service, check the following.

Check the name service containers with the ldaplist command .

If the client is set up correctly, you should be able to see the name service containers as shown in the following example:

 #  ldaplist  dn: cn=Directory Administrators, dc=example, dc=com dn: ou=People, dc=example, dc=com dn: ou=Special Users, dc=example, dc=com dn: ou=group, dc=example, dc=com dn: ou=Groups, dc=example, dc=com dn: ou=rpc, dc=example, dc=com . . . 

You might see this instead:

 #  ldaplist  ldaplist:Object not found(Session error no available conn.) 

This indicates the client is unable to access the data using the authentication method defined for it. Even though the client might have initialized without problems, the following misconfigurations could exist:

• The proxyDN or proxypassword entered on the command line could be wrong.

• The directory server certificate might contain a DNS address that the client is unable to resolve.

To verify the proxyDN and associated proxypassword , try to bind to the directory server using a command like ldapsearch .

  # ldapsearch -D "cn=proxyagent, ou=profile, dc=example.com" -w mysecret -b dc=example, dc=com objectclass=\*  

If the ldapsearch command fails, make sure the password is what you think it is. If it succeeds, check the content of /var/ldap/ldap_client-cred for misspelling. For clients using the TLS:SIMPLE authentication method, check the server certificate header for the address of the directory server and make sure you can ping that address.

Authentication Problems

To Troubleshoot Password Authentication Problems

After the client is successfully initialized, users might not be able to log in. This is a common problem that can be caused by a variety of configuration errors.

If users cannot get authenticated, the first thing to do is to verify the entry for the user who is trying to log in. You can do this with either the ldapsearch or ldaplist command as shown below.

1. Use the ldaplist command to verify the user's entries .

    #  ldaplist -l passwd tom  dn: uid=tom, ou=people, dc=example, dc=com objectClass: posixAccount objectClass: shadowAccount objectClass: account objectClass: top uid: tom cn: tom uidNumber: 12050 gidNumber: 10 gecos: Tom Bialaski - Enterprise Engineer homeDirectory: /home/tom loginShell: /bin/csh userPassword: {crypt}SnLaPR6XvcJV6 shadowLastChange: 11892 shadowFlag: 0 # 

   By specifying the -l option and the uid of the user, the entire entry for that user is displayed. The number of attributes and object classes will depend on your environment, but the entry must contain both the posixAccount and shadowAccount object classes. The userPassword attribute must contain a non-NULL value for authentication to work with pam_unix.

   In this example, the userPassword attribute and its value is displayed. This is because the directory server is configured to support pam_unix style authentication. What this means is the proxy agent account that was created by the idsconfig setup script has read and search privileges for that attribute. This is not a requirement for pam_ldap style authentication.

   The format of how the password is stored helps determine how authentication is performed. If pam_unix is used, the userpassword attribute is prefixed with {crypt} . If pam_ldap is used, the userpassword attribute might show up as a different hash format like {SSHA} . If it does, this could indicate a security hole by allowing read access to the proxy agent's userPassword attribute. Note that the Directory Manager will always be able to read passwords.

2. (Alternative) Use the ldapsearch command to verify the user's entries .

   An alternative way to check the user entry is with the ldapsearch command, as shown below.

     # ldapsearch -D "cn=directory manager" -w mysecret -b \ ou=people, dc=example, dc=com uid=michael  uid=michael, ou=people, dc=example, dc=com objectClass=posixAccount objectClass=shadowAccount objectClass=account objectClass=top uid=michael cn=michael uidNumber=2505 gidNumber=10 gecos=Michael Haines - Professional Services homeDirectory=/home/michael loginShell=/bin/csh userPassword={SSHA}irwM5kV7M5zNFuJgpYJEd+SF6YIbfEBNeiVJfQ== shadowLastChange=11892 shadowFlag=0 

   In this example, the password is stored in the Salted Secure Hashing Algorithm (SSHA) format and can only be used with pam_ldap authentication.

3. Use the snoop command to monitor communication between the client and server .

   If the user entry looks correct, the next step is to monitor the handshake activity that takes place while the client is attempting to access the server. An easy way to do this is to run the snoop command while authentication is attempted.

   In the following example, no data encryption is used, so everything comes across the network in clear text. An alternative for debugging data-encrypted communication is to turn on process tracing, which is discussed later. You may wish to verify that everything works first before turning encryption on.

   The following partial snoop trace shows the initial bind that takes place when a client using proxy credentials first contacts the server.

    #  snoop -v ldap  grep LDAP  LDAP:     ----- Lightweight Directory Access Protocol Header ---- LDAP:       *[LDAPMessage] LDAP:          [Message ID] LDAP:         Operation *[APPL 0: Bind Request] LDAP:             [Version] LDAP:             [Object Name] LDAP:                 cn=proxyagent, ou=profile, dc=example, dc=com LDAP:            Authentication: Simple [0] LDAP:                 test1234 LDAP:         Operation *[APPL 0: Bind Response] LDAP:             [Result Code] LDAP:              Success 

   The key here is the distinguished name ( DN ), which is cn=proxyagent , ou= profile , dc=example , dc=com , and the associated password of test1234 . These are the credentials the client attempted to bind with. Assuming they match, a Success result code is returned.

Authentication Examples

The method used to authenticate users is determined by how the pam.conf file is constructed on the client system. For the examples, the following Solaris 9 OE configuration file is used.

 #  cat /etc/pam.conf  # Authentication management # # login service (explicit because of pam_dial_auth) # login   auth requisite          pam_authtok_get.so.1 login   auth required           pam_dhkeys.so.1 login   auth sufficient         pam_unix_auth.so.1 login   auth required           pam_ldap.so.1 try_first_pass login   auth required           pam_dial_auth.so.1 

This is the recommended stacking of PAM modules as discussed in Chapter 3 "Defining Directory Service Security Architecture." With a file set up like this one, pam_unix authentication is tried first, and if it succeeds, the user is authenticated. If it fails, pam_ldap is tried. The following sections show traces of how this is done.

Authentication with pam_unix

In this example a user called tom logs in. The user's password is stored in {crypt} format (highlighted in bold text).

 LDAP:      Operation *[APPL 4: Search Request] LDAP:          [Base Object] LDAP:              ou=people, dc=example, dc=com ..... LDAP:            Equality Match *[3] LDAP:                [Attr Descr] LDAP:                      objectClass LDAP:                [Value] LDAP:  shadowAccount  LDAP:            *[3] LDAP:                [OctetString] LDAP:                      uid LDAP:                [OctetString] LDAP:  tom  

The trace shows that a search is performed in the ou=people container for an entry that contains the shadowAccount object class and an uid attribute equal to tom . The search base of ou=people , dc=example , dc=com is determined by values set in the client profile that the client is configured to use. The following trace shows the result of this search.

 LDAP:      Operation *[APPL 4: Search ResEntry] LDAP:          [Object Name] LDAP:  uid=tom, ou=people, dc=example, dc=com  LDAP:         *[Partial Attributes] LDAP:            *[Attribute] LDAP:                [Type] LDAP:                      uid LDAP:               *[Vals] LDAP:                     [Value] LDAP:  tom  LDAP:            *[Attribute] LDAP:                [Type] LDAP:                      userpassword LDAP:               *[Vals] LDAP:                     [Value] LDAP:  {crypt}SnLaPR6XvcJV6  

The search in this case finds an entry with a DN of uid=tom , dc=sun , dc=com that matches the search criteria. The value of the userpassword attribute is then retrieved. If the value matches the password that the user entered, the authentication criteria is satisfied so pam_ldap is never invoked. If the value does not match, then pam_ldap is invoked as shown in the next example.

Authentication with pam_ldap

In the following example, a user called michael attempts to log in. In this case the password for the account is not stored in {crypt} format so the attempt at pam_unix authentication fails. The try_first_pass option is specified in pam.conf , so the user is not prompted to enter an LDAP password. Instead, the first password entered is tried. If, however, the password entered was mistyped , the user is prompted for an LDAP password. In this example, it is assumed that the password entered the first time is correct.

 LDAP:      Operation *[APPL 3: Search Request] LDAP:          [Base Object] LDAP:              ou=people, dc=example, dc=com LDAP:          [Scope] LDAP:           singleLevel LDAP:          [DerefAliases] LDAP:           derefAlways LDAP:          [SizeLimit] LDAP:          [TimeLimit] LDAP:          [TypesOnly] LDAP:         And *[0] LDAP:            Equality Match *[3] LDAP:                [Attr Descr] LDAP:                      objectclass LDAP:                [Value] LDAP:  posixAccount  LDAP:            *[3] LDAP:                [OctetString] LDAP:                      uid LDAP:                [OctetString] LDAP:  michael  

In this example, a search is made for an entry that contains the posixAccount object class and has a uid attribute value equal to michael . This search is somewhat different than the one performed for pam_unix in that the posixAccount object class is specified instead of the shadowAccount object class, and the userpassword attribute value is not requested .

If the search is successful, the DN of the entry is returned, which is used in the next example to bind to the directory.

 LDAP:   ----- Lightweight Directory Access Protocol Header ---- LDAP:     *[LDAPMessage] LDAP:        [Message ID] LDAP:       Operation *[APPL 0: Bind Request] LDAP:           [Version] LDAP:           [Object Name] LDAP:  uid=michael, ou=people, dc=example, dc=com  LDAP:          Authentication: Simple [0] LDAP:  mysecret  ..... LDAP:       Operation *[APPL 1: Bind Response] LDAP:           [Result Code] LDAP:            Success 

In this example, the entry found that satisfied the search criteria has a DN of uid= michael , ou=people , dc=example , dc=com . Using this DN along with the password, the bind request is attempted. If the request is successful, the user is authenticated. A key difference between pam_unix authentication (discussed in the previous example) is that the password entered by the user is sent to the directory server. In the example, no data encryption is used, so the password is sent in clear text. In production use, you would want to use data encryption, but for debugging purposes, sending it in clear text is helpful. If it works with clear text, then data encryption can be turned on.

Authentication Problem Summary

The following is a summary of possible symptoms and corrective actions for common authentication problems.

pam_unix Problems

• Proxy agent bind fails

  This problem can be caused by having an incorrect DN specified in the ldap_client_cred or password. This can be checked by trying to bind to the directory with the same credentials the client is using.

  Example:

   #  ldapsearch -D "cn=proxyagent,ou=profile,dc=example,dc=com" -b \ dc=east, dc=sun,dc=com objectclass=\*  Bind Password:  wrong_password  ldap_simple_bind_s: Invalid credentials 

  or

   #  ldapsearch -D cn  =proxyagent,  ou=profile,dc=example,dc=com -b \ dc=sun,dc=com objectclass=\*  Bind Password: ldap_simple_bind_s: No such object 

• User entry not found

  This could be caused by the entry missing the shadowAccount attribute, a bad search base, or a wrong value for the uid attribute.

• Password is not retrieved

  This can be caused by not having the correct ACI set. You can check it by running the following command and observing the output.

   #  ldapsearch -D "cn=directory manager" -b dc=example,dc=com \ aci=\* aci  Bind Password:  *******  . . . dc=example,dc=com aci=(targetattr = "cnuiduidNumbergidNumberhomeDirectoryshadowLastChange shadowMinshadowMaxshadowWarningshadowInactiveshadowExpi reshadowFlagmemberUid")(version 3.0; acl LDAP_Naming_Services_deny_write_access; deny (write) userdn = "ldap:///self";) aci=(target="ldap:///dc=east,dc=sun,dc=com")(targetattr= "userPassword")(version 3.0; acl LDAP_Naming_Services_proxy_password_read; allow (compare,read,search) userdn = "ldap:///cn=proxyagent,ou= profile,dc=example,dc=com";) . . . 

  If this ACI does not exist or has wrong information, the proxyagent account will not be able to search for and read the password. This ACI should have been set up by the idsconfig script, but might be missing if it failed or if it was manually configured and another configuration process was used.

• No RPC Credentials warning message

  This message might appear on some Solaris 8 OE clients. It usually occurs when the user's password cannot be retrieved by pam_unix . If this happens, pam_unix attempts to obtain RPC credentials to authenticate against, but cannot find any. A notification of this is mistakenly sent, even though this is normal behavior if pam_unix is stacked before pam_ldap and the directory does not allow the password to be read. This message can be ignored.

Automounter Problems

The Solaris OE automounter relies heavily on a naming service to obtain the information it requires to function properly. If the information cannot be obtained or is incorrect, the automounter will fail to work. Identifying the source of the problem can be tricky because you might only see a message like this:

 #  cd /home/tom  /home/tom: No such file or directory 

The first step in diagnosing the problem is to determine where the automounter is looking for the information it needs. You can start by looking at the /etc/nsswitch.conf file that the client is using.

 #  cat /etc/nsswitch.conf  . . . hosts:      ldap [NOTFOUND=return] files .... automount:  files ldap . . . #  cat /etc/auto_master  /net            -hosts           -nosuid,nobrowse /home           auto_home        -nobrowse /xfn            -xfn /tools          auto_tools       -nobrowse +auto_master 

The two key entries here are hosts and automount . The hosts entry is used to resolve the address of the NFS server specified in the autofs mount entry, and the automount entry is used to determine where to look for the auto_master entry. In this example, files is searched first, so the /etc/auto_master file is consulted to identify autofs mount points. The +auto_master notation instructs autofs to consult a name service if the mount point is not found in the file.

To see the entry on the directory server, run the following command:

 #  ldaplist -l auto_home tb250  dn: cn=tb250,nisMapName=auto_home,dc=example,dc=com         objectClass: nisObject         objectClass: top         cn: tb250         nismapentry: nfsserver:/export/home7/tb250         nismapname: auto_home 

From the output, you can see an old style notation specifying nisObject to define automount objects. This definition does not work with the Phase 2 clients unless objectclass mapping is implemented.

 #  ldaplist -l auto_home tb250  dn: automountKey=tb250,automountMapName=auto_home,dc=example,dc=com         objectClass: automount         objectClass: top         automountKey: tb250         automountInformation: nfsserver:/export/home7/tb250 # 

This output shows the Phase 2 definition for the automount object is used. These objects do not work with Phase 1 clients or Phase 2 clients using Version 1.0 client profiles.

To see what the automounter is doing, you can turn on debugging as shown in this example.

 #  /etc/init.d/autofs stop  #  /usr/lib/autofs/automountd -vTT  #  /usr/sbin/automount -v  automount: /net mounted automount: /home remounted automount: /xfn mounted automount: no unmounts #  cd /home/tom  LOOKUP REQUEST: Thu Aug 22 08:46:39 2002 name=tb250[] map=auto_home opts=nobrowse path=/home direct=0 getmapent_ldap: key=[ tom ] ldap_match: ldapkey =[ tom ] ldap_match: searchfilter =[ (&(objectClass=nisObject) (nisMapName=auto_home)(cn=tom)) ] ldap_match: __ns_ldap_list OK mapline: nfsserver:/export/home7/tom do_mount1:(nfs,nfs) /home/tom -nobrowse nfsserver:/export/home7/tom penalty=0 nfsmount: standard mount on /home/tom : nfsserver:/export/home7/tom ping: nfsserver timeout=15 request vers=3 min=2 pingnfs OK: nfs version=3 nfsmount: Get mount version: request vers=3 min=3 nfsmount: mount version=3 mount nfsserver:/export/home7/tom /home/tom () mount nfsserver:/export/home7/tom dev=3a40003 rdev=0 OK MOUNT REPLY    : status=0, AUTOFS_DONE 

In this example, the search is made for an nisObject object. This means that is was performed on a Phase 1 client. The next example shows what the output on a Phase 2 client would look like.

 #  cd /home/tb250  t1      LOOKUP REQUEST: Fri Aug 23 08:49:24 2002 t1        name=tb250[] map=auto_home opts=nobrowse path=/home direct=0 t1        PUSH /etc/auto_home t1      getmapent_ldap called t1      getmapent_ldap: key=[ tb250 ] t1      ldap_match called t1      ldap_match: key =[ tb250 ] t1      ldap_match: ldapkey =[ tb250 ] t1        ldap_match: Requesting list for (&(objectClass= automount)(automountKey=tb250)) in auto_home t1        ldap_match: __ns_ldap_list OK t1        ldap_match: found: nfsserver:/export/home7/tb250 

Debugging SASL DIGEST-MD5 Problems

If SASL/DIGEST-MD5 authentication is used, a snoop trace will look something like this (bold text indicates the information to look for):

 LDAP:   ----- Lightweight Directory Access Protocol Header ----- LDAP:     *[LDAPMessage] LDAP:        [Message ID] LDAP:       Operation *[APPL 0: Bind Request] LDAP:           [Version] LDAP:           [Object Name] LDAP:          Authentication: SASL *[3] LDAP:              [OctetString] LDAP:  DIGEST-MD5  LDAP: LDAP:   ----- LDAP: ----- LDAP: LDAP:   "" LDAP: LDAP:   ----- Lightweight Directory Access Protocol Header ----- LDAP:     *[LDAPMessage] LDAP:        [Message ID] LDAP:       Operation *[APPL 1: Bind Response] LDAP:           [Result Code] LDAP:            SASL Bind In Progress LDAP:           [Matched DN] LDAP:           [Error Message] LDAP:          SASL Credentials  [7] LDAP:               realm="myserver.example.com",no LDAP:               nce="  PXZxIw/DacrytK"  ,qop="auth", LDAP:               algorithm=md5-sess,charset=utf-8 LDAP: 

If you are having SASL/DIGEST-MD5 problems, check the directory server access log for errors, make sure SASL/DIGEST-MD5 is enabled and that passwords are stored in clear text.

TLS/SSL Errors

TLS/SSL problems can be tricky to debug because the data transfer is encrypted. If you have problems connecting, check the system log ( syslog ) and the directory server access log for error messages.

Example:

 #  cat /var/adm/messages  ... Sep 5 10:23:29 eelab14 ldaplist[9626]: [ID 605618 user.error] libldap: CERT_VerifyCertName: cert server name 'myldap' does not match 'myserver.example.com': SSL connection denied . . . 

In this example, there is a mismatch between the fully qualified directory server name and the name contained in the server certificate header.

If the system log fails to provide sufficient information, check the directory server access log for clues. You can get additional information by turning on error log tracing as shown in FIGURE 4-4.

Figure 4-4. Error Log Properties

Password Problems

Problems can occur if the password is not stored in the expected format, or the password is not what you expect. To generate a hashed password, use the pwdhash command as shown.

 #  directoryserver pwdhash -D /var/mps/serverroot/slapd-vipivot \ -s crypt hello  {crypt}VfHh.ESyoKX0U #  directoryserver pwdhash -D /var/mps/serverroot/slapd-vipivot \ -s ssha hello  {SSHA}3Kvdi0z6hIfQUCWGBvhGyo4rCOdRENccR0OPXQ== 

To change a password and store it in UNIX crypt format:.

 dn: uid=tb250,ou=people,dc=example,dc=com changetype: modify replace: userpassword userpassword: {crypt}VfHh.ESyoKX0U 

To change a password and store it in Sated Secure Hash Algorithm (SSHA):

 dn: cn=proxyagent,ou=profile,dc=example,dc=com changetype: modify replace: userpassword userpassword: {SSHA}3Kvdi0z6hIfQUCWGBvhGyo4rCOdRENccR0OPXQ== 

To change a password and store it in clear text.

 dn: uid=test,ou=people,dc=example,dc=com changetype: modify replace: userpassword userpassword: {clear}hello