LDAP Weirdness (Solaris 9)

From: Daniel M. Zimmerman (dmz_at_cs.caltech.edu)
Date: 06/16/03 

Date: Sun, 15 Jun 2003 20:59:54 -0700

I'm having a very odd problem with LDAP authentication on a Solaris 9
box I'm running. The LDAP server is running OpenLDAP with a self-signed
certificate, and in order to get the Solaris machine's native LDAP
talking to it securely, I had to run the connection over an stunnel (so
the Solaris machine is actually talking to "localhost" as its LDAP
server, and the connection goes over the stunnel). It seems to work
fine for authentication under most circumstances; however, there are
two odd things going on that I just can't figure out, and maybe
somebody can offer an explanation:

1) Finger doesn't seem to work right. My user account (stored on the
LDAP server) is called "dmz"; while logged in, if I run "finger dmz", I
get the "Login name: dmz In real life: ???"
that you would expect for an account that doesn't exist. But if I run
"finger", it properly lists the names of all logged-in users (which
must be obtained from the LDAP server), and if I run "sudo finger dmz"
such that "finger" is running as root, it properly gives information
about me (my .plan, my shell, my idle time, etc.) It strikes me as
very, very odd.

2) The machine is a Sun Ray server (2.0 software), and it seems that
the Sun Rays don't get along with the LDAP server too well. I can log
into the machine with my account via ssh, on the console, and even on a
Sun Ray if I exit the Sun Ray Session login screen and just log
directly into a dtlogin. However, if I try to log into the Sun Ray
Session screen, it asks me for my password multiple times and then
complains of an "Internal PAM Error".

The machine is using the native Sun LDAP client. The contents of
/var/ldap/ldap_client_file are as follows:

#
# Do not edit this file manually; your changes will be lost.Please use
ldapclient (1M) instead.
#
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= localhost
NS_LDAP_SEARCH_BASEDN= ou=cs,o=caltech,c=us
NS_LDAP_AUTH= simple
NS_LDAP_SEARCH_SCOPE= sub
NS_LDAP_CACHETTL= 3600
NS_LDAP_CREDENTIAL_LEVEL= proxy

The /var/ldap/ldap_client_cred file contains valid credentials for an
account that can read, but not write, the crypted passwords on the LDAP
server. All such crypted passwords are actually "crypt"ed, not MD5
hashed or otherwise non-Solaris-standard.

The /etc/pam.conf file I'm using is as follows (with much of the Sun
commentary at the beginning removed):

# Authentication management
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authenctication
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth sufficient pam_unix_auth.so.1
other auth sufficient pam_ldap.so.1 use_first_pass debug
#
# passwd command (explicit because of a different authentication module)
#
passwd auth sufficient pam_passwd_auth.so.1
passwd auth sufficient pam_ldap.so.1 use_first_pass debug
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron account required pam_projects.so.1
cron account sufficient pam_unix_account.so.1
cron account sufficient pam_ldap.so.1 use_first_pass debug
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account
management
#
other account requisite pam_roles.so.1
other account required pam_projects.so.1
other account sufficient pam_unix_account.so.1
other account sufficient pam_ldap.so.1 use_first_pass debug
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session
management
#
other session required pam_unix_session.so.1
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password
management
#
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1
#
httpd auth sufficient pam_unix.so.1
#
#
# pam_sunray.so added to dtlogin-SunRay by SunRay Server Software
#
dtlogin-SunRay auth sufficient /opt/SUNWut/lib/pam_sunray.so
dtlogin-SunRay auth requisite pam_authtok_get.so.1
dtlogin-SunRay auth required pam_dhkeys.so.1
dtlogin-SunRay auth sufficient pam_unix_auth.so.1
dtlogin-SunRay auth sufficient pam_ldap.so.1 use_first_pass debug
#
# pam_sunray.so added to dtsession-SunRay by SunRay Server Software
#
dtsession-SunRay auth sufficient /opt/SUNWut/lib/pam_sunray.so
syncondisplay
dtsession-SunRay auth requisite pam_authtok_get.so.1
dtsession-SunRay auth required pam_dhkeys.so.1
dtsession-SunRay auth sufficient pam_unix_auth.so.1
dtsession-SunRay auth sufficient pam_ldap.so.1 use_first_pass debug

I really hope somebody can suggest something that I'm missing, or some
explanation for what's going on, because I just don't understand it.

Thanks in advance for any assistance... 

-- 
Daniel M. Zimmerman
Caltech Computer Science

Relevant Pages