ldap – Why idmapd is Needed for LDAP + KERBEROS + NFS

freeipakerberosldapnfs

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 user1@mydomain.com 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 user1@mydomain.com 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 user1@mydomain.com 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]
user1@HQ.EXAMPLE.COM=user1

What I would like to achieve is that I don't need that static mapping user1@HQ.EXAMPLE.COM=user1 and if possible that I don't even need to create a local user user1 on the NAS.

Best Answer

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]
johndoe@OTHER.DOMAIN.ORG = johnny

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