Side effect of recent change to more secure defaults like "lanman auth = No" intentionally?

[Andrew Bartlett]

On Fri, 2007-09-14 at 00:55 +0200, Guenter Kukkukk wrote:
> Hi all,   (Version 3.2.1pre1-SVN-build-25136)
> 
> in recent svn rev. 25049 more secure defaults for Samba 3.2 have
> been introduced:
>    client lanman auth = No
>    client plaintext auth = No
>    lanman auth = No
> 
> I ran into a problem when my daily svn build (and install) touched the
> new default setting "lanman auth = No" the _first_ time.
> 
> Was wondering, why OS/2 clients suddenly got an "access denied" error
> during sesssetup, but remembered the ml discussions about new planned more secure
> defaults. Testparm was showing the new defaults and a svn check confirmed abartlets
> changes.
> Did add the following to the [global] section of smb.conf
>    client lanman auth = Yes
>    lanman auth = Yes
> 
> Again - _any_ further access from OS/2 gave "access denied"!
> 
> During debugging, I realized that "lm_pw = pdb_get_lanman_passwd(sampass);" in
> auth_sam.c always returned a null ptr for the lanman password.
> The rest was easy...
> 
> When this version (and later ones) is installed - and no administrative
> changes are being done to smb.conf before a restart - _each_ OS/2 user's 
> LM password hash will be _deleted_ from the passdb backend on it's 
> very first next logon request! (here smbpasswd was used)
> Even with now ongoing administrative action, the already accessed
> LM password hashes are _gone_!
> 
> Is this the intended behaviour - or is it an unwanted / untested side effect?
> 
> If it's intended - which seems a bit ugly to me - the next realease notes should
> make this behaviour _very_ clear and how it can be avoided...
> 
> Sample smbpasswd entry (slightly modified) before first access:
> gk:1000:EC00EEA187473ED4C2265B23734E0DAC:3A7F56DC5DB01A34FC389A6FB2954BC0:[U          ]:LCT-46E8CFC4:
> and after:
> gk:1000:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:3A7F56DC5DB01A34FC389A6FB2954BC0:[U          ]:LCT-46E93487:

Why is the LCT (last change time) in the entry changing?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20070914/04b8ba8c/attachment.bin