projects techreports press lab location staff
citi top.2 top.3
citi mid.3
bot.1 bot.2 bot.3
star

Projects: NFS Version 4 Open Source Reference Implementation

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.

Instructions

These instructions were written assuming you are starting with the following:
  • A complete installation of Fedora Core

    Note that this should work with any distribution with the (currently required) ldap headers and libraries installed. Ldap may be provided by a package named "libldap2-dev" or similar.

  • The latest nfs-utils with our patches, and the latest nfsidmap library; libnfsidmap.so from here

For the experimental umich_ldap translation method

  • The ldap client installed and configured
  • An ldap server installed and configured where you can add schema

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.

nsswitch Instructions

  • Build and install libnfsidmap.so
  • Add the [Translation] section to /etc/idmapd.conf with Method = nsswitch
  • Configure nsswitch behaviour (/etc/nsswitch.conf)
  • If using ldap in nsswitch, configure ldap behaviour (/etc/ldap.conf)

    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 = 141.211.133.100
    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.

    principal@REALM 
    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.

    umich_ldap instructions

  • Build and install libnfsidmap.so
  • Add the [Translation] section to /etc/idmapd.conf with Method = umich_ldap
  • Add the [UMICH_SCHEMA] section to /etc/idmapd.conf and give values to LDAP_server, LDAP_base, NFSv4_name_attr, NFSv4_group_attr, and GSS_principal_attr.

    Configure the LDAP server

  • Decide on NFSv4_name_attr and GSS_principal_attr names, and how you will associate them with the posixAccount uidNumber and gidNumber.
  • For each local and remote user you wish to give NFSv4 access, add the NFSv4_name_attr attribute (we use NFSv4Name) with user@v4domain as a value.
  • For each local and remote user you wish to give Kerberos V access, add the GSS_principal_attr attribute (we use GSSAuthName) with principal@REALM as a value.

    The libtest program

    A 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
    

    UMICH Schema

    Here are the LDAP attributes and object classes that we are experimenting with.

    nfsv4.schema
    ------------
    attributetype ( 1.3.6.1.4.1.250.1.61
            NAME ( 'NFSv4Name')
            DESC 'NFS version 4 Name'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
            SINGLE-VALUE)
    
    attributetype ( 1.3.6.1.4.1.250.1.62
            NAME ( 'GSSAuthName')
            DESC 'RPCSEC GSS authenticated user name'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.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 ( 1.3.6.1.4.1.250.1.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 ( 1.3.6.1.4.1.250.1.63 NAME 'NFSv4RemoteGroup'
            DESC 'NFS version4 group from remote NFSv4 Domain'
            SUP top STRUCTURAL
            MUST ( gidNumber $ NFSv4Name )
            MAY ( cn $ memberUid $ description) )
    
  • blank.space
    b.star projects | techreports | press | lab | location | staff Email address
    or call +1 734 763 2929
    Copyright © 1996-2013
    The Regents of the University of Michigan
    bottom.line
    citi