'host' attribute not working in nss_ldap/pam_ldap?

View: New views
1 Messages — Rating Filter:   Alert me  

'host' attribute not working in nss_ldap/pam_ldap?

by John Perkins-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I'm trying to set up LDAP-based account access at our site to replace
the text passwd files currently maintained on each individual
workstation.  The passwords themselves are all kept in a kerberos 5
server; I want to use LDAP to get any other relevant information from
the LDAP database.  I do have a working setup where the system can get
this information from an LDAP database, but the pam_check_host_attr does
not seem to take effect.

I have seen similar requests posted to this list in the past, but (from
what I could understand) they did not have the host attributes in their
LDAP database.

User password entries look like this:

==================================================
yorick(su): ldapsearch -x -b 'dc=cs,dc=wisc,dc=edu'
'(&(objectClass=posixAccount)(uid=frida))'
# extended LDIF
#
# LDAPv3
# base <dc=cs,dc=wisc,dc=edu> with scope subtree
# filter: (&(objectClass=posixAccount)(uid=frida))
# requesting: ALL
#

# frida, people, cs.wisc.edu
dn: uid=frida,ou=people,dc=cs,dc=wisc,dc=edu
uid: frida
objectClass: top
objectClass: posixAccount
objectClass: account
objectClass: shadowAccount
objectClass: krb5Principal
cn: Frida Lyngstad
ou: People
loginShell: /bin/bash
userPassword:: Kg==
uidNumber: 17294
gidNumber: 17294
homeDirectory: /u/f/r/frida
gecos: Frida Lyngstad
krb5PrincipalName: {KERBEROS}frida@...
host: abba.cs.wisc.edu
host: borel.stat.wisc.edu
host: charon.stat.wisc.edu
host: chef.cs.wisc.edu
host: cookie.cs.wisc.edu
host: curds.cs.wisc.edu
host: futz.cs.wisc.edu
host: germain.stat.wisc.edu
host: instnt
host: instunix
host: newton.cs.wisc.edu
host: otto-man.cs.wisc.edu
host: pongo.cs.wisc.edu
host: ramrod.cs.wisc.edu
host: rschunix
host: scroop.cs.wisc.edu
host: storchi.cs.wisc.edu
host: taylor.cs.wisc.edu
host: tylendel.cs.wisc.edu
host: violet.cs.wisc.edu
host: winstat01.stat.wisc.edu
host: winstat02.stat.wisc.edu
host: winstat03.stat.wisc.edu
host: winstat04.stat.wisc.edu
host: winstat05.stat.wisc.edu
host: winstat06.stat.wisc.edu

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
yorick(su):

==================================================

The computer yorick.cs.wisc.edu is my test case computer, and it will
allow user "frida" to login.  "pam_check_host_attr yes" is set in
/etc/ldap.conf.  Yet ssh will still allow this user to login.

The client computer is running RedHat linux 5.3 (64-bit); nss_ldap and
pam_ldap RPMs are installed.  /etc/pam.d/system-auth looks like this:

==================================================
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_krb5afs.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
try_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/$ISA/pam_unix.so nullok
use_authtok md5 shadow
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     required      /lib/security/$ISA/pam_krb5afs.so
==================================================

Any suggestions from the pam_ldap gurus as to what may be causing this
behavior or where to look for further debugging?

--
============================================================================
   John Perkins                   |   University of Wisconsin-Madison
   Researcher                     |   Department of Computer Science
   john@...               |   1210 W. Dayton St.
   608-262-0438/608-262-6626 FAX  |   Madison, WI  53706-1685
============================================================================