diff options
Diffstat (limited to 'support/nfsidmap/README')
| -rw-r--r-- | support/nfsidmap/README | 126 |
1 files changed, 126 insertions, 0 deletions
diff --git a/support/nfsidmap/README b/support/nfsidmap/README new file mode 100644 index 0000000..5a448ef --- /dev/null +++ b/support/nfsidmap/README @@ -0,0 +1,126 @@ +Library to help mapping id's, mainly for NFSv4. + +When NFSv4 is using AUTH_GSS (which currently only supports Kerberos v5), the +NFSv4 server mapping functions MUST use secure communications. + +We provide several mapping functions, configured using /etc/idmapd.conf + +As of the 0.21 version of this library, mapping methods are separate +dynamically-loaded libaries. This allows the separation of any +LDAP requirements from the main libnfsidmap library. The main library +now basically loads and calls the functions in the method-specific +libaries. The method libraries are expected to be named +"libnfsidmap_<method>.so", for example, "libnfsidmap_nsswitch.so". + +Several methods may be specified in the /etc/idmapd.conf configuration +file. Each method is called until a mapping is found. + +The following translation methods are delivered in the default distribution: + +nsswitch +-------- + +The default method is called nsswitch. This method uses the get password +file entry functions getpwname(), getpwid(), and the get group file entry +functions getgrnam(), getgrgid(). The nsswitch method can therefore be +configured by the /etc/nss_switch.conf passwd data base stanza. 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. + + +static +------ + +This method works only for translating GSS authenticated names to local +names. It uses a static mapping setup defined in the [Static] section +of the idmapd.conf file. The form of the entries are: + <GSS-Authenticated name> = <localuser> + +For example: + nfs/host.domain.org@DOMAIN.ORG = root + +It is recommended that this module be used in combination with another +module (e.g. the nsswitch module). + +umich_ldap +---------- +An experimental method, umich_ldap uses an LDAP schema and ldap functions +to perform translations. This method is designed to service 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. + +It is assumed that the LDAP server will index these attributes, and that these +attributes will be associated with the nss.schema posixAccount uidNumber and +gidNumber. We expect that the uidNumber and gidNumber attribute 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. + +GSS_principal_attr holds a GSS security mechanism specific context principal +name. For Kerberos v5, it is a Kerberos principal <service/>principal@REALM. +For SPKM3, it is a PKI DN such as (line is split):` +"/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 TR_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 inetorgPerson and posixAccount schema. +For remote users that we do not wish to give a local machine account, +we use the NFSv4RemotePerson object to contain the NFSv4Name, uidNumber, +gidNumber, and GSSAuthName. + +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) ) + |