Encrypted Passwords & Restricting Logon Attempts

Jim Morris Jim at Morris-World.com
Wed Nov 27 14:53:01 GMT 2002


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

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?


> 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?
  --
Jim Morris (Jim at Morris-World.com)




More information about the samba-technical mailing list