pam/winbind user not found problem

[Les Mikesell]

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 at gmail.com