Depricate auth parameters in 3.6, remove in master?

[Andrew Bartlett]

On Fri, 2011-01-28 at 11:58 +0100, Björn Jacke wrote:
> Hi Andrew,
> 
> apart from the discussion whether or not there will be another 3.x release,
> some cleanups would be fine I think, no matter if they end up first time in a
> 3.7 or 4.0 release.
> 
> On 2011-01-28 at 12:09 +1000 Andrew Bartlett sent off:
> > security=share (per the discussion)
> 
> +1
> 
> > username (only part of security=share username guessing)
> 
> +1
> 
> > security=server
> 
> +1
> 
> > encrypt passwords = no
> 
> not sure how many people actually still use this. I think I'd like to keep
> this.

The point with the plaintext password code is that it performs a
server-side brute force attack (see password level) on the plaintext
password (due to case sensitivity), and just does not work properly with
Windows clients (almost any) due to lack of caching (causing really
weird reconnect failure) and the need to set registry hacks.  So it is
both a security risk and a 

There certainly are users of this, but we need to move them to other
more secure solutions to their needs, and that starts by marking it as
deprecated. 

> > password level
> 
> +1 !!!
> 
> > update encrypted
> 
> like "encrypt passwords"...
> 
> > use spnego = no
> 
> +1 - I'm not aware of real use cases.
> 
> > server schannel = no
> 
> seems Windows NT4 before SP4 didn't support netlogon schannel, so at lease
> "server schannel = auto" functionality should be kept.

Do our users actually have any NT4 clients running less than SP4?  The
netlogon authentication scheme actually has some quite nasty flaws when
not very secured with schannel, because the data in the session isn't
bound to the authentication.  One could even plausibly extract session
keys with the right attack. 

Thinking further on this, and due to this security issue, I would
actually like to see the default changed to 'yes', and the parameter
deprecated as a whole. 

> > auth methods
> 
> not sure ...
> 
> > enable privileges = no
> 
> +1
> 
> > domain master = yes (when domain logons = no, ie not a DC)
> 
> making them conflict would be good I think.
> 
> 
> > null passwords = yes (the meaning of the ACB_NOPWREQ isn't what we
> > thought it was)
> 
> +1
> 
> Cheers
> Björn

Thanks for your review,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.