I am confronted with a relatively strange behaviour regarding ipa and automounting. We are using automounted home shares on some of our systems. On two almost identical systems I cannot chdir (permission denied) to user A's home directory on server 1 but chdir to user B's home directory works. On server 2 it is the exact opposite. On a third server chdir does not work for both users.

Ronald Wimmer via FreeIPA-users wrote: > On 14.09.20 16:06, Ronald Wimmer via FreeIPA-users wrote: >> I am confronted with a relatively strange behaviour regarding ipa and >> automounting. We are using automounted home shares on some of our >> systems. >> >> On two almost identical systems I cannot chdir (permission denied) to >> user A's home directory on server 1 but chdir to user B's home >> directory works. On server 2 it is the exact opposite. On a third >> server chdir does not work for both users. > > A manual "kinit userA" seems to solve the problem as the user had no > Kerberos credentials? But why? Why was a Kerberos ticket not fetched > automatically? How did the user login to the system?

On ti, 15 syys 2020, Ronald Wimmer via FreeIPA-users wrote: > On 15.09.20 15:48, Rob Crittenden via FreeIPA-users wrote: >> Ronald Wimmer via FreeIPA-users wrote: >>> On 14.09.20 16:06, Ronald Wimmer via FreeIPA-users wrote: >>>> I am confronted with a relatively strange behaviour regarding ipa and >>>> automounting. We are using automounted home shares on some of our >>>> systems. >>>> >>>> On two almost identical systems I cannot chdir (permission denied) to >>>> user A's home directory on server 1 but chdir to user B's home >>>> directory works. On server 2 it is the exact opposite. On a third >>>> server chdir does not work for both users. >>> >>> A manual "kinit userA" seems to solve the problem as the user had no >>> Kerberos credentials? But why? Why was a Kerberos ticket not fetched >>> automatically? >> >> How did the user login to the system? > > SSH. > > Sometimes I did a "su - myIpaUser" from a root shell. Is this supposed > to work or does it only work when the user has a valid ticket (from a > previous login)? The latter. > (Does it make a difference when I have no Kerberos ticket on the > originating system and I am forced to enter the users password upon > login? Both cases should result in obtaining a Kerberos ticket, > shouldn't they?) It depends. A lot, actually:  - If your SSH client allows forwarding a TGT and KDC allows it too,    then login with Kerberos ticket to SSH server might give you a    working TGT on the server side. SSSD on the server side is not    involved here as Kerberos authentication is handled completely by SSH    server.  - if you login with password over SSH and you have PAM authentication    enabled in SSH server configuration, SSSD might get you a new    Kerberos ticket in the user's ccache on the server side.

[...] >>    Kerberos ticket in the user's ccache on the server side. > > So. Let me try to summarize this for myself. When I want a kerberized > NFS share to be accessible the user must have a valid Kerberos ticket, > right? This can be either obtained through SSHD, could be delegated > from the originating system or it could be fetched on the target > system by SSSD. Is this correct? More or less, yes.

On 15.09.20 17:19, Alexander Bokovoy via FreeIPA-users wrote: >On ti, 15 syys 2020, Ronald Wimmer via FreeIPA-users wrote: >>On 15.09.20 16:39, Alexander Bokovoy via FreeIPA-users wrote: >>>On ti, 15 syys 2020, Ronald Wimmer via FreeIPA-users wrote: >>>>On 15.09.20 15:48, Rob Crittenden via FreeIPA-users wrote: >>>>>Ronald Wimmer via FreeIPA-users wrote: >>>>>>On 14.09.20 16:06, Ronald Wimmer via FreeIPA-users wrote: >>>>>>>I am confronted with a relatively strange behaviour >>>>>>>regarding ipa and >>>>>>>automounting. We are using automounted home shares on some of our >>>>>>>systems. >>>>>>> >>>>>>>On two almost identical systems I cannot chdir >>>>>>>(permission denied) to >>>>>>>user A's home directory on server 1 but chdir to user B's home >>>>>>>directory works. On server 2 it is the exact opposite. On a third >>>>>>>server chdir does not work for both users. >>>>>> >>>>>>A manual "kinit userA" seems to solve the problem as the user had no >>>>>>Kerberos credentials? But why? Why was a Kerberos ticket not fetched >>>>>>automatically? >>>>> >>>>>How did the user login to the system? >>>> >>>>SSH. >>>> >>>>Sometimes I did a "su - myIpaUser" from a root shell. Is this >>>>supposed to work or does it only work when the user has a >>>>valid ticket (from a previous login)? >>> >>>The latter. >>> >>>>(Does it make a difference when I have no Kerberos ticket on >>>>the originating system and I am forced to enter the users >>>>password upon login? Both cases should result in obtaining a >>>>Kerberos ticket, shouldn't they?) >>> >>>It depends. A lot, actually: >>> >>> - If your SSH client allows forwarding a TGT and KDC allows it too, >>>   then login with Kerberos ticket to SSH server might give you a >>>   working TGT on the server side. SSSD on the server side is not >>>   involved here as Kerberos authentication is handled >>>completely by SSH >>>   server. >>> >>> - if you login with password over SSH and you have PAM authentication >>>   enabled in SSH server configuration, SSSD might get you a new >>>   Kerberos ticket in the user's ccache on the server side. >> >>So. Let me try to summarize this for myself. When I want a >>kerberized NFS share to be accessible the user must have a valid >>Kerberos ticket, right? This can be either obtained through SSHD, >>could be delegated from the originating system or it could be >>fetched on the target system by SSSD. Is this correct? > >More or less, yes. What I was trying to accomplish is very similar to https://bugzilla.redhat.com/show_bug.cgi?id=1017651 where a user logs in to an IPA client with SSH keys (pubkey in IPA). Is it still like in that bug's thread that this won't work or would SSH trigger PAM and the latter SSSD in order to fetch a Kerberos ticket.

If it still does not work I will got the way outlined in the thread: > 1) Create a service principal 'prod' > 2) Get keytab for it using ipa-getkeytab (the result is the equivalent of > your SSH key) > 3) Place this keytab on the systems you log in and then manage production > from > 4) Add kinit with this keytab to you bash profile