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: '[email protected]' 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 <[email protected]> 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. > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
