auth_to_local method for local user matching

[Ben H]

Greg,

I think this is making sense now, but I just want to confirm by example
that I understand your description.

Let's work off of this particular rule, which I was thinking *might* work
in all scenarios:

auth_to_local = RULE:[1:$0\$1](^DOMAIN\.COM\\.*)s/^DOMAIN\.COM/DOMAIN/

If l ssh into to a box using either `username` or `DOMAIN\\username' I will
still get the same UPN for my principal which will be:
'username at DOMAIN.COM'

The rule above will always convert that to DOMAIN.COM\username and then
finally substitute it to 'DOMAIN\username' (a.k.a our "match")

Are you stating that ssh (the application) is likely presenting whatever an
'id -un'/whoami provides and that whatever it is presenting must equal our
"match" ?

So even though in our "append domain" mode I can login with either form of
name (DOMAIN\username or username), if whoami returns 'username', then our
name is not a "match" in this case?

In other words - krb5_kuserok isn't just looking up (via getpwnam()?) to
confirm if it can find a user with that name, but the system has to return
the user in a format that is equivalent to the match?

Hopefully, I have understood correctly.  I'm thinking it *may* be possible
to write rules that basically state the following:

1) [1:$1] search for a domain name in the string and if none found, simply
output $1 as the whole sting
2) [1:$0\$1] search for a domain name in the string, and if found, output
as DOMAIN\$1

Whether or not the above *might* work is dependent on the rule processing
order.  Do all rules get processed, or once one matches does it exit?

thanks again





On Wed, Aug 21, 2013 at 1:12 PM, Greg Hudson <ghudson at mit.edu> wrote:

> On 08/21/2013 01:28 PM, Ben H wrote:
> > So how exactly is krb5_kuserok determining luser ?
>
> It's not.  krb5_kuserok receives the local username as input.  The
> application is deciding which value to pass.
>
> > 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).
>
> With k5login_directory, you can store .k5login files in a directory
> owned by root, thus preventing users from granting access to their own
> accounts.
>
> It may still be burdensome to have to create the .k5login files, but if
> they are the only option, k5login_directory may make it a little easier,
> depending on the details of your situation.
>
>