[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pam-list
Subject:    pam_unix, pam_ldap, and nss
From:       ben thielsen <btb () bitrate ! net>
Date:       2010-06-08 3:58:26
Message-ID: F73DF610-3AFC-4400-9C9C-3EBF2E4CEF7C () bitrate ! net
[Download RAW message or body]

hi-

i've been experimenting with ldap authentication combined with traditional unix \
authentication, and have what appears to be a working configuration - but, in the \
process, it's raised some questions.  my testing has been only with sshd for the \
moment.  at the bottom of the message is my current sshd pam config.  i've included \
the various common-* includes in the file as though they were part of it.

i'm specifically wondering about the account section.  using the more basic \
configuration:

account	[success=1 new_authtok_reqd=done default=ignore]	pam_unix.so
account	[success=1 default=ignore]				pam_ldap.so minimum_uid=1000 debug
account	requisite						pam_deny.so
account	required						pam_permit.so

ldap users were allowed in when i wasn't expecting them to be.  i'm using openldap w/ \
the nssov overlay and the nss-pam-ldapd stub libraries.  isolating just the unix \
module or just the ldap module resulted in each type working as desired \
independently, but adding in the unix module circumvented the ldap group membership \
requirements.  since this system is also using ldap for nss - getent passwd, group, \
and shadow all expose ldap data, my sense was that this was the reason behind this \
behavior (although i don't quite understand specifically why).

my approach was to use localuser to identify if the user was local or in ldap, and \
then if found in ldap, apply the ldap module first, followed by the unix module only \
on success.  it seems to work, but feels a bit convoluted.  is this sane?  how is \
this typically handled, when nss uses both local files and ldap, and the pam uses \
both local and ldap modules with account restrictions coming from the ldap module?  i \
also wanted to keep the unix module first in the stack, to minimize delays if the \
ldap server was not reachable.

in the past i'd have used only localusers and not unix, which would simplify the \
account stack, but i've been cautioned previously on the list that doing so would \
result in things like password expiry not being honored, etc.

i'd greatly appreciate any criticism, etc. offered on my approach to solving the \
above, and on the below config in general.

regards
-ben

# sshd pam config
auth		required				pam_env.so
auth		required				pam_env.so envfile=/etc/default/locale

@include common-auth
### common-auth ###
auth		[success=2 default=ignore]		pam_unix.so nullok_secure
auth		[success=1 default=ignore]		pam_ldap.so use_first_pass minimum_uid=1000 debug
auth		requisite				pam_deny.so
auth		required				pam_permit.so
### end common-auth ###

account		required				pam_nologin.so

@include common-account
### common-account ###
# send directly to unix module if a local user, send to ldap module first if not
account		[success=1 default=ignore]		pam_localuser.so
account		[success=ok default=1]			pam_ldap.so minimum_uid=1000 debug
account		[success=1 new_authtok_reqd=done default=ignore]	pam_unix.so
account		requisite				pam_deny.so
account		required				pam_permit.so
### end common-account ###

@include common-session
### common-session ###
session		required				pam_unix.so
session		optional				pam_ldap.so minimum_uid=1000 no_warn debug
session		optional				pam_mkhomedir.so
### end common-session ###

session		optional				pam_motd.so # [1]
session		optional				pam_mail.so standard noenv
session		required				pam_limits.so

@include common-password
### common-password ###
password	requisite				pam_passwdqc.so min=disabled,24,11,7,7
password	[success=2 default=ignore]		pam_unix.so use_authtok try_first_pass sha512 \
obscure password	[success=1 default=ignore]		pam_ldap.so use_authtok try_first_pass \
minimum_uid=1000 debug password	requisite				pam_deny.so
password	required				pam_permit.so
### end common-password ###

_______________________________________________
Pam-list mailing list
Pam-list@redhat.com
https://www.redhat.com/mailman/listinfo/pam-list


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic