Depricate auth parameters in 3.6, remove in master?

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


On Tue, 2011-02-08 at 11:38 -0500, yaberger at ca.ibm.com wrote:
> Hi Andrew,
> 
> Regarding this post on samba-technical mailing list
> http://lists.samba.org/archive/samba-technical/2011-January/076053.html
> 
> 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
cracker).  

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                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.



More information about the samba-technical mailing list