W2K Domain Login Problem with 2.2.0

[Jeremy Allison]

On Mon, Apr 23, 2001 at 04:04:55PM +1000, Andrew Bartlett wrote:
> 
> The one's our bug-reporter supplied might be a start :-)
> 
> auth    required        pam_unix.so nullok
> account required        pam_unix.so
> 
> This looks perfectly reasonable, as a starting point.  Maybe add debug
> to the end of the lines.  You will need to add:
> 
> session required   pam_unix.so
> 
> if you want to access file-shares with the current cvs.

Ok - I've been playing with this a bit and I'm coming
to the conclusion we should compile Linux Samba with
pam turned *OFF* by default, and let those admins
who want it recompile with the --with-pam option for
a PDC.

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.

If however, we use the following pam.d/samba file

auth            required        /lib/security/pam_pwdb.so nullok shadow
account         required        /lib/security/pam_pwdb.so
session         required        /lib/security/pam_pwdb.so
password        required        /lib/security/pam_pwdb.so

we are able to get successful logons to a Samba PDC from
a win2k client either with or without shadow passwords.

It's also a *bastard* to debug - pam isn't exactly verbose
when it's screwing up.

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....

What concerns me is shipping an rpm on Linux that *works*, out
of the box for approx. 100% of our users. If adding pam by
default takes that figure down to 99% then it's *NOT* worth
the support hassles.

It has to be *bulletproof*. I'm not sure it is right now
due to the disparity in PAM modules/implementations on Linux
and Solaris boxes.

Thoughts anyone ?

		Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------