pam_unix, pam_ldap, and nss

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list


[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux