W2K Domain Login Problem with 2.2.0

[Andrew Bartlett]

Gerald Carter wrote:
> 
> Andrew Bartlett wrote:
> >
> > 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.
> 
> Some admins like PAM.  Some just like it some of the time.
> :-)
> 
> >
> > OK, so we have found our problem.  Its misconfigred
> > systems - users who are not using our supplied PAM config.
> 
> I'm no RPM expert, but isn't this our fault?
> 
> %attr(-,root,root) %config(noreplace) /etc/pam.d/samba

Nope, becouse the install script stomped all over /etc/pam.d/samba
anyway.  That makes the spec file broken, but not broken in this
respect.

> 
> > We already ship without pam enabled, and 'those admins'
> > are turning it on.
> 
> Andrew, this sounds like a subjective statement.  My
> experience has been the opposite actually.  Do we
> have numbers one way or the other?  Just curious.

Most admins proxied by most linux distributions - who will probalby
enable pam whatever happens.  (Look at what RedHat did with --with--ssl)

> 
> > We have not had any reports from users of the Linux
> > RPMS.
> 
> Not true.  The Win2k domain logons were broken in
> our RPMs.
> 
> > Turning PAM OFF is a admin nightmare, as that will
> > also turn off plain-text passwords on those systems
> 
> Guys, we are talking about Linux here.  Not all the servers
> in the world.  Maybe Solaris, but we have all sorts of
> other servers out there as well.
> 

--snip--

> > Yes, we need to do it properly, but not supporting PAM
> > in NOT an option.
> 
> We have conflicting design goals at the moment.  The PAM
> support was thrown in at the last minute and caused
> some things to break.  It was not properly documented
> and has come back to bite us.
> 
> There, I said it.  I was a bad call on our part to do this
> as a last minute change.  Period.
> 
> Now that I have that off my chest, I will say that
> surprisingly enough, I agree with Andrew.  Samba should
> be able to integrate with PAM.  However, and this is a big
> thing, we need to pay attention to all the corners cases as
> well.
> 
> Jeremy is right.  We have to many people depending
> on us to not get this right.  It has to be 100%.
> 
> Here some possible scenarios...
> 
>  o Standalone samba server - PAM works fine
> 
>  o Samba as a member server - domain security.  We need
>    to work this one out.  Remote users, local users, etc...

Winbind is the pam module in this case, and winbind is currently the
same as pam_permit :-)

> 
>  o Samba as a PDC - All local users
> 
> How does a full blown SAM-like account storage system
> fit in here?  A simple thing like disabling an account
> in User Manager for Domains...which should take precedence?
> Samba's passdb or PAM?  Can we assume we know which one the
> UNIX admin wants?  What if it is an NT shop with a Samba
> appliance?

We should AND the requirements, ie check with both.  If its an NT shop
we just make PAM pam_permit and let it go.

> 
> btw....passwd chat cannot go away completely because
> not all systems can use PAM.   Although on those that do,
> PAM should be used I agree completely.

Good, a patch will be delivered shortly.  (There is one on samba-patches
already, actualy - but I'll upload a later version).

> 
> There are many more questions that one would initially
> assume for this problem to be adressed in one weekend.
> Perhaps we should just setup a conf call and hash it out.
> Then post an RFC on samba-technical.
> 
> Non of us are working in isolation and yet the PAM
> support was kind of thrown in there without really
> talking it out with everyone (at least I was out of
> the loop).
> 
> So i'll probably get flamed for some of this, but hey :)
> It's Monday morning here and I have plenty of coffee
> (not that coffee really relates to this story, but it
> is always "a good thing" TM) :-)
> 

-- 
Andrew Bartlett
abartlet at pcug.org.au