Depricate auth parameters in 3.6, remove in master?

Andrew Bartlett abartlet at
Tue Feb 8 15:03:45 MST 2011

On Tue, 2011-02-08 at 11:38 -0500, yaberger at wrote:
> Hi Andrew,
> Regarding this post on samba-technical mailing list
> We are still using these two settings on different SMB services:
> security = share
> encrypt passwords = no
> For "security = share", it's a public SMB service that provides read-only 
> or write-only access.
> No id/password need to be provided but this would not be the case with 
> "security = user" from my understanding.
> Is it possible to provide the same kind of SMB service without security = 
> share?

You will need security=user, and then your users will need to provide a
username in this case.  This will then allow access from Windows Vista
and Samba 3.5 clients with the default settings. 

> As for "encrypt password = no", well... we have plans to get rid of it but 
> we currently rely on PAM authentication (which needs to be clear text) and 
> DCE behind PAM for authentication/authorization.
> We're still many months away from replacing DCE by a LDAP/KRB solution.

The reason we are proposing to deprecate these parameters is to give you
fair warning.  However, your situation (which I was aware of from
previous discussions) is rare, has serious issues with client support
(plaintext passwords are essentially untested in modern clients, and
there are known serious bugs), and in the medium term you will need to
find another solution.  

I don't think it's reasonable to continue to maintain this code
increasingly unsupported (by clients) code forever.  It has some pretty
nasty side-effects (particularly when security=share and encrypt
passwords = no are combined, it's essentially a server-side password

Perhaps an option would be to allow plaintext passwords in the protocol,
but to only permit them to be passed to a revamped auth_script, which
sites would then manage however they required?

Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 
Samba Developer, Cisco Inc.

More information about the samba-technical mailing list