On Thu, May 22, 2014 at 11:07:18AM +0200, Jakub Hrozek wrote:
On Thu, May 22, 2014 at 10:11:54AM +0200, Sumit Bose wrote:
> I would like to use getpwnam() to find the POSIX user for a given
> Kerberos principal.
In general I'm fine with what you propose, but I wonder why is it easier
to use getpwnam() and not a special library call, like we have for sid-to-name
lookups? Did you want to avoid having to link the localauth plugin with
a third party library (like sss_nss_idmap) ?
getpwnam() already provides the needed functionality, i.e. indicates if
there is a corresponding user or not and returns the canonical name.
Adding another call would just duplicate functionality.
> 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
> into the name part 'a@b' and the domain part 'c'.
Yes, I think we were asked to allow e-mail addresses as username in the
yes, although there is a difference because users won't like to type
and additional domain name or an '@' sign at the login prompt. If the
email-domain is the same as the DNS-domain used by SSSD it will already
work. If it is different from the DNS-domain I think we have to add a
new internal variable for the mail-domain. Additionally a mail-domain
might related to multiple DNS-domain, e.g. in the case of an AD forest.
> 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
> names with '\' as a separator '@' is allowed in names, i.e.
> be result in name 'b@c' and domain 'a' (so in theory I could use
> 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.
Currently we only support domain names that contain alphanumeric ASCII
characters, dashes and underscores anyway, at least those defined in the
sssd.conf. I'm not sure if the same limitation is also imposed on
But still, what about only allowing the '@' in the name part? I don't
think we would break backwards compatibility, I doubt anyone is using a
subdomain with '@' in the name.
yes, my point was that we should not allow them in the domain part (at
least not as long as there is no use case :-)
sssd-devel mailing list