[Samba] Trouble connecting to Samba 3.3.2 on Ubuntu from Win98

Günter Kukkukk linux at kukkukk.com
Mon Mar 15 22:42:14 MDT 2010


Am Dienstag 16 März 2010 02:20:18 schrieb Michael Lueck:
> Felix Miata wrote:
> > OS/2 takes that plus two more:
> >
> > client lanman auth = [Yes,True]
> > client plaintext auth = [Yes,True]
> 
> Interesting... I do use OS/2 on occasion, I have neither of those in my
>  smb.conf, and it worked while on the Debian Sarge / 2.0.26a configuration.
> 
> I have not tried since migrating, so perhaps I will get bit when I do, so
>  thanks in advance! ;-)
> 
> Sincerely,
> 

Some additions/clarifications,

client lanman auth = [Yes,True]
client plaintext auth = [Yes,True]

As the names already imply, both options are only used when samba _client_ 
applications - like smbclient - are used to access a remote smb server of any 
kind (mostly legacy servers).

client plaintext auth = [Yes,True] is _not_ necessary to  access OS/2 or win98/me, so 
should only be used with great care!

Note, that the cifs vfs kernel module, used to mount remote smb shares, does _not_ use
smb.conf at all.

------------------------------
The samba _server_ related option is
lanman auth =  [Yes,True]

Due to security reasons the internal default setting has been changed to "No"
(afair in 3.2.x).

When 
     lanman auth = No
is used, by default or explicitly set, the lanman hash is no longer generated inside
the passdb backend when a samba user is added/modified with smbpasswd or pdbedit !
So only a later smb.conf change to 
    lanman auth = Yes
does _not_ work! The lanman hash (also the nt hash) must be newly created with
smbpasswd or pdbedit.

When "lanman auth = Yes" is active and you use (as root) 'pdbedit -Lw test' and get something like:
test:1004:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:CDB6947B067797BF2A82807973B89556:[U          ]:LCT-4999D2A5:
you know that the leftmost lanman hash has not been generated at all! 
Btw - NEVER EVER post your lanman or NT hashes to the public, they are like plaintext passwords!

The current inner workings of samba is a bit more complex regarding this issue.
Just one sample:
Assuming one has created all the samba users with a pre-3.2.x samba version. So both 
the lanman and the NT hash are stored inside the passdb backend.
After upgrading to a more recent samba version - and assuming that "lanman auth = No"
is now active via new default - pdbedit -Lw will automatically hide the still stored
lanman hash like XXXXXXXXXXXXX....
(In case smbpasswd is used as the backend, one can still read its complete ASCII content).
A problem arises when a client user (from win98/me, OS/2, ...) is now requesting lanman auth
for login.
The samba server rejects the login with "access denied" and behind the scenes it _deletes_ (!)
the lanman hash for (only) this connecting user in the passdb backend!

Anyway - the stored state of the lanman hash for all users can be examined with root privs:
   pdbedit -Lw
(assuming " lanman auth = Yes" is set when doing so....)    :-)

Cheers, Günter


More information about the samba mailing list