On 23-02-17 15:39, Brendan Kearney wrote:
> On 02/23/2017 09:11 AM, Kees Bakker wrote:
>> On 23-02-17 13:51, Brendan Kearney wrote:
>>> On 02/23/2017 07:32 AM, Kees Bakker wrote:
>>>> On 22-02-17 17:33, Brendan Kearney wrote:
>>>>> On 02/22/2017 10:26 AM, Kees Bakker wrote:
>>>>>> On 22-02-17 14:05, Brendan Kearney wrote:
>>>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote:
>>>>>>>> On 21-02-17 19:49, Brendan Kearney wrote:
>>>>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote:
>>>>>>>>>> Hey,
>>>>>>>>>>
>>>>>>>>>> Maybe one of the NFS users on this list could give me a hint what
>>>>>>>>>> could be wrong. I'm not sure if it has any relation with 
>>>>>>>>>> FreeIPA/Kerberos.
>>>>>>>>>>
>>>>>>>>>> I've set up an NFS server and I can mount the NFS directory on my 
>>>>>>>>>> client. So, I'm
>>>>>>>>>> guessing that setting up Kerberos principal was done correctly.
>>>>>>>>>>
>>>>>>>>>> However, only root can actually access the mounted contents. Any 
>>>>>>>>>> other user
>>>>>>>>>> only sees question marks as shown below.
>>>>>>>>>>
>>>>>>>>>> The mount command is simple.
>>>>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome
>>>>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
>>>>>>>>>> mount.nfs: trying text-based options 
>>>>>>>>>> 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'
>>>>>>>>>>
>>>>>>>>>> On the server side /etc/exports looks like this.
>>>>>>>>>> /home        *(rw,sync,sec=krb5i,no_subtree_check)
>>>>>>>>>>
>>>>>>>>>> $ sudo mount |grep nfs
>>>>>>>>>> srv1.example.com:/home on /nfshome type nfs4 
>>>>>>>>>> (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)
>>>>>>>>>>
>>>>>>>>>> $ sudo ls -ld /nfshome
>>>>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
>>>>>>>>>> $ sudo ls -l /nfshome
>>>>>>>>>> total 0
>>>>>>>>>> drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb
>>>>>>>>>>
>>>>>>>>>> $ ls -l /nfshome
>>>>>>>>>> ls: cannot access '/nfshome': Permission denied
>>>>>>>>>> $ ls -l / | grep nfshome
>>>>>>>>>> ls: cannot access '/nfshome': Permission denied
>>>>>>>>>> d?????????   ? ?    ?       ?            ? nfshome
>>>>>>>>>>
>>>>>>>>> sec=krb* means that the user accessing the mount has to authenticate 
>>>>>>>>> with a kerberos ticket, and has to be the user or in the group 
>>>>>>>>> granted access to the share.  from the looks of things, the user did 
>>>>>>>>> not authenticate, and that is why the permissions are question marks. 
>>>>>>>>>  check the kerberos tickets that the user has (klist output).  
>>>>>>>>> Otherwise, the ownership might be user and group that the client 
>>>>>>>>> machine does not recognize (think posix user/group that is not in 
>>>>>>>>> sync between the NFS server and the client)
>>>>>>>> Thanks for the reply.
>>>>>>>>
>>>>>>>> In this case the user _is_ authenticated.
>>>>>>>> keesb@client1:~$ klist
>>>>>>>> Ticket cache: KEYRING:persistent:60001:60001
>>>>>>>> Default principal: ke...@example.com
>>>>>>>>
>>>>>>>> Valid starting     Expires            Service principal
>>>>>>>> 22-02-17 09:20:30  23-02-17 09:20:25  krbtgt/example....@example.com
>>>>>>> no, the user has a TGT.  a nfs/host.domain.tld@REALM ticket is needed 
>>>>>>> to authenticate.
>>>>>> (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. ))
>>>>>>
>>>>>>>> What other grants could be needed? HBAC Rules?
>>>>>>>>
>>>>>>>> Do I need an nfs principal for the client? (I didn't think so, but 
>>>>>>>> many HOWTO's say so [2]. Anyway, it
>>>>>>>> doesn't help to get access for the user.)
>>>>>>> there are principals to create and keytabs to be updated on hte NFS 
>>>>>>> sever, if not done already.
>>>>>> I did create a principal for the NFS server (using ipa service-add) and
>>>>>> add to the keytab on the NFS server (using ipa-getkeytab) ...
>>>>>> root@srv1# klist -ke
>>>>>> Keytab name: FILE:/etc/krb5.keytab
>>>>>> KVNO Principal
>>>>>> ---- 
>>>>>> --------------------------------------------------------------------------
>>>>>>       1 host/srv1.example....@example.com (aes256-cts-hmac-sha1-96)
>>>>>>       1 host/srv1.example....@example.com (aes128-cts-hmac-sha1-96)
>>>>>>       1 nfs/srv1.example....@example.com (aes256-cts-hmac-sha1-96)
>>>>>>       1 nfs/srv1.example....@example.com (aes128-cts-hmac-sha1-96)
>>>>>>
>>>>>> Is this what you mean?
>>>>> yes, if that is done, the server side components should be done for 
>>>>> kerberos.  have you set things up in /etc/idmapd.conf so your domain, 
>>>>> REALM, etc are setup?
>>>> I don't think that a change of idmapd.conf (on the NFS server) is needed 
>>>> because all host
>>>> names are FQDN and everything is in one and the same REALM.
>>> NFS needs to know how to map a user object to an ID and groups. identities 
>>> established by kerberos do not directly translate to users.  usually some 
>>> sort of directory services are leveraged in order to accomplish this, 
>>> though PAM and things like that can be used to.  by setting things in 
>>> idmapd.conf, you are telling NFS who to translate kerberos identities into 
>>> usernames, so ownership and permissions can be sync'd.
>> Both the NFS server and the client are configured as FreeIPA client.
>> On the server the users are known (through PAM, SSSD). Only user
>> "ubuntu" is a local (/etc/passwd) user. All other users are defined on
>> the IPA server.
>>
>> root@srv1:~# ls -l /home
>> total 0
>> drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb
>> drwxr-xr-x 1 ubuntu ubuntu 142 aug 17  2016 ubuntu
>> root@srv1:~# ls -ln /home
>> total 0
>> drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb
>> drwxr-xr-x 1  1000  1000 142 aug 17  2016 ubuntu
>>
>> On the client, same story
>>
>> root@client1:~# ls -l /nfshome
>> total 0
>> drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb
>> drwxr-xr-x 1 ubuntu  ubuntu  142 aug 17  2016 ubuntu
>> root@client1:~# ls -ln /nfshome
>> total 0
>> drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb
>> drwxr-xr-x 1  1000  1000 142 aug 17  2016 ubuntu
>>
>>
>>
>>>>>>>      then the user should be able to pull the ticket for auth.
>>>>>> Sorry to ask, but how do I do that? On the client, I suppose, and by the 
>>>>>> user ??
>>>>>>
>>>>>> keesb@client1$ kinit nfs/srv1.example....@example.com
>>>>>> Password for nfs/srv1.example....@example.com:
>>>>>>
>>>>>> But I don't have a password for that. Hmm.
>>>>> there is no need to init on the client side, as long as the TGT is 
>>>>> obtained.  you should never need to init the nfs/blah.. on the client 
>>>>> side.
>>>> OK
>>>> So, it seems to me that all the basics are setup correctly. The mount 
>>>> succeeds. The user
>>>> has a TGT and still the (non-root) user cannot even stat the mount point, 
>>>> nor the directory
>>>> entry itself.
>>>>
>>>> What puzzles me is that root can see everything, also without a TGT.
>>> the mount will succeed, but the user does not have access because NFS does 
>>> not know who the user it.  it has an unassociated ID established by 
>>> kerberos, but not a user.
>> Let's step back a little.
>>
>> On the NFS client, the user does an ls of / (that's where the mountpoint 
>> is). At the point
>> where ls reads the entry (through stat) for "nfshome" it gets (probably) 
>> EPERM.
>> And hence ls prints all the question marks. That leads me to believe that 
>> only the kernel
>> (on the NFS client) is involved at this point. I could be wrong but I don't 
>> think there is
>> any kerberos TGT involved.
>>
>>>>>>>> Furthermore, I'm guessing that the host principle which I got after 
>>>>>>>> ipa-client-install is
>>>>>>>> good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab 
>>>>>>>> for it, which I
>>>>>>>> did not do.)
>>>>>>>> # klist -ke
>>>>>>>> Keytab name: FILE:/etc/krb5.keytab
>>>>>>>> KVNO Principal
>>>>>>>> ---- 
>>>>>>>> --------------------------------------------------------------------------
>>>>>>>>        1 host/client1.example....@example.com (aes256-cts-hmac-sha1-96)
>>>>>>>>        1 host/client1.example....@example.com (aes128-cts-hmac-sha1-96)
>>>>>>>>
>>>>>>>> [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA
>>>>>>>> [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/
>>>>>>> http://www.itp.uzh.ch/~dpotter/howto/kerberos
>>>>>>>
>>> added the thread back to the mailing list for the benefit of any who search 
>>> on the subject.
>>>
>>>
> run journalctl -fl on both the NFS server and the NFS client while trying to 
> mount the share.  one of them should tell you something.

Nothing much. On the server I just see

    feb 23 15:47:34 srv1.example.com rpc.mountd[22742]: authenticated mount 
request from 172.16.16.39:678 for /home (/home)

The mount succeeds. Simple as that. Mounting is not the problem, I think.



>
> the mount operation will succeed, because any ACL set in the exports file is 
> being met.  root likley has access because the uid/gid is common and local on 
> both devices and therefore no mapping is needed.

OK. No problem with that.

>   your virtual user does not exist in either local user store, and therefore 
> needs to be mapped.

No, no, the virtual user is present on both sides, because both NFS server and 
client are configured
as IPA client. That user can login on both systems. The uid/gid mapping is 
straightforward.

>   what does /etc/nsswitch.conf say for passwd, shadow and group?
>

On both server and client:
passwd:         compat sss
group:          compat sss
shadow:         compat sss

-- 
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

Reply via email to