 |
» |
|
|
|
This section describes troubleshooting techniques as well
as problems you may encounter. Enabling
and Disabling LDAP-UX Logging | |
When something 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. This is a good place to start. If LOG_INFO is not adequate
to identify the problem, set log_level to LOG_DEBUG to log trace
information. LOG_DEBUG will provide more information but will significantly
reduce performance and generate 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 syslog daemon with the following command.
(See 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. Look
for functions with "__ldap." These correspond
to standard LDAP function calls.
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. Enable PAM logging on a particular client as follows.
See pam(1), pam.conf(4), and Managing
Systems and Workgroups for more information on 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.conf
and add a new line at the bottom like the following: *.debug <tab> /var/adm/syslog/debug.log |
Restart the
syslog daemon with the following command. (See 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.conf
to its previous state to stop logging. Restart the
syslog daemon with the following command. (See 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."
Active
Directory Server Log Files | |
Active Directory event log files can be viewed using the Windows 2000 Event
Viewer. To start the Viewer, choose 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
under “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 the ldapsearch command and information from the current profile.
Try searching for one of your user's information in the
directory as the proxy user with a command like the 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 don't, your proxy user may not be configured
properly. Make sure you have access permissions set correctly for
the proxy user. See the step "Create a proxy user" on
page 23 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 under “Enabling
and Disabling LDAP-UX Logging”,
then try logging in again. Check the log file for any unexpected
events.
|
Printable version
