Troubleshooting

This section describes problems you may encounter and troubleshooting techniques.

Enabling and Disabling LDAP-UX Logging

When a program or service is behaving incorrectly, enabling logging is one way to examine the events that occur to determine where the problem is. Enable LDAP-UX Client Services logging on a particular client as follows:

Edit the local startup file /etc/opt/ldapux/ldapux_client.conf and uncomment the lines starting with #log_facility and #log_level by removing the initial # symbol. You can set log_level to LOG_INFO to log only unusual events. If LOG_INFO is not adequate to identify the problem, set log_level to LOG_DEBUG to log trace information. LOG_DEBUG provides more information, but significantly reduces performance and generates large log files on active systems.
Edit the file /etc/syslog.conf and add a new line at the bottom:
local0.debug <tab> /var/adm/syslog/local0.log
where <tab> is the Tab key on your keyboard.
Restart the syslogdaemon with the following command: (Refer to syslogd(1M) for details.)
kill -HUP 'cat /var/run/syslog.pid'
Once logging is enabled, run the HP-UX commands or applications that exhibit the problem.
Disable logging by commenting out the log_facility and log_level lines in the startup file /etc/opt/ldapux/ldapux_client.conf. Comment them out by inserting a # symbol in the first column.
Examine the log file at /var/adm/syslog/local0.log to see what actions were performed and if any are unexpected.




	TIP: Enable LDAP logging only long enough to collect the data you need because logging can significantly reduce performance and generate large log files. You may want to move the existing log file and start with an empty file: `mv /var/adm/syslog/local0.log /var/adm/syslog/local0.log.save` Restart the syslogdaemon with the following command: (Refer to syslogd(1M)or details.) kill -HUP 'cat /var/run/syslog.pid'.

Enabling and Disabling PAM Logging

When something is behaving incorrectly, enabling logging is one way to examine the events that occur to determine where the problem is. Complete the following steps to enable PAM logging on a particular client. Refer to pam(1), pam.conf(4), and Managing Systems and Workgroups for more information about PAM.

Add the debug option to each line in /etc/pam.conf that contains libpam_krb5.1. For example:

login account sufficient /usr/lib/security/libpam_krb5.1 debug
login account required /usr/lib/security/libpam_unix.1
su    account sufficient /usr/lib/security/libpam_krb5.1 debug
su    account required /usr/lib/security/libpam_unix.1
...

Edit the file /etc/syslog.confand add a new line at the bottom similar to the following:
*.debug <tab>/var/adm/syslog/debug.log
Restart the syslog daemon with the following command. (Refer to syslogd(1M) for details.)
kill -HUP 'cat /var/run/syslog.pid'
Once logging is enabled, run the HP-UX commands or applications that exhibit the problem.
Restore the file /etc/syslog.confto its previous state to stop logging.
Restart the syslogdaemon with the following command: (Refer to syslogd(1M) for details.)
kill -HUP 'cat /var/run/syslog.pid'
Remove the debug options from /etc/pam.conf.
Examine the log file at /var/adm/syslog/debug.log to see what actions were performed and if any are unexpected. Look for lines containing PAM.




	TIP: Enable PAM logging only long enough to collect the data you need because logging can significantly reduce performance and generate large log files. You may want to move the existing log file and start with an empty file: `mv /var/adm/syslog/debug.log /var/adm/syslog/debug.log.save`. Restore the file when finish. Restart the syslog daemon with the following command (Refer to syslogd(1M) for details.) kill -HUP 'cat /var/run/syslog.pid'

Viewing Active Directory Service Log Files

You can view Active Directory event log files using the Windows 2000 or 2003 Event Viewer. To start the viewer, click Start->Programs->Administrative Tools->EventViewer.

User Cannot Log on to Client System

If a user cannot log in to a client system, perform the following checks.

