Re: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7
On Sat, Dec 12, 2015 at 01:34:53PM +0100, Stefano Cortese wrote: > > > This is expected because if either the principal or the user name is > known to SSSD the localauth plugin will take control because by default > the added modules are registered first (see [plugins] section of man > krb5.conf for details). > > To check auth_to_local_names first you can try > >enable_only=names,k5login,sssd > > > > It does not work for me. > Changed the snippet and made immutable, after sssd restart the > behaviour is the same. > It does not work also putting k5login or names alone. > Note that the sssd version in SL6.7-RHEL6.7 is > 1.12.4-47 > Should those keywords work in this version ? ah, this is not related to the SSSD version, but to the version of MIT Kerberos. SL/CentOS/RHEL 6.7 should have version 1.10.3 which already has the new plugin interface but the localauth plugin was only released in MIT Kerberos version 1.12. 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
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
On Tue, Dec 08, 2015 at 02:33:40PM +0100, Stefano Cortese wrote: > 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 This is expected because if either the principal or the user name is known to SSSD the localauth plugin will take control because by default the added modules are registered first (see [plugins] section of man krb5.conf for details). To check auth_to_local_names first you can try enable_only=names,k5login,sssd HTH 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
On Tue, Dec 08, 2015 at 02:30:54PM +0100, Stefano Cortese wrote: >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: > [1]https://fedorahosted.org/sssd/ticket/2788 > > > not needing principal switching from/to root for the moment > > > Yes, sorry, wrong ticket: > [2]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) . Try now, there is nothing confidential in the bug, so I opened it. (I'm afraid there's nothing useful either, but the BZ might be useful in referencing for support..) >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 I can't promise anything because the scope of the changes is not totally clear, but can you please open a support case asking for the change in RHEL-6? Feel free to send me the case number, then. It might also be helpful to include why the workaround is not helpful/not feasible to you, because RHEL-6 already getting quite late in the cycle, so all changes should be justified.. -- 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
Re: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7
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
--
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
On Mon, 2015-12-07 at 18:04 +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 > > > > > > - 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 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. -- Simo Sorce * Red Hat, Inc * New York -- 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
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. -- 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
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@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 -- 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
