[Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7
Stefano Cortese
stefano.cortese at ego-gw.it
Sat Dec 5 17:44:45 UTC 2015
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)?
- 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?
- 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
More information about the Freeipa-users
mailing list