Use a command like pwget(1) with -n, or nsquery(1)^[2] to verify that NSS is working:
pwget -n username
nsquery passwd username
If the output shows LDAP is not being searched, check /etc/nsswitch.conf to make sure LDAP is specified. If username is not found, make sure that user is in the directory and, if using a proxy user, make sure the proxy user is properly configured.
If nsquery(1) displays the user's information, make sure/etc/pam.conf is configured correctly for Kerberos. If/etc/pam.conf is configured correctly, check the directory's policy management status. It could be the directory's policy management is preventing the bind because, for example the user's password has expired or the login retry limit has been exceeded. To check this try an ldapsearch command and bind as the user, for example:
cd /opt/ldapux/bin
./ldapsearch -h servername -b "CN=Users,DC=cup,DC=hp,DC=com"
msSFUName=username -D <directory Administrator DN> -w passwd
./ldapsearch -h servername -b "CN=Users,DC=cup,DC=hp,DC=com"
-D userDN" -w passwd msSFUName=username
where userDN is the DN of the user who cannot log in and username is the login of the user. If you cannot bind as the user, check if any directory policies are preventing access.
See below for an example of determining the user's bind DN.
Display the current configuration profile and check all the values to make sure they are as you expect:
cd /opt/ldapux/config
./display_profile_cache
In particular, check the values for the directory server host and port, the default search base DN, and the credential level. Also, if you have remapped any standard attributes to alternate attributes, or defined any custom search descriptors, make sure these are correct and exist in your database. If any of these are incorrect, correct them as described in “Modifying a Profile”.
If you are using a proxy user, make sure the configuration is correct as described in “Verifying the Proxy User”.

Make sure the client system can authenticate to the directory and find a user in the directory by searching for one of your user's information in the directory. Use theldapsearch command and information from the current profile.

Try searching for a user's information in the directory as the proxy user with a command similar to following:

cd /opt/ldapux/bin

./ldapsearch-h servername -b "baseDN" -D <proxy user DN> -w\ passwd msSFUName=username

using the name of your directory server (from display_profile_cache), search base DN (from display_profile_cache), proxy user (from ldap_proxy_config -p), proxy user password, and a user name from the directory.

For example:

cd /opt/ldapux/bin

./ldapsearch -h sys001.hp.com -b -D "CN=proxyuser,CN=users,DC=cup,DC=hp,DC=com" -w passwd\ msSFUName=biljonz

You should get output like the following:

dn: CN=John R Bill
Jones,CN=Users,DC=cup,DC=hp,DC=com 
accountExpires: 9223372036854775807 
badPasswordTime: 0 
badPwdCount: 0 
codePage: 0 
cn: John R Bill Jones 
countryCode: 0 
instanceType: 4 
lastLogoff: 0 
lastLogon: 0 
logonCount: 0 
distinguishedName: CN=John R Bill Jones,CN=Users,DC=cup,DC=hp,DC=com 
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=cup,DC=hp,DC=com 
objectClass: top 
objectClass: person 
objectClass: organizationalPerson 
objectClass: user 
objectGUID:: m0weqe/tykmLX1yw8Y/QZw== 
objectSid:: AQUAAAAAAAUVAAAAEZm5eELHdFIVJa9HtgYAAA== 
primaryGroupID: 513 
pwdLastSet: 0 
name: John R Bill Jones 
sAMAccountName: biljonz
sAMAccountType: 805306368 
userAccountControl: 546 
uSNChanged: 15284 
uSNCreated: 15283 
whenChanged: 20001222132148.0Z 
whenCreated: 20001222132148.0Z
gecos: John R Bill Jones,6394,DEV 
gidNumber: 1771 
loginShell: /bin/ksh 
msSFUHomeDirectory: /tblv006/home/biljonz 
msSFUName: biljonz 
syncNisDomain: cup 
uidNumber: 467

If you do not get this output, your proxy user may not be configured properly. Make sure you have access permissions set correctly for the proxy user. Refer to “Creating a New Proxy User” for details on configuring the proxy user.

You can also try binding to the directory as the directory administrator and reading the user's information.

Enable PAM logging as described under “Enabling and Disabling PAM Logging” then try logging in again. Check the PAM logs for any unexpected events.
Enable LDAP-UX logging as described in “Enabling and Disabling LDAP-UX Logging”, then try logging in again. Check the log file for any unexpected events.

^[2]nsquery(1) is a contributed tool included with the ONC/NFS product.

Troubleshooting

Technical documentation

» Table of Contents

» Glossary

» Index

Enabling and Disabling LDAP-UX Logging

Enabling and Disabling PAM Logging

Viewing Active Directory Service Log Files

User Cannot Log on to Client System