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

[Sumit Bose]

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

Thank you for testing. The steps above disable the creation of the
localauth_plugin file by SSSD since the file already exists and is
immutable. SSSD tries to write:

[plugins]
 localauth = {
  module = sssd:/usr/lib/sssd/modules/sssd_krb5_localauth_plugin.so
  enable_only = sssd
 }

into this file to enable SSSD's localauth plugin. When I wrote the patch
for this I guess I over-optimistically added 'enable_only = sssd' which
disables all the default schemes available in libkrb5. I wonder if you
can create /var/lib/sss/pubconf/krb5.include.d/localauth_plugin with
this line missing:

[plugins]
 localauth = {
  module = sssd:/usr/lib/sssd/modules/sssd_krb5_localauth_plugin.so
 }

and try again? You might need to make it mutable again which 'chattr -i'
and after editing it call 'chattr +i' again so the SSSD cannot write
it's own version. If the version without 'enable_only = sssd' works for
you I think I will prepare a patch for SSSD which does not add this line
be default which then should fix your issue and other .k5login related
tickets we have in trac.

Thank you for for help.

bye,
Sumit
> 
> >
> >btw also check out this ticket:
> >    https://fedorahosted.org/sssd/ticket/2788
> not needing principal switching from/to root for the moment
> 
> >
> >> - 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.
> 
> 
> >> - 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