On Thu, May 22, 2014 at 09:42:15AM -0400, Simo Sorce wrote:
On Thu, 2014-05-22 at 15:18 +0200, Sumit Bose wrote:
> On Thu, May 22, 2014 at 08:49:34AM -0400, Simo Sorce wrote:
> > On Thu, 2014-05-22 at 10:11 +0200, Sumit Bose wrote:
> > > Hi,
> > >
> > > I would like to use getpwnam() to find the POSIX user for a given
> > > Kerberos principal. To achieve this I have to change the
> > > regular-expression we use to split the user name into name and domain
> > > components because we use '@' as a delimiter here and Kerberos
> > > principals contain an '@' as well.
> > >
> > > My idea is to allow an '@' in the name part so that
'a@b@c' is split
> > > into the name part 'a@b' and the domain part 'c'. A name
containing an
> > > '@' will then be considered as a Kerberos principal by SSSD and
used
> > > accordingly. If the domain is not known and the Kerberos principal
> > > should be searched in all known domains a single '@' at the end,
e.g.
> > > 'a@b@' shall indicate that the argument is a Kerberos principal.
> > >
> > > I would like to know if you agree with this approach, if you have
> > > concerns and other suggestions?
> > >
> > > As a side node. While looking at this I found some oddities in the
> > > current regular-expressions. E.g. currently '@' is not allowed in
the
> > > name part, but in the domain part when '@' is the separator. This
leads
> > > to a splitting of 'a@b@c' to name 'a' and domain
'b@c'. For AD-style
> > > names with '\' as a separator '@' is allowed in names,
i.e. 'a\b@c' will
> > > be result in name 'b@c' and domain 'a' (so in theory I
could use this
> > > scheme to send a Kerberos principal to SSSD, but for me this looks even
> > > stranger than my suggestion above, it hard to use on the command-line
> > > and does not solve the case where the domain is not known). I will try
> > > to fix those inconsistencies as well.
> >
> > I don't like this much.
> >
> > Instinctively I would say the current scheme should be just fine, if you
> > pass in name@REALM you get REALM as the domain name. If they match (bar
> > case), then you search for name as the username. If they do not match
> > and you end up finding no domain, then we can internally decide to
> > search all domain using name@REALM as the principal in a ldb_search().
> >
> > Where does this break ?
> >
> > Is it possible to have a user foo in domain
example.com that has a
> > principal of bar(a)EXAMPLE.COM ? And at the same time also have a user
> > 'bar' in the same domain ?
> > Is this the case you are trying to handle ? How likely is it ?
>
> no, I think this is quite unlikely. My concern was more related to
> performance. If we decide that name@REALM is a principal because we
> didn't find user 'name' in domain 'REALM' we have to iterate
over all
> configured domains and check if there is a user with the given
> principal. If the domain is known for the principal we cannot only skip
> the user lookup but can search the given domain directly. The krb5
> localauth will be able to give the right domain in all the cases where
> the user logs in with a fully qualified name or if fully qualified names
> are used as canonical names.
If we index the principal names, a perfect match search will be quite
fast, I do not think performance will be a big deal.
In general you will not know the domain from the kerberos side, so I am
not sure you'd be ever able to pass in the right domain name, I forgot
the details of the interface though, but if I look at gss_localname()
the only thing that gets passed in is a gss_name_t wihch is a pure
kerberos principal in this case. I do not see where you would be able to
pass in additional information (eg. sssd domain).
I was thinking of the kuserok case where you get local name and the
principal.
> > Btw, I was thinking whether we should handle cases where you pass in
> > things like root/admin@REALM this would require some special mapping
> > rules ... have you thought about these cases ?
>
> This will currently pass the regular expressions splitting the input.
> But yes, we have to decide how to handle them when searching for
> principals.
At least it is easy to skip a regular search as '/' is not a valid
character in a user name, so we can skip straight to the 'principal
mangling code'.
Btw, I was thinking we could use some trick to tell sssd we only want a
principal -> user resolution (vs a standard getpwnam), as there are at
least 2 characters we can abuse to deal with it. For example encasing
the principal name within ':' chracters as in :simo@FREEIPA.ORG: would
be quite clear (or maybe: ':princ:simo@FREEIPA.ORG').
I am just not sure we want to abuse the nsswitch interface that way.
Ok, I will continue with the scheme you proposed. If we run into issues
it would be possible to enhance it later without invalidating the
previous work.
Bonus question, are we going to try to store these entries in the fast
cache ?
yes, it's the response of a getpwnam() call. Is there a reason not to
store it?
bye,
Sumit
Simo.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel