I'm working on a PAM setup that will ignore winbind/AD completely for users listed in /etc/passwd, and do the samba thing for all other users.
Mostly it seems to work, but there's one weird side-effect. For non-AD users (only), an AD group "BUILTIN+users" is being added as a secondary group. If I kill winbind, it still gets added, although only the gid is available (no name). I've googled around a while and get the impression that this behavior somehow supports 'winbind nested groups'. I don't see how or why this is happening given that I am (I believe) short-circuiting the pam config so that no pam_winbind nor pam_krb5 modules get stepped through for these local users. I can't understand how pam_winbind is (apparently) managing to mess with secondary groups in this case. My best theory at the moment, not knowing any of this very well, is that maybe pam_winbind is "cheating" on the PAM api, and somehow adding this secondary group in some init or close function (where it should not be). Any ideas? Mike account [default=2 success=ignore] pam_localuser.so account sufficient pam_unix2.so account requisite pam_deny.so account sufficient pam_krb5.so account requisite pam_deny.so auth required pam_env.so auth [default=2 success=ignore] pam_localuser.so auth sufficient pam_unix2.so auth requisite pam_deny.so auth sufficient pam_krb5.so auth required pam_winbind.so use_first_pass password [default=2 success=ignore] pam_localuser.so password sufficient pam_unix2.so nullok password requisite pam_deny.so password sufficient pam_winbind.so password sufficient pam_krb5.so password requisite pam_deny.so session optional pam_mkhomedir.so session required pam_limits.so session [default=2 success=ignore] pam_localuser.so session sufficient pam_unix2.so session requisite pam_deny.so session optional pam_krb5.so session required pam_winbind.so session optional pam_umask.so -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
