LDAP + KERBEROS + NFS. Why do I need idmapd?

Question

What I am trying to do

I have a freeIPA domain, with a few clients and a Synology NAS (also enrolled in freeIPA).

I created a shared folder on the NAS, with NFSv4 + krb5 support. From the client, I obtain a ticket for LDAP user [email protected] and I mount this folder.

Initially, files created in this folder would be owned by nobody user.

I finally had it working, by changing /etc/idmapd.conf on the NAS to

• have the domain set correctly
• have a static mapping between [email protected] and a local user

Question

I do understand the role of idmapd fore NFS in general.

In this case however:

• why do I need explicit mappings? Can't it figure it out itself?
• why do I need a mapping at all? The NAS is also in the same freeIPA domain, is an LDAP client and has the right kerberos principals.It knows perfectly who [email protected] is, why can't it just use THAT uid for file ownership on that folder, instead of the uid of a local user? Can I avoid creating local users?

My current idmapd.conf looks like this:

[General]
Domain=hq.example.com

[Mapping]
Nobody-User=guest
Nobody-Group=users

[Translation]
Method=nsswitch
GSS-Methods=static,synomap

[Static]
[email protected]=user1

What I would like to achieve is that I don't need that static mapping [email protected]=user1 and if possible that I don't even need to create a local user user1 on the NAS.

Solution

The short of it is that NFSv4 protocol relies a username being shared between the server and client, and not the UID/GID numbers (which were used in the earlier versions) and the UID <==> username mapping can actually be different on the client and the server.

As part of the NFSv4 protocol both the server need to map the common security contexts/permissions, owner and owner_group to something that makes sense for the local file-system operations. That mapping is done by IDMAPD on Linux systems.

On a Linux system many local file-systems operations are UID/GID based but those need to be translated to the shared NFSv4 context before they can be transmitted to the NFS server.

Maybe RFC 3530 can explain it better:

§ 5.8. Interpreting owner and owner_group

The recommended attributes "owner" and "owner_group" (and also users and groups within the "acl" attribute) are represented in terms of a UTF-8 string. To avoid a representation that is tied to a particular underlying implementation at the client or server, the use of the UTF-8 string has been chosen. Note that section 6.1 of [RFC2624] provides additional rationale. It is expected that the client and server will have their own local representation of owner and owner_group that is used for local storage or presentation to the end user. Therefore, it is expected that when these attributes are transferred between the client and server that the local representation is translated to a syntax of the form "user@dns_domain". This will allow for a client and server that do not use the same local representation the ability to translate to a common syntax that can be interpreted by both.

---

Edit in response to your imapd.conf.

You using a static mapping to local user. You probably want to map the NFSv4 identities to LDAP users, which probably should should happen by the nsswitch option, but apparently is not. You could try to see what is happening by increasing the verbosity of the idmapd on the NFS server.

Alternatively configure idmapd to directly query your LDAP server. The exact syntax may depend on the version you're using, but the man page shows something along the lines of :

[General]

Verbosity = 0
Domain = domain.org
Local-Realms = DOMAIN.ORG,MY.DOMAIN.ORG,YOUR.DOMAIN.ORG

[Mapping]

Nobody-User = nfsnobody
Nobody-Group = nfsnobody

[Translation]

Method = umich_ldap,nsswitch
GSS-Methods = umich_ldap,static

[Static]
[email protected] = johnny

[UMICH_SCHEMA]   
LDAP_server = ldap.domain.org
LDAP_base = dc=org,dc=domain

Comments

[cornuz]

perhaps I'm still missing the point. When the user is an LDAP user, is it still true that UID <==> username mapping can actually be different on the client and the server? They both know that [email protected] has UID 123456. It is the same user on both sides, right? Not just two users with the same name.

[HBruijn]

In your particular case yes, username to uid mapping is identical for both NFSV4 server and client, but in the generic case it is not.

[cornuz]

Thanks, this makes things clearer. In practice though, does it mean that I can avoid creating local users on the nfs server to be explicitly mapped to the corresponding LDAP users? I thought that just setting the domain correctly in idmapd.conf would achieve this, but I can't get it to work without those explicit mappings.

[HBruijn]

How to explain this best. Uhhm the file system on your NFS server still uses UID and GID numbers for ownership and since those don't come with the username over NFSv4 you still need to provide a mapping to retrieve those from your LDAP

[cornuz]

But the NFS server is also an LDAP client, it knows (from LDAP server) what the uid is. If we forget about NFS, and just have an LDAP client, this client doesn't need to have a local user and map it to the LDAP user. It just uses the LDAP user. So why can't the NFS server do the same?

[HBruijn]

Are you actually using idmapd.conf to map directly to your LDAP or are you using static mappings?

[cornuz]

I would like to avoid static mappings, but I can't get it to work without. I updated my answer including my current idmapd.conf.

[cornuz]

Thanks for the answer update. Unfortunately it's not so easy to make changes in idmapd.conf, as they would be rewritten by the GUI the next time I save anything from there. But your answer solves the big doubt I had about the necessity of explicit mappings.