[
https://issues.apache.org/jira/browse/KUDU-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16108271#comment-16108271
]
Todd Lipcon commented on KUDU-2087:
-----------------------------------
Based on some investigation, the problem is many-fold:
1) FreeIPA distinguishes between service principals and user principals and
doesn't store a 'uid' field in LDAP for service principals. Thus, when 'sssd'
tries to map a service principal to a local unix user, it determines that there
is no such user (ie getpwnam() fails). This is by design, best I can tell.
2) sssd's implementation of krb5_auth_to_localname uses getpwnam to try to map
the kerberos principal to the local username. Because of the above, it fails
for service principals.
3) Prior to el7.3, ssd configures krb5 with 'enable_only = sssd' in the
localauth plugin section. This means that if sssd fails to perform the mapping,
it does not fall back to other mappings defined in krb5.conf (eg explicitly
defined auth_to_local rules). See
https://bugzilla.redhat.com/show_bug.cgi?id=1297462
4) Even after 7.3, there is an additional bug in sssd which I just filed, which
causes the fallback to still not work. See
https://pagure.io/SSSD/sssd/issue/3459
Because of this, we're getting the KRB5_PLUGIN_NO_HANDLE error code back up at
the Kudu layer. We already have our own fallback case for KRB5_LNAME_NO_TRANS,
and it seems like we should just be handling PLUGIN_NO_HANDLE in the same way
to workaround the above behavior.
> Failure to map principal to local username in FreeIPA-configured environment
> ----------------------------------------------------------------------------
>
> Key: KUDU-2087
> URL: https://issues.apache.org/jira/browse/KUDU-2087
> Project: Kudu
> Issue Type: Bug
> Components: security
> Affects Versions: 1.3.1, 1.4.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
>
> FreeIPA is a tool provided by Red Hat which helps operators configure and
> manage an integrated LDAP + Kerberos environment (sort of a parallel of
> Active Directory from what I can tell). In this environment, the local MIT
> krb5 installation is configured to use the SSD 'localauth' plugin, which is
> responsible for mapping principals to usernames by implementing the
> krb5_auth_to_localname() API.
> In this environment, Kudu fails to start with Kerberos enabled because the
> krb5_auth_to_localname() API is returning KRB5_PLUGIN_NO_HANDLE when it tries
> to map its own principal to a username.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
