Authenticaion and 'security =' changes
abartlet at pcug.org.au
Mon Nov 12 06:17:23 GMT 2001
David Collier-Brown wrote:
> Andrew Bartlett wrote:
> > So we probably will need to add some logic to testparm to avoid
> > foot-shooting, but I think it is a worthwhile addition.
> Er, could someone add my proposed self-check
> patch first?
> > The change will involve killing security = server and security = domain,
> > and creating an 'authentication order = ....'. The 'use rhosts'
> > parameter will also disappear.
> Sounds like a decent 3.0-era change.
> I would suggest:
> if (security = x && authentication order = y)
> if (x != y)
> fail horribly
> warn at a high log level (0? 1?)
This gets complex. auth order is a *list* of authenticaion methods,
each tried in turn. The test case here is security > USER and auth
order != NULL. In that case we have problem, but we can just treat
security = USER and go on with our lives.
> if (security = x && no authentication order)
> compose an authentication order
> warn at a moderate log level (1?)
This I can live with.
> > Possible authentication methods will include:
> > rhosts
> > hostsequiv
> both are somewhat insecure (;-))
Indeed, but they are also simple modules that provide a good example for
other implementors. That is mainly how they managed to stay around...
> > sam
this is smbpasswd btw.
> > unix
> > local -- a combination of SAM and Unix, depending on encryption.
> if this is like pam, you can say that direcly
If I create a 'pam' module then we will have 'pam' as an option and the
--with-pam configure check will go away. This option is here becouse I
want the defaults to be the same as under 2.2, that is unencrypted ->
Unix/PAM and encrypted -> sam.
> > server -- old security = server
> I'd use a more specific term, like
> win9x stupid compatability protocol (;-))
I'll probably call it 'smb server'
> > domain -- old security = domain
might end up as 'nt domain'
> > As such things *will break* after the introduction of this parameter. I
> > won't do compatibility measures at this time, but we may need to for the
> > 3.0 release.
> The technique is not hard, just not well-known.
> Solved problem in computer science from just
> before Unix was written, actually (;-)).
The problem isn't with the security= stuff. I think compatablity
measures will do fine here. The problem is the consequential changes
for a 'server role ='. This is harder to do in a backward compatible
manner. Fortuenetly it is also a simpiler paramater.
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
More information about the samba-technical