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 [email protected] ? 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 :[email protected]: would be quite clear (or maybe: ':princ:[email protected]'). 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 _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
