Did you also set the Method in idmap.conf to include static?

On Jul 17, 2017, at 9:02 AM, Anton Semjonov via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> wrote:

I also tried setting up a static mapping in /etc/idmapd.conf on both the server and client: mapping the service principal to user 'git'. The effect was the client displaying the folder being owned by 'nobody' - whoops.

Hello again.

As a follow-up, I tried some further troubleshooting on two fresh virtual machines. The setup process was as follows:

[both] - install CentOS via kickstart - change hostname - ipa-client-install - ipa-client-automount - install @Network File System Client / @File and Storage Server - useradd --system --no-create-home git - add static mapping in /etc/idmapd.conf (see other reply) - add service principals in ipa: * git/test00.client.$domain@$REALM * nfs/zfs0.storage.$domain@$REALM

[server zfs0.storage.$domain] - kinit -k - ipa-getkeytab -p nfs/$HOSTNAME -k /etc/krb5.keytab - create a directory structure for exporting: • root @zfs0 ~ # ls -la /media/testenv/ total 0 drwxr-sr-x. 1 admin kerberos 18 Jul 19 20:56 . drwxr-xr-x. 1 root root 14 Jul 19 00:06 .. drwx--S---. 1 git kerberos 0 Jul 19 00:06 git drwxrwsrwx. 1 root kerberos 8 Jul 19 19:02 public - export with '/media *(rw,sec=krb5p,crossmnt,fsid=0,sync)' - add firewalld service nfs permanently - reboot

[client test00.client.$domain] - kinit -k - ipa-getkeytab -p git/$HOSTNAME -k /var/lib/gssproxy/clients/$(id -u git).keytab - fstab: zfs0.storage.$domain:/ /media nfs4 defaults,proto=tcp 0 0 - reboot

Then, logging in to the client and switching users with 'su - git' allowed me to navigate in /media, yet again I was denied access to the folder owned by git:

• git @test00 /media/testenv $ ls git ls: cannot open directory git: Permission denied

Gssproxy surely seems to use the client keytab, a cache is created:

• root @test00 / # klist -kt /var/lib/gssproxy/clients/995.keytab Keytab name: FILE:/var/lib/gssproxy/clients/995.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 1 18/07/17 23:32:43 git/test00.client.$domain@$REALM 1 18/07/17 23:32:43 git/test00.client.$domain@$REALM • root @test00 / # ll /var/lib/gssproxy/clients/ total 8 -rw-------. 1 root root 198 Jul 18 23:32 995.keytab -rw-------. 1 root root 1815 Jul 19 19:02 krb5cc_995

After adding some verbosity flags ("-vvv" in /etc/sysconfig/nfs and "Verbosity = 5" in /etc/idmapd.conf) I recorded logs while I was (re)mounting the nfs share and navigating through folders. The static idmap mapping seems to work:

59: nfsidmap[9406]: key: 0x1802b55 type: uid value: git/test00.client.$domain@$REALM timeout 600 60: nfsidmap[9406]: nfs4_name_to_uid: calling static->name_to_uid 61: nfsidmap[9406]: static_getpwnam: name 'git/test00.client.$domain@$REALM' mapped to 'git' 62: nfsidmap[9406]: nfs4_name_to_uid: static->name_to_uid returned 0 63: nfsidmap[9406]: nfs4_name_to_uid: final return value is 0

.. but as stated above I am still denied access. The logs are attached, because otherwise Thunderbird rips the formatting apart. I hope that this clarifies my situation a little and allows for some reproduceability.

Where could I further increase verbosity to see what principal/username is actually transmitted to the NFS server when I am denied access? Is there a NFS4 specific mailinglist where I could ask?

Greetings from Germany, Anton

On 17/07/17 15:02, Anton Semjonov via FreeIPA-users wrote:

Hello everyone!

I am trying to setup an NFS export with sec=krb5p on one machine and make it accessible to a system user ('git' in this case) on another. I'd like to put GitLab backups on my ZFS array via NFS, to be more specific.

All machines in my little homelab are based on CentOS 7.3.1611 and I use two replicated FreeIPA servers with what I believe to be the latest release available on CentOS: 4.4.0. Both the storage server and the GitLab server are enrolled hosts in my realm.

After enrolling both machines with ipa-client-install and installing @File\ and\ Storage\ Server on one and @Network\ File\ System\ Client on the other, I ran ipa-client-automount on both, as I read somewhere that it sets up neccessary configuration files for identity mapping?

I also found a thread on this mailinglist, about a usecase of Apache accessing a /var/www directory via kerberized NFS. I believe my usecase is very similar and I feel like I am very close to a solution. But I just don't understand where things go wrong:

In this particular case the 'git' user on both machines has different UIDs. It was created during the installation of GitLab on the client but the UID was already occupied by 'softhsm private keys owner' on the server. Thus I created a system user manually, which has a different UID though. For the sake of troubleshooting I also tried all the following steps with the Apache user, which has UID 48 on both machines - the result was the same.

As this is not an actual user in my realm, I first created a service principal of the form git/$HOSTNAME@REALM (or apache/... for that matter). I then used ipa-getkeytab to create a keytab in /var/lib/gssproxy/clients/$UID.keytab for gssproxy to find. That worked nicely as in: The user automagically got access to the mounted NFS share while a krb5cc_$UID was created in the directory mentioned above. After switching users with su, I can navigate through the mount - as long as all the folders have 755 permissions. A folder with 700 permissions and owner 'git' is correctly displayed as being owned by 'git' on the client

• yet I cannot access it! When I create a file or folder in a folder

with public permissions (777), the owner of the newly created file is 'nfsnobody'.

I also tried setting up a static mapping in /etc/idmapd.conf on both the server and client: mapping the service principal to user 'git'. The effect was the client displaying the folder being owned by 'nobody' - whoops.

Doing all the above steps with an actual user in the realm works fine. Either with the automagic method through gssproxy or by getting a ticket with kinit first: I can access a folder with 700 permissions and files are created with the correct owner, etc.

Is there any critical step that I missed? I feel like I am very close .. I'd be thankful for any hints.

Cheers, Anton _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org