View Single Post
  #10 (permalink)  
Old 06-01-2009, 12:56 AM
todd_dsm todd_dsm is offline
Loyal Member
 
Posts: 89
Default I found the cure

The UNIX and Windows Accounts in Zimbra LDAP and Zimbra Admin UI - Zimbra :: Wiki post suggests that your pam stack for the system be:
account sufficient pam_unix.so
account sufficient pam_ldap.so
auth sufficient pam_ldap.so
auth sufficient pam_unix.so
password sufficient pam_unix.so
password sufficient pam_ldap.so
session sufficient pam_unix.so
session sufficient pam_ldap.so
session required pam_mkhomedir.so skel=/etc/skel umask=0077
===
On a RHEL system the pam.conf man pages says of a 'sufficient' entry:
success of such a module is enough to satisfy the authentication requirements of the stack of modules (if a prior required module has failed the success of this one is ignored). A failure of this module is not deemed as fatal to satisfying the application that this type has succeeded.

The pam.conf man pages says of a 'required' entry:
failure of such a PAM will ultimately lead to the PAM-API returning failure but only after the remaining stacked modules (for this service and type) have been invoked.
===
As the first entry indicates you will check your /etc/passwd files first (pam_unix.so) then, on the second line, the ldap entries (pam_ldap.so).
===
The first line in the pam stack will most certainly fail if you have all of your users in ldap. Then, because of the sufficient designation, the remaining lines in the pam stack will be ignored.
===
FOR THE PRESENT: I have removed the unix lines from my pam stack (pam_unix.so) and changed all sufficient to required. Mine looks like this:
# cat /etc/pam.d/system-auth-ac
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
account required pam_ldap.so
auth required pam_ldap.so
password required pam_ldap.so
session required pam_ldap.so
session required pam_mkhomedir.so skel=/etc/skel umask=0077
===
This allows for all requirements so far:
1) my test users can login via the samba domain
2) their home directories are created automatically
3) the server can still find it's self when starting (after a reboot) and boot normally
===
Also, the sshd pam includes a lot of pointers to the system-auth-ac pam, so this has to be modified to NOT point to line entries in system-auth-ac. This is necessary as you will not be able to login again as root after all sessions are closed. This is my new sshd pam:
# cat /etc/pam.d/sshd
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_nologin.so
account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so force revoke
session include system-auth
session required pam_loginuid.so
session optional pam_echo.so file=/etc/pam.d/sshd_welcome
# NOTE: the final line is not necessary. I've simply added a welcome message during testing.
===
Now, more unforeseen requirements have been met:
1) you can still login as root!
===
That being said, I am not an expert with PAM. This will undergo further security review by someone with much more experience in this area than me. You should do the same. This will get you started though - no scripting necessary
Reply With Quote