[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 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.
-- 
/ Alexander Bokovoy