Enforcing password policies with LDAP and 'passwd: compat' set
- From: Brad Rosser <brad.rosser@xxxxxxxxx>
- Date: Thu, 11 Jun 2009 15:23:23 +1000
My organisation currently uses NIS for its Solaris name/directory services,
but we are looking at moving to using LDAP instead.
I'm currently testing Sun's LDAP server - Java Directory Server Enterprise
Edition 6.3.1' - with LDAP server and clients running Solaris 10 5/08.
One of the new functions we'd like to acquire with a move to LDAP for
name services is improved account/password management. Sun's Directory
Server implements a number of password policies - password expiration,
account deactivation, password lockout - which we never had with NIS,
and which our auditors would like to see. :-)
With /etc/nsswitch.conf set on a client to what I'll call 'pure' LDAP:
passwd: files ldap
... everything works swimmingly. The LDAP server's log shows that
login attempts are facilitated by attempted BINDs to the user's distinguished
name as that user. Accounts that are expired, deactivated or locked
each return an explicit error code and message, and ssh/telnet tell the
user that his account is 'expired'. A user can't login in any of these three
cases. Exactly what we want. Exactly what I gather everyone else
sees when they're using 'pure' LDAP and account management.
However, we want to preserve the old-style NIS compatibility for our
/etc/passwd file; we want to be able to use the old +/- syntax for
netgroup inclusion. So our test LDAP client has its /etc/nsswitch.conf
configured like this:
passwd: compat
passwd_compat: ldap
When we do this, however, we lose 'two-thirds' of our password policy
enforcement; well, two of our three tests fail:
- a login (via ssh or telnet) to an expired account will succeed (with no
warning messages about the expiration);
- a login to a deactivated account will succeed; but
- a login to a locked account will still fail (as desired).
The LDAP server still shows attempted BINDs to the accounts in all three
cases, and they still return the same errors ... but ssh/telnet now 'ignores'
the errors two of the three times!
It seems to be PAM's fault. We have these entries for account management
in /etc/pam.conf:
other account requisite pam_roles.so.1
other account binding pam_unix_account.so.1 server_policy debug
other account required pam_ldap.so.1 debug
... looking at the debug output it seems that pam_unix 'approves' a login
and so pam_ldap is never called. It seems to me that the 'passwd: compat'
setting in /etc/nsswitch.conf is so 'transparent' pam_unix itself seems to be
hoodwinked by it, and doesn't know to pass on accounts that are actually
stored in the LDAP database and not the local /etc/passwd file. That's just
my impression.
So, my question is ... has anyone got LDAP account management working
properly with clients which are configured for 'passwd: compat' operation?
This is driving me crazy ... I'm starting to think it's a big bug that
I won't be
able to get around. But LDAP has been in use for a decade (I'm seeing
early problems regarding PAM and such going back to 2004!) so it's hard to
accept that there's nothing to be done.
Assuming that it does end up being a bug ... can anyone suggest a
workaround, say on the LDAP server, which might help? I'm using a
serviceSearchDescriptor in some clients' LDAP profiles, for example,
to divert them to 'test project' containers for the 'projects' database. I
suppose I could set up a serviceSearchDescriptor to do the same thing
for the 'ou=people' container ... is there a way I could do this based on the
inquiring client host (I'm thinking of starting from something like automount's
ability to substitute the key of a map for the '&' character)?
Can anyone help?
Thanks,
Brad
_______________________________________________
sunmanagers mailing list
sunmanagers@xxxxxxxxxxxxxxx
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
- Prev by Date: Kiran Bhalgat sent you a Friend Request on Yaari
- Next by Date: Kerberos (MIT) users can login even when Password has expired.
- Previous by thread: Kiran Bhalgat sent you a Friend Request on Yaari
- Next by thread: Kerberos (MIT) users can login even when Password has expired.
- Index(es):
Relevant Pages
|
