RB wrote:
This isn't strictly a PAM issue, but rather with the default RHEL5.x
configuration (and Centos, and probably fedora). Does anyone know what they
were thinking?
Ostensibly, they were trying to authenticate system users without
passing said users' credentials on to winbind. Whether intentional or
not, it seems they assumed users would have a UID that could be
resolved by pam_unix. That's often the case, but with proper
enterprise-level user management (no local accounts) the assumption
breaks.
Should most pam auth modules know anything about uid's?
By all means - auth is probably the most important place for UIDs/GIDs
to be known.
What's supposed to happen with pam_smb_auth?
I thought that was account info. If the idea is to keep the 'system' accounts
(below 500 by convention)in the passwd file, is there a better way to do it?
Probably should have used something to this effect instead of 'requisite':
[success=ok new_authtok_reqd=ok ignore=ignore default=die user_unknown=ignore]
Which is, of course, according to pam.conf(5) the same as 'requisite'
with the added control of ignoring unknown users. Allows the stack to
shortcut if it's a system user with bad credentials but still passes
completely unresolved credentials on.
I have several Linux systems where I use pam_smb and local auth so
people in the windows domain don't need to manage a separate password.
Some of these have web services that don't require a local account and
the login and password should work for either local linux users or
windows domain users. Some have local accounts for people who actually
log in. Is there a better way to handle this? I'd like:
(A) to not require the Linux boxes to join the windows domain.
(B) to be able to add users that don't exist in the windows domain.
which I have now, but I'd also like:
(C) common uid/gid's across linux machines for both domain and
non-domain users and
(D) central password management for my non-domain users
(E) the ability for apps like subversion and apache to access the same
authentication, seeing both domain and non-domain logins.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
