On Thu, 2002-11-28 at 01:51, Jim Morris wrote: > Andrew, > > Thanks for your detailed response on this subject. > > >> As everyone on this list is probably aware, the use of encrypted > >> passwords and PAM password authentication are an apparently mutually > >> exclusive options with Samba 2.2.x. This is stated up front in the > >> help > >> for the 'obey pam restrictions' option in the man page I believe. > > > > Just to make this clear, this is not of our choosing, it is just a > > matter of how the protocol works. > > Oh - I knew that when I composed my message. That is also clear - PAM > does not support the challenge/response mechanism needed. It still > seems to me that it should somehow be possible, if coded right. Let's > say we have PAM setup on the system to actually authenticate against > the smbpasswd file, or an OpenLDAP server storing the passwords in > encrypted form. Is there no way to do the handshaking at the Samba > level, with just one call to PAM? Or do we need to read the 16-byte > hash or whatever is stored in the smbpasswd file, in order to check the > password? I can see PAM not letting us do that....
It is technically possible to make PAM do a large number of things, but really, you don't want to go there :-). Doing so would remove the purpose of using PAM - because you would no longer be able to use arbitrary modules - only modules coded with this samba-specific hack. :-) > Ok - on plain texts passwords, you state: > > > It would also prevent domain logons, and exposes bugs in other parts of > > Microsoft's client. > > The domain in this case is controlled by Samba. Most of the clients are > Windows 95/98 clients, and testing with Windows 98 seems to show that > it can do a 'domain logon'. For the record, I know that this is not > quite the same as the domain logon that Windows 2000 or NT clients will > do, and I have yet to test one of those clients. (I spent a LOT of > time working through the domain logon stuff a couple of years ago when > working on those chapters of 'Special Edition, Using Samba' with > Richard Sharpe). Anyway, I would only consider this switch to > plaintext passwords a temporary measure while I come up with something > better. > > > I think that the easiest way to do this would be to look into Samba > > 3.0's auth subsystem, and add a hook for WRONG_PASSORD return values. > > This could update the same database that pam_tally uses. > > Sounds like I need to pull a copy of HEAD from CVS and start getting > familiar with Samba 3.0. Of course, I am assuming that the HEAD > revision is Samba 3.0 work in progress? Samba 3.0 is now in alpha, and we have a separate CVS branch - SAMBA_3_0. There are also tarballs - but grab the CVS if you can. > > We certainly need to work on this, and a number of other 'enterprise > > grade' features. There are a number of things that, as developers, we > > don't notice, but user feedback (and in some cases, very good patches!) > > has allowed us to support. > > > > This feature in particular should be picked up when we finish > > implementing and better integrating account policy support. > > Well, I have been looking for a contribution to make to Samba for a > long time. My last direct contributions involved some OS/2 client > related debugging of Samba back in 1995, so its been a while! It > sounds like this may be an area I could work on. > > >> Alternatively, how difficult would it be to modify Samba to support an > >> option like this directly, within the constructs of the smbpasswd > >> file? > > > > Yes, your best option is to modify Samba, > > Ok - thanks for the advice. Should I consider Samba 3.0 (CVS) as the > best starting point for such a process? Yes. For a samba-centric patch, I would do this by hooking into the auth subystem in auth/auth.c. We would then have to decide where to store the counter - probably in the passdb subsystem as a simple counter. This has interesting complications on BDCs, but it probably the best place to start. We already have an account policy (lib/account_pol.c) to 'set' this behavior, so that should probably control the new feature. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
signature.asc
Description: This is a digitally signed message part
