auth_to_local method for local user matching

[Ben H]

Greg,

I took a quick look at krb5_kuserok() man page and I understand, and agree
with your assessment in terms of what is being returned with the two
different auth rules.
Either we get DOMAIN\username or just username.

However, what I am unclear of is that in mode #1 (where we can login in
either format), the system will recognize getpwnam() calls for either name.
In other words, I can issue:
getent passwd username
or
getent passwd DOMAIN\\username

these are passed through nsswitch to the appropriate providers and both
will return the following entry:
username:x:550:5000:user:/home/username/:/bin/bash

So, since the system itself can apparently resolve either format in mode #1
to simply "username" - I guess my question is why can't krb5_kuserok?
Ideally, we could *always* pass it the full DOMAIN\username via the
auth_to_local rule since the getpwnam() can always resolve that.

So how exactly is krb5_kuserok determining luser ?

Also - I'm not sure your reference to k5login_directory?  Did you mean to
recommend it as an alternative to homedir stored .k5login files?
If so - thanks for the pointer.  While there are some situations that a
.k5login is necessary for, I feel that in general they are an unnecessary
risk and burden to utilize.
E.g. - a user can grant another user access to his account without any
administrative intervention (KerberosUseKuserok in ssh can prevent).
I am not against using it in every scenario, but would like to be able to
depend on the default behavior of no k5login required if upn matches.

thanks very much!


On Wed, Aug 21, 2013 at 10:31 AM, Greg Hudson <ghudson at mit.edu> wrote:

> On 08/20/2013 04:23 PM, Ben H wrote:
> > The question is  why must the auth_to_local rule be updated to return
> only
> > in the `user` format for this to work?  How and where is this local user
> > being determined?
>
> The application is calling krb5_kuserok() with a principal name and a
> local name.  It sounds like in mode #1, the application is passing just
> the username as the local name, while in mode #2, the application is
> passing DOMAIN\username.
>
> If that is true, I don't think you can get both modes to work using
> auth_to_local rules.  authname-to-localname mapping yields only one
> local name for a principal name.
>
> > Ideally I am trying to craft a rule that would work in all scenarios - I
> > see no reason why the rule from #2 would not support both configurations.
> > I am also trying to not rely on a .k5login file (which would make this
> > whole mapping unnecessary I believe)
>
> You might be interested in the k5login_directory option; search for that
> string in:
>
>
> http://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html
>
> In the upcoming release 1.12, we are adding a pluggable interface for
> kuserok:
>
>   http://web.mit.edu/kerberos/krb5-devel/doc/plugindev/localauth.html
>   http://web.mit.edu/kerberos/krb5-devel/doc/plugindev/general.html
>
> But that's in the future, and is more tailored for integrators than
> system administrators (as it requires writing C code and building a
> shared object).
>
>