[Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7

[Jakub Hrozek]

On Sat, Dec 05, 2015 at 06:44:45PM +0100, Stefano Cortese wrote:
> Hello,
> we have a number of ipa 3.0 clients that have been upgraded from Scientific
> Linux 6.6 to 6.7 and after the upgrade both the .k5login authorization and
> auth_to_local_names mappings don't work anymore as before.
> The environment is linux only with no AD/Samba
> 
> Essentially we are using those mechanism to manage the spawning of processes
> via kerberized rsh or GSS ssh using service principals that are mapped to
> IPA accounts on the remote clients.
> Basically process A on hostA runs as userA with  service principal serviceA
> credentials from a local keytab and spawns a remote process on hostB via
> /usr/kerberos/bin/rsh -l userB hostB
> In userB homedir the .k5login file contains:
> the userB principal
> the serviceA principal
> 
> The running of the remote command is denied on host B with an error like:
> "Principal serviceA for local user userB failed krb5_kuserok"
> 
> The same problem occurs if instead of the .k5login file the mapping is done
> configuring the auth_to_local_names section in /etc/krb5.conf on hostB
> 
> Digging on the sssd/kerberos and IPA topics I have found that the behaviour
> is caused by the introduction of the localauth sssd kerberos plugin
> configured in /var/lib/sss/pubconf/krb5.include.d/localauth_plugin (see
> https://fedorahosted.org/sssd/wiki/DesignDocs/NSSWithKerberosPrincipal )
> 
> To be sure I downgraded the krb5-libs package on SL6.7 from version
> 1.10.3-42 ( the one where the localauth krb5 interface has been backported
> https://rhn.redhat.com/errata/RHBA-2015-1410.html )  to version  1.10.3-37
> and the mapping works correctly
> 
> Indeed in this mail
> https://www.mail-archive.com/sssd-devel@lists.fedorahosted.org/msg19174.html
> it is made clear that the plugin overloads the standard kuserok() and
> krb5_aname_to_localname() calls in view of a better integration with Active
> Directory or the mapping managed centrally
> 
> For the moment we don't need integration with Active Directory, so the
> solution was to comment the following line in /etc/krb5.conf:
> includedir /var/lib/sss/pubconf/krb5.include.d
> 
> So the questions are:
> - is there another cleaner way to exclude the localauth sssd plugin
> (considering that the configuration snippet is recreated at every sssd
> restart)?

Can you test if this hack would help:
    # service sssd stop
    # rm /var/lib/sss/pubconf/krb5.include.d/localauth_plugin
    # touch /var/lib/sss/pubconf/krb5.include.d/localauth_plugin
    # chattr +i /var/lib/sss/pubconf/krb5.include.d/localauth_plugin
    # service sssd start

btw also check out this ticket:
    https://fedorahosted.org/sssd/ticket/2788

> - is there the possibility on IPA 4.1 (the version of our server) to manage
> the mapping letting the plugin in place, namely to associate or authorize
> one or multiple service principals with an ipa posix account so that the
> getpwent() works?

I wonder why the mapping fails, can you invalidate the cache with
sss_cache and try to look up the principal from the command line, using
getent passwd primary at REALM ?

> - is there a more suitable way to obtain the above delegation and security
> context switching using other mechanisms supported by IPA?
> 
> Thanks in advance
> Stefano
> 
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project