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

[Jakub Hrozek]

On Mon, Dec 07, 2015 at 06:04:30PM +0100, Stefano Cortese wrote:
> >> 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
> 
> It works, thanks
> 
> >
> >btw also check out this ticket:
> >    https://fedorahosted.org/sssd/ticket/2788
> not needing principal switching from/to root for the moment

Yes, sorry, wrong ticket:
    https://fedorahosted.org/sssd/ticket/2707

> 
> >
> >> - 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 REALM ?
> >
> Maybe I wasn't clear in describing the setup.
> 
> I am attempting to log from a local machine as "userA"  using the
> credentials of a "service principal" defined in IPA to a remote machine as
> "userB"
> The userB principal is resolvable on the remote host via "getent passwd
> userB" because it is a user principal.
> Also the userA principal is resolvable on the local machine, but this should
> not play a role because the user's credentials are not used for the
> connection, only the service credentials, as a client.
> The service principal is not resolvable via "getent passwd" neither on the
> originating host nor on the destination host.
> The trick with .k5login is that the service principal used in the connection
> is granted access as userB because it is listed as one of the principals
> that correspond to the userB posix account on the remote host.

Thank you, then I think #2707 would help you because you could configure
that .k5login is still used.