[PATCH] Add a winbind localauth plugin for MIT Kerberos

[Alexander Bokovoy]

On to, 21 kesä 2018, Rowland Penny via samba-technical wrote:
> 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 ?
What is "this" in your question? winbindd cannot be used for
krb5_kuserok()/krb5_aname_to_localname() right now. This is what the
plugin to libkrb5 adds, making Kerberos applications capable to
automatically map Kerberos principals to user accounts without
additional configuration regardless of the domain size and complexity.

> 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.
No, we talk about POSIX users and Kerberos principals. These need to be
mapped to each other and winbindd is our backend for doing so.

-- 
/ Alexander Bokovoy