W2K Domain Login Problem with 2.2.0

[Andrew Bartlett]

Steve Langasek wrote:
> 
> On Mon, 23 Apr 2001, Jeremy Allison wrote:
> 
> > The problem is we can't know if the system has got
> > shadow passwords enabled or not.
> 
> > I discovered that running with shadow passwords
> > and using the above pam.d/samba file fails completely,
> > with messages such as :
> 
> > PAM: Init user: jallison
> > Gethostbyaddr failed for 192.168.233.2
> > PAM: setting rhost to: 192.168.233.2
> > PAM: setting tty
> > PAM: Init passed for user: jallison
> > PAM: Account Management for User: jallison
> > PAM: UNKNOWN ERROR for User: jallison
> > PAM: Account Check Failed : Authentication service cannot retrieve
> > authentication info.
> > PAM: PAM_END OK.
> > PAM: Account Validation Failed - Rejecting User!
> 
> > in the smb log when the user tries to log onto the PDC.
> > If you run pwunconv to undo the shadow file (making the
> > system less secure) then the above pam config file
> > works.
> 
> OK, this I recognize.  Had to dig through the source to pam_unix to be sure.
> 
> A very serious problem for PAM modules, one you unfortunately won't find
> documented in any PAM howtos, is that the application and modules have no way
> to communicate information regarding filesystem credentials.  It is *very*
> difficult for a PAM module to change the process's uid/euid without losing
> information.  It can be done under Linux -- newer versions of the Linux-PAM
> pam_unix module do it -- but since there's PAM code out there that /doesn't/
> know how to handle uids, Samba should wrap all PAM calls with
> become_root()/unbecome_root().  As a general rule, all apps should assume
> maximum possible credentials prior to invoking PAM.

Finally, an explaination that MAKES SENSE.  Whats more, the reason it
worked for me is that I use NIS, so didn't need to be root.  

> 
> The other thing you won't find in the howtos is that, since PAM modules need
> to do their own logging and need to work with applications which use syslog
> and with those which don't (and Samba is both!), they may call openlog() with
> different options... so Samba should also call setup_logging() again after
> every PAM call.
> 
> > Now either we *always* control the pam.d/samba file that is
> > used on install, or we skip this whole ugly mess and ship
> > with PAM *off* by default, and let those admins who want
> > it turn it on....
> 
> Well, there will always be competing interests here; the Samba team wants to
> make sure the PAM config matches a known good, the administrator wants to be
> able to customize the config for his particular environment...
> 

Well if we ship with pam_stack we know that we are using a known good
config - and the admin changes it at their peril.  In fact the other PAM
config file (in RPMS) we ship will work on almost all situations anyway.

Andrew Bartlett
abartlet at pcug.org.au

-- 
Andrew Bartlett
abartlet at pcug.org.au