Authenticaion and 'security =' changes

Andrew Bartlett 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
>                 else
>                         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
>                 ditto

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

-- 
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 mailing list