<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Simo Sorce wrote: <blockquote cite="mid1449509265.17418.11.camel@redhat.com" type="cite"> <blockquote type="cite"> <pre wrap=""> 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. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">- is there a more suitable way to obtain the above delegation and </pre> </blockquote> <pre wrap="">security </pre> <blockquote type="cite"> <pre wrap="">context switching using other mechanisms supported by IPA? Thanks in advance Stefano </pre> </blockquote> </blockquote> </blockquote> <pre wrap=""> 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. </pre> </blockquote> 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 </body> </html>