NFSv4 in a multi-realm environment
Configuration of libnfsidmap.so on Linux; name <=> id mapping for rpc.svcgssd, rpc.idmapd, and libacl.
libnfsidmap is a library holding mulitiple methods of mapping names to id's and visa versa, mainly for NFSv4.
We provide an extensible array of mapping functions, currently consisting of two choices; the default nsswitch and the experimental umich_ldap. The mapping method is configured using /etc/idmapd.conf.
The umich_ldap functions enable remote user@v4domain and remote GSS principal mapping. Remote group mapping will be coming soon.
Remember that these mapping functions are for libnfsidmap users only - rpc.svcgssd, rpc.idmapd, and libacl. Commands such as ls still use the nsswitch infrastructure.
When NFSv4 is using AUTH_GSS (which currently only supports Kerberos v5), the NFSv4 server mapping functions called by rpc.svcgssd and rpc.idmapd MUST use secure communications.
Note: The umich_ldap translation method is very new, and will change a lot as we get feedback and add functionality.
Note: The current libnfsidmap implementation does not use SASL because of library conflicts in rpc.svcgssd. rpc.svcgssd calls CITI's mech glue layer gssapi library (in nfs-utils). Cyrus SASL calls a their own gssapi interface which is not compatable with ours. We will resolve these conflicts ASAP.
InstructionsThese instructions were written assuming you are starting with the following:
For the experimental umich_ldap translation method
The nsswitch Translation Method
Here is an excerpt from /etc/idmapd.conf showing nsswitch as the configured Translation Method. Note that the UMICH_SCHEMA parameters are left undefined (indeed, they can be left out of /etc/idmapd.conf) as they are not used.
# One of # nsswitch -> configured via /etc/nsswitch.conf # umich_ldap -> [UMICH_SCHEMA] choices are filled in [Translation] Method = nsswitch [UMICH_SCHEMA] LDAP_server = LDAP_base = NFSv4_name_attr = NFSv4_group_attr = GSS_principal_attr =nsswitch is the default translation method. The nsswitch method uses the get password file entry functions getpwname(), getpwid(), and the get group file entry functions getgrnam(), getgrgid(). The nsswitch functions behaviour is configured by editing the /etc/nsswitch.conf passwd data base stanza.
Even though 'ldap' is not listed as a legal entry in /etc/nsswitch.conf, 'ldap' can be entered as an entry for the passwd and group databases. The ldap client is configured by editing /etc/ldap.conf.
If secure communications are required (AUTH_GSS), the passwd data base stanza can contain the 'file' entry because the rpc.idmapd and rpc.svcgssd run as root, and/or the 'ldap' entry if the ldap service is configured to use SASL in /etc/ldap.conf. The 'nis' entry is NOT recommended, it does not have a secure communications mode.
The umich_ldap Translation Method
Here is an excerpt from /etc/idmapd.conf showing umich_ldap as the configured Translation Method. Note that the UMICH_SCHEMA parameters are required to be filled in with this choice of method.
# One of # nsswitch # umich_ldap [Translation] Method = umich_ldap [UMICH_SCHEMA] LDAP_server = 188.8.131.52 LDAP_base = dc=arbitrary,dc=domain,dc=org NFSv4_name_attr = NFSv4Name NFSv4_group_attr = NFSv4Name GSS_principal_attr = GSSAuthName
This second set of mapping functions is a new experimental set called umich_ldap configured as we use it in the idmapd.conf example above. This set of translation functions are designed to service local and remote users, allowing remote users to set and get ACLs as well as map GSS principals to id's. The functions are LDAP based, and the ldap search filters look for attribute names set by idmapd.conf [UMICH_SCHEMA] NFSv4_name_attr, NFSv4_group_attr, and GSS_principal_attr attributes. This is an experimental setup; our intention is to interoperate with other NFSv4 platform remote user mapping schemes as they come on line.
It is assumed that the LDAP server will index the [UMICH_SCHEMA] attributes, and that these attributes will be associated with the nss.schema posixAccount uidNumber and gidNumber. We expect that the current hard-wired choice of the uidNumber attribute to hold the numeric UID and the gidNumber attribute to hold a numeric GID will be configurable via the idmapd.conf file soon.
NFSv4_name_attr holds an NFSv4 name of the form user@domain, where the domain portion of the name is a valid NFSv4 domain name. There is a one-to-one mapping between the NFSv4_name_attr name and a UID.
NFSv4_group_attr holds an NFSv4 name of the form group@domain, where the domain portion of the name is a valid NFSv4 domain name. There is a one-to-one mapping between the NFSv4_group_attr name and a GID.
Note: We are still experimenting with remote groups - should have some functionality soon.
GSS_principal_attr holds a GSS security mechanism specific context principal name. For Kerberos v5, it is a Kerberos principal.
For SPKM3, it is a PKI DN such as
"/C=US/ST=Michigan/O=University of Michigan/OU=UMICH Kerberos Certification Authority/CN=andros/USERID=andros/Email=andros@UMICH.EDU"
There is a many-to-one relationship between the GSS_principal_attr name and a UID plus GID.
We have defined LDAP object classes for our experimental NFSv4 id mapping. We made the attribute names configurable so that other sites could still use the umich_ldap translation functions with different LDAP attribute names.
We use the same attribute name, NFSv4Name for the NFSv4_name_attr and the NFSv4_group_attr. For local users and remote users that we wish to give a local machine account, we add the NFSv4Name attribute and the GSSAuthName attribute to the existing posixAccount schema.
We suggest you consult this power point talk entitled Remote Name Mapping for Linux NFSv4, also available in PDF format (Last updated 08-25-2005).The presentation shows an example of NFSv4 cross domain/Kerberos v5 cross realm Name to ID mapping, including setting ACLs for remote users using the umich_ldap attributes. The power point version is useful because it has notes, and some of the slides have actions.
Configure the LDAP server
The libtest programA stand alone test program, libtest is included in the nfsidmap distribution. It calls the complete libnfsidmap function set and is useful for testing LDAP configurations. Build and install libnfsidmap, and then build libtest as follows:
gcc -g libtest.c -lnfsidmap -o libtest
Here are the LDAP attributes and object classes that we are experimenting with.
nfsv4.schema ------------ attributetype ( 184.108.40.206.220.127.116.11.61 NAME ( 'NFSv4Name') DESC 'NFS version 4 Name' EQUALITY caseIgnoreIA5Match SYNTAX 18.104.22.168.4.1.1422.214.171.124.26 SINGLE-VALUE) attributetype ( 126.96.36.199.188.8.131.52.62 NAME ( 'GSSAuthName') DESC 'RPCSEC GSS authenticated user name' EQUALITY caseIgnoreIA5Match SYNTAX 184.108.40.206.4.1.14220.127.116.11.26) # # minimal information for NFSv4 access. used when local filesystem # access is not permitted (nsswitch ldap calls fail), or when # inetorgPerson is too much info. # objectclass ( 18.104.22.168.22.214.171.124.60 NAME 'NFSv4RemotePerson' DESC 'NFS version4 person from remote NFSv4 Domain' SUP top STRUCTURAL MUST ( uidNumber $ gidNumber $ NFSv4Name ) MAY ( cn $ GSSAuthName $ description) ) # # minimal information for NFSv4 access. used when local filesystem # access is not permitted (nsswitch ldap calls fail), or when # inetorgPerson is too much info. # objectclass ( 126.96.36.199.188.8.131.52.63 NAME 'NFSv4RemoteGroup' DESC 'NFS version4 group from remote NFSv4 Domain' SUP top STRUCTURAL MUST ( gidNumber $ NFSv4Name ) MAY ( cn $ memberUid $ description) )