W2K Domain Login Problem with 2.2.0

[Andrew Bartlett]

Jeremy Allison wrote:
> 
> 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.

That's it as it stands anyway, but admins LIKE pam, because all
applications use the same criteria deciding on a users validity -
without PAM, my uni's IT department couldn't allow logins into its SSH
server - because ssh.com doesn't support PAM.  OpenSSH however supported
pam and allows users to authenticate against LDAP.  PAM is worth the
effort - it really is.

> 
> The problem is we can't know if the system has got
> shadow passwords enabled or not.

Its pretty safe to assume that they do, in any case we ship a pretty
good default as it is.

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

OK, so we have found our problem.  Its misconfigred systems - users who
are not using our supplied PAM config.

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

We already ship without pam enabled, and 'those admins' are turning it
on.  Samba's PAM support is getting better, and there is now a patch
available to get better unix password sync USING PAM.  We also have pam
sessions, making samba behave much more like every other application
running on a PAM enabled system.  

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

We have not had any reports from users of the Linux RPMS.  The only
Linux report I have is a debian user who has what looks like a custom
pam config file (we don't package debian, last I looked).  

Well you will get the support hassles any way, every distributor ships
--with-pam, and RedHat already has bug reports about the old behavior. 
The issue with the shadow file and PAM configuration in general is
addressed by shipping a pam.d/samba file in the RPMS, which we do, and
using modules like pam_stack to ensure that we only break when the rest
of the distro does.

> 
> 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.
 
Turning PAM OFF is a admin nightmare, as that will also turn off
plain-text passwords on those systems (but we don't care about that
anymore...), and reopen a whole whereby DISABLED accounts are allowed
in, where there is no way for an admin to setup an easy /etc/nologin
file (this can be configured via PAM), and where the restrictions that
apply to the rest of a unix system are blindly ignored by Samba.  

Do note, there is another thread going on at the moment - and somebody
mentioned that Samba's lake of proper PAM support as a reason people
aren't using Samba.

Yes, we need to do it properly, but not supporting PAM in NOT an option.

And PAM is on the those things that will make winbind really work,
because every application will check with winbind for authentication. 
Wouldn't you feel cheated if you supplied a perfect winbind
implementation only to find that $big-software-package didn't support
PAM, therefore broke your single-sign-on model?

Andrew Bartlett

-- 
Andrew Bartlett
abartlet at pcug.org.au