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).
> 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.
Bonus question, are we going to try to store these entries in the fast
cache ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York