Re: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7
Jakub Hrozek wrote: 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 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. Hi Jakub, yes maybe it could help, even if I didn't find many details (bugzilla says I am not authorized to access the RedHat Bug 1240302 with my bugzilla account, I have tried also with our RedHat support licensed account) . It seems having been filed for sssd 1.14 and RHEL7 , is there any hope that it will be implemented also for 6.7 or 6.8 ? we can't upgrade to 7 for the IPA clients. Bye 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
Re: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7
Sumit Bose wrote:
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.
Hi Sumit
yes it works commenting out the line 'enable_only = sssd' and making
the file immutable , namely the .k5login file is read and enforced.
But respect to the solution emptying completely the snippet, it is lost
the possibility to perform the same enforcement via an
'auth_to_local_names' entry in /etc/krb5.conf for the given realm in
which the service principal is mapped onto the destination posix
account
Stefano
Thank you for for help.
bye,
Sumit
--
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
Re: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7
Sumit Bose wrote:
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.
Hi Sumit
yes it works commenting out the line 'enable_only = sssd' and making
the file immutable , namely the .k5login file is read and enforced.
But respect to the solution emptying completely the snippet, it is lost
the possibility to perform the same enforcement via an
'auth_to_local_names' entry in /etc/krb5.conf for the given realm in
which the service principal is mapped onto the destination posix
account
Stefano
Thank you for for help.
bye,
Sumit
--
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
Re: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7
Simo Sorce wrote: 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 FWIW a better way to solve this would be to use constrained delegation, allowing the service principal to obtain the target user credentials. This way you do not allow users to mess with .k5login files (which allows them to permit in an account whoever they please w/o central control. Simo. Hi Simo, yes, I will look into it when upgrading the IPA server to SL7.2 and IPA 4.2 (while for the clients as far as I understand for the constrained delegation to work they can stay on 6.7). Indeed for the moment we can use the auth_to_local_names mapping in /etc/krb5.conf to achieve the delegation and prevent the creation/modification of the .k5login file in some way. But of course the centralized solution is much better. Thank you very much 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
Re: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7
> 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 > - 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
[Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7
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 -- 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
