[PATCH] Add a winbind localauth plugin for MIT Kerberos

Rowland Penny rpenny at samba.org
Thu Jun 21 10:13:21 UTC 2018


On Thu, 21 Jun 2018 12:40:03 +0300
Alexander Bokovoy <ab at samba.org> wrote:

> On to, 21 kesä 2018, Rowland Penny via samba-technical wrote:
> > On Thu, 21 Jun 2018 10:21:51 +0200
> > Andreas Schneider via samba-technical
> > <samba-technical at lists.samba.org> wrote:
> > 
> > > Hi,
> > > 
> > > attached is a patch which implements a localauth plugin for MIT
> > > Kerberos.
> > > 
> > > https://web.mit.edu/kerberos/krb5-latest/doc/plugindev/localauth.html
> > > 
> > 
> > That link is the usual developer written gobbledygook, it even tells
> > you to read the source for more info. I think what it is trying to
> > say is, it allows kerberos to know who local system accounts are.
> > 
> > If this is the case, why ? 'local system accounts' are just that,
> > local. 
> > 
> > > https://bugzilla.samba.org/show_bug.cgi?id=13480
> > 
> > Whilst I can understand that the case in the ticket must be correct,
> > what I cannot understand what kerberos has to do with local system
> > users, or am I missing something ?
> Yes, you are missing something. While Kerberos is an authentication
> mechanism and its principals in general have no relationship to
> identities of underlying operating system, Samba needs an identity to
> run smbd process and that identity is directly derived from the
> authenticated identity.
> 
> There are other applications which perform similar action. Both
> Kerberos and higher level GSS API have functions to transform an
> authenticated identity into a local identity to help the applications
> with this task.
> 
> Traditionally a particular way this can be configured is by using
> ~/.k5login or (in case of MIT Kerberos) auth_to_local rules in
> krb5.conf. These were checked by krb5_userok() and
> krb5_aname_to_localname() functions. If an application wanted to know
> that a particular principal can represent a user on the system, it
> called krb5_kuserok(). If it needed to know which local user name to
> use for a principal, it called krb5_aname_to_localname().
> 
> Implementations of theese both methods didn't scale in large
> organizations, so for those cases we introduced a pluggable localauth
> interface in MIT Kerberos in 2013. It allowed to delegate
> krb5_kuserok() and krb5_aname_to_localname() checks to external
> modules.
> 
> For SMB protocol we know that we can construct a user name based on
> the security token we received. We can also use Kerberos ticket's
> MS-PAC content for that. However, other applications don't have this
> information. For example, OpenSSH server wouldn't know you are
> Foo\Administrator if you present a Kerberos ticket
> Administrator at FOO.COM. It needs an explicit user name to be specified
> by the SSH client (ssh -l Foo\Administrator) and then it would ask
> krb5_kuserok() to validate that Kerberos principal
> Administrator at FOO.COM is allowed to be a user Foo\Administrator on
> the system.
> 
> This knowledge can be in ~/.k5login or as an auth_to_local rule in
> krb5.conf. However, maintaining such rules on each system is quite
> heavy in terms of up-to-dateness.
> 
> We made it first with SSSD for FreeIPA and direct AD usage. SSSD
> allows using any name associated with the user as its POSIX id when
> resolving it. You can say getpwnam_r("Foo\Administrator") or
> getpwnam_r("Administrator at FOO.COM"), they'll point to the same user
> entry. This allows to make a generic localauth plugin to MIT Kerberos
> that simply validates a Kerberos principal and a user name resolve to
> the same entry (same UID).
> 
> When winbindd is used to perform identity resolution, we can do the
> same. This is what Andreas' localauth plugin does, allowing us to have
> unified identity experience across multiple protocols and multiple
> client software stacks.
> 
> Hope this helps.

Well it does and then again, it doesn't ;-)

Why do we need something other than winbind, if winbind can already do
this ?

I am beginning to think when you say 'local system user', you don't
actually mean a local Unix system user, you mean a local Windows system
user.

Rowland



More information about the samba-technical mailing list