NFSv4 Working Group W. Adamson Internet-Draft NetApp Intended status: Standards Track K. Coffman Expires: January 4, 2010 CITI, University of Michigan July 3, 2009 NFSv4 Multi-Domain Access draft-adamson-nfsv4-multi-domain-access-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 4, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Adamson & Coffman Expires January 4, 2010 [Page 1] Internet-Draft NFSv4 Multi-Domain Access July 2009 Abstract The NFS Version 4 [NFSv40] protocol enables the construction of a distributed file system which can join NFSv4.0 or NFSv4.1 [NFSv41] servers, which potentially use separate name translation services and separate security services, into a common name space. The protocol supports multiple authentication methods and does not restrict how users are represented or authenticated. As such a user's view of the name space may be limited by the authentication and authorization privileges they have on the different file servers in the name space. This document discusses authentication and authorization management and proposes two name service attributes that are used for NFSv4 name and security principal translations to enable users to traverse and access files in a secure, multi-domain NFS Version 4 name space. Adamson & Coffman Expires January 4, 2010 [Page 2] Internet-Draft NFSv4 Multi-Domain Access July 2009 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Background and Motivation . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Overview of NFSv4 Namespace and Name Translation . . . . . 7 2.3.1. NFSv4 Server Pseudo File System . . . . . . . . . . . 7 2.3.2. NFSv4 Referral . . . . . . . . . . . . . . . . . . . . 7 2.3.3. NFSv4 ACL Name and GSS Principal Translation . . . . . 7 3. Managing Access in a local NFSv4 Environment . . . . . . . . . 11 3.1. Security Services . . . . . . . . . . . . . . . . . . . . 11 3.2. DNS Domains . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. The NFSv4 Domain . . . . . . . . . . . . . . . . . . . . . 12 3.4. Name Translation Requirements in an NFSv4 Domain . . . . . 12 4. Managing Access Across Multiple NFSv4 Domains . . . . . . . . 15 4.1. Name Translation Requirements in the Federated FS . . . . 16 5. New LDAP Attributes and Object Class . . . . . . . . . . . . . 19 5.1. Multiple NFSv4 Domain Translation Solution . . . . . . . . 20 5.2. Local NFSv4 Domain LDAP Attribute Use . . . . . . . . . . 22 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Adamson & Coffman Expires January 4, 2010 [Page 3] Internet-Draft NFSv4 Multi-Domain Access July 2009 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Adamson & Coffman Expires January 4, 2010 [Page 4] Internet-Draft NFSv4 Multi-Domain Access July 2009 2. Introduction 2.1. Background and Motivation Authentication and authorization in NFS4 occurs at the RPC [RFC1831] level with the RPC credential presenting the security principal to the NFSv4 server for translation into a local representation. Setting authorization for file object access occurs in the NFSv4 layer where NFSv4 acl attribute names are also presented to the NFSv4 server for translation. The choice and management of security services and name translation services is therefore central to enabling access in an NFS Version 4 name space. The name space scope directly effects the choice and management of name translation and security services. For example, a single enterprise could have a firewalled network, use low security protocols, and employ a common identity for users across the file servers in the name space. A grid or a physically distributed enterprise environment could require a high security level and utilize name and principal translations across different administrative domains. The Network Information Service [NIS], the Lightweight Directory Service [LDAP], and Active Directory [AD-LDAP] are the three broadly used client-server directory service protocols for distributing system configuration data and providing name translation in managed networked environments. LDAP and Active Directory are used instead of NIS in environments where scale and security are issues. Active Directory uses the LDAP protocol for many purposes including name translation. This document uses LDAP as a name service in all examples and solutions. RFC2307 [RFC2307] defines the LDAP posixAccount object class and an associated set of attributes used to resolve account information such as user IDs to login names and group IDs to group names. The posixAccount class requires a one-to-one correspondence between the user's login name (uid attribute) and the user's integer identification number (uidNumber attribute). Distributed file systems such as NFS Version 2 [RFC1094], NFS Version v3 [RFC1813], and AFS [AFS_ACM] keep this one-to-one correspondence either by placing numeric user identifiers on the wire or by supporting a single Kerberos [RFC4120] realm and using the user's login name as the Kerberos principal. These distributed file systems maintain the one-to-one uid to uidNumber correspondence and can continue to use the posixAccount class for name (and Kerberos principal) to uidNumber resolution. Adamson & Coffman Expires January 4, 2010 [Page 5] Internet-Draft NFSv4 Multi-Domain Access July 2009 NFSv4 can have multiple acl attribute names and multiple security principals associated with a user and so presents a name to uidNumber resolution problem that is not solved by the current LDAP attribute set. This document demonstrates the need for two new LDAP name service attributes and object classes (Section 5) by starting with a simple name space (Section 3) and building into one that spans administrative domains (Section 4) where each domain requires a name service and a high level of security. The name translation, authentication and authorization requirements of the Federated File System [FEDFS-REQTS] are discussed throughout. 2.2. Terminology NFSv4: Refers to both the NFS Version 4 Minor Version 0 [NFSv40] and the NFS Version 4 Minor Version 1 [NFSv41] protocols unless otherwise stated. Local representation: How a local file system represents users and groups which we define as the LDAP posixAccount uidNumber or gidNumber. NFSv4 ACL name: The NFSv4 draft recommended attributes "owner" and "owner_group", and also users and groups within the "acl" attribute. The name is of the form user@dns_domain. GSS principal: The security principal name in an NFSv4 draft supported GSS [RFC2743] Security Mechanism. NFSv4 name service: A service that translates between an NFSv4 ACL user name and a uidNumber, a GSS principal and a uidNumber, and an NFSv4 ACL group name and a gidNumber. Host-based authentication: An authentication model used by NFSv4 where the NFSv4 server authenticates the NFSv4 client, and trusts the client to authenticate all users. The AUTH_SYS security flavor depends on host-based authentication. User-based authentication: An authentication model used by NFSv4 where the user principal is authenticated by an NFSv4 server, and the NFSv4 server is authenticated by the user principal. The RPCSEC_GSS [RFC2203] Kerberos security mechanism is an example of a user-based authentication model. Adamson & Coffman Expires January 4, 2010 [Page 6] Internet-Draft NFSv4 Multi-Domain Access July 2009 Absent file system: An export on an NFSv4 server that serves a location attribute, but has no data. Local NFSv4 environment: A local NFSv4 environment is one where client workstations and file servers share an NFSv4 name service and so the exported file systems share an NFSv4 ACL space. Foreign user: A user from a different NFSv4 name service. 2.3. Overview of NFSv4 Namespace and Name Translation To provide a context for the reader two major features of the NFSv4 name space, the building blocks of the name space, are reviewed in brief. An example of how NFSv4 uses name translation in a single client to single server environment is also provided. 2.3.1. NFSv4 Server Pseudo File System The NFSv4 server presents its exports as leaves of a single name space, the pseudo file system. An NFSv4 client mounts the server pseudo file system root and uses LOOKUP and READDIR operations to browse seamlessly from one export to another. The server administrator can change the server exports without changing the client mountpoint. 2.3.2. NFSv4 Referral An NFSv4 server can export an absent file system and such an export can be a leaf of the server's pseudo file system. One of the uses of the NFSv4 fs_location attribute is to return the 'real' location of an absent file system exported by an NFSv4 server. An absent file system contains no files or directories other than the root. Any reference to it, except to access a small set of attributes useful in determining alternate locations, will result in an error, NFS4ERR_MOVED. The NFSv4 client responds to the NFS4ERR_MOVED error by requesting the fs_location attribute which redirects the client to the actual file system location. This provides a means by which file systems located on one server can be associated with a name space defined by another server, thus allowing a general multi-server name space facility. A designation of such a location, in place of an absent file system, is called a "referral". 2.3.3. NFSv4 ACL Name and GSS Principal Translation NFSv4 uses a syntax of the form "user@dns_domain" to represent the NFSv4 ACL name. This design gives a level of indirection that allows Adamson & Coffman Expires January 4, 2010 [Page 7] Internet-Draft NFSv4 Multi-Domain Access July 2009 the client and server to translate their local representation to a common syntax. The Kerberos identity shares this feature as it is also in string form with the syntax of principal@REALM. client.business.com server.business.com (BUSINESS.REALM) (BUSINESS.REALM ) Figure 1: Single client and server namespace An example of the name translations involved for a user Bob to set an NFSv4 ACL for Alice across the POSIX interface on client.business.com on a file in a Kerberos protected NFSv4 export on server.business.com is given. The client and server share a name service, the DNS business.com domain, and the Kerberos BUSINESS.REALM realm. This example will be extended in steps from the single client and server to a multi-domain federated file system in upcoming sections. Adamson & Coffman Expires January 4, 2010 [Page 8] Internet-Draft NFSv4 Multi-Domain Access July 2009 Typical LDAP name service entries for the fictional users Bob Bar and Alice Answer. # bob, People, business, com dn: uid=bob,ou=People,dc=business,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: posixAccount cn: Bob B. Bar sn: Bar uid: bob mail: bob@business.com uidNumber: 2975 gidNumber: 10 homeDirectory: /users/bob loginShell: /bin/csh displayName: Bob B. Bar # alice, People, business, com dn: uid=alice,ou=People,dc=business,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: posixAccount cn: Alice A. Answer sn: Answer uid: alice mail: alice@business.com uidNumber: 1002 gidNumber: 10 homeDirectory: /users/alice loginShell: /bin/csh displayName: Alice A. Answer Figure 2 Prior to sending the first compound RPC to the server, user-based authentication is used to establish a Kerberos GSS context for Bob on the client and the server. At the end of a successful GSS context establishment, before the NFSv4 server can grant any file system access, Bob's Kerberos GSS principal must be mapped to a uidNumber on the file server. Note that the uidNumber mapping requirement for NFSv4 access allows separation of NFSv4 access from general Kerberos authentication. Adamson & Coffman Expires January 4, 2010 [Page 9] Internet-Draft NFSv4 Multi-Domain Access July 2009 The posixAccount class uid attribute can be used for all the name translations in this simple example by making Bob's POSIX login name and his Kerberos principal name the same, and by stripping the '@BUSINESS.REALM' and the '@business.com' from the Kerberos principal and the NFSv4 ACL name respectively prior to submitting the names for translation. In other words, the posixAccount uid "bob",the NFSv4 ACL name "bob@business.com" and the Kerberos principal name "bob@ BUSINESS_REALM" are all equivalnet. The server will need a list of DNS domains it will accept as valid (business.com in this example) and check the @dns_domain portion of an NFSv4 ACL name prior to translation. Also required is the addition of the @business.com to translated uids to create the NFSv4 ACL name. Step 1: On the NFSv4 server (GSS interface), the @BUSINESS.REALM portion of Bob's Kerberos principal is stripped prior to contacting the LDAP name service. bob@BUSINESS.REALM -> bob -> uidNumber 2975 Bob now has a Kerberos protected GSS connection to the server, which is used to set an acl for 'alice' on a file. Bob enters the POSIX setacl command and the client POSIX interface translates "alice" into the local uidNumber. Step 2: On the client (POSIX interface) alice -> uidNumber 1002 The NFS4 client translates the uidNumber into a user@dns_domain NFS4 ACL name required for the NFSv4 SETATTR operation acl attribute which is sent to the server. Step 3: On the client (NFSv4 interface). The @business.com portion of the name is added after the uidNumber translation. uidNumber 1002 -> alice -> alice@business.com The server translates the NFS4 ACL name to be used to set the ACL on the file system object. Step 4: On the server (NFSv4 interface), the @business.com portion of the name is stripped prior to contacting the LDAP name service. alice@business.com -> alice -> uidNumber 1002 The server sets the ACL on the file using Alice's uidNumber. Adamson & Coffman Expires January 4, 2010 [Page 10] Internet-Draft NFSv4 Multi-Domain Access July 2009 3. Managing Access in a local NFSv4 Environment The NFSv4 [NFSv40] draft addresses all of the pieces of NFSv4 administration each with many options. Stand alone NFSv4 sites choose which options serve their needs. To address the name translation issues of joining stand alone sites into a multi-domain NFSv4 namespace such as the federated file system, some common choices of the available administration options need to be agreed upon. This section describes these common choices, and then expands upon the single client to single server example (Figure 1). 3.1. Security Services As described in section 2.2.1.1 "RPC Security Flavors" of [NFSv41]: NFSv4.1 clients and servers MUST implement RPCSEC_GSS. (This requirement to implement is not a requirement to use.) Other flavors, such as AUTH_NONE, and AUTH_SYS, MAY be implemented as well. The AUTH_SYS security flavor uses a host-based authentication model which can only be use in an NFSv4 name space where all clients and servers share a name service. A shared name service is required because uidNumbers are passed in the RPC credential, and there is no indication of which service translated the user name to the uidNumber so collisions can occur between administrative domains. The AUTH_NONE security flavor is useful to the multi-domain NFSv4 or federated name space to grant universal access to public data without any credentials. The RPCSEC_GSS security flavor with the Kerberos security mechanism is mandated by both NFS Version 4 [NFSv40] [NFSv41] drafts and being a user-based authentication model is appropriate for use in the multi-domain federated name space. Multiple Kerberos Realms per local NFSv4 environment are supported. A single Kerberos Realm can also be part of multiple local NFSv4 environments, each with a distinct name service. The RPCSEC_GSS security flavor with an X.509 based security system is another user-based authentication module appropriate for use in the multi-domain federal name space. 3.2. DNS Domains Multiple DNS domains can be used by the client workstations and file servers in a local NFSv4 environment served by a single name service. The NFS Version 4 Minor Version 0 [NFSv40] draft specifies a broad Adamson & Coffman Expires January 4, 2010 [Page 11] Internet-Draft NFSv4 Multi-Domain Access July 2009 relationship between a DNS domain and the dns_domain portion of the user@dns_domain in the ACL name. The only constraint is that servers "should accept as valid a set of users for at least one domain". The method the NFSv4 client uses to construct a user@dns_domain name to place on the wire is not even discussed, the client machine's DNS domain name is one likely choice. Given a set of NFSv4 file servers serviced by multiple DNS domains, the protocol allows a single user to have different NFSv4 user@ dns_domain ACL names due to the different DNS domains the NFSv4 servers belong to. This becomes confusing to say the least when two servers using the same name service return ACLs for the same user with different user@dns_domain names. 3.3. The NFSv4 Domain The NFSv4 Domain, roughly the equivalent of an AFS Cell, is the collection of administrative services used to build a multi-domain NFSv4 federated file system, and is defined as follows. The NFSv4 Domain is an independently administered site running NFSv4 and consists of a collection of NFSv4 file servers and client workstations that share a name service, has one or more DNS domains, and one or more security services. The NFSv4 domain administrator MUST choose one of the DNS domains servicing the NFSv4 file servers and client machines to use as the NFSv4 Domain name for use with the multi-domain NFSv4 federated file system. The NFSv4 domain name MUST be unique among all NFSv4 Domains. All the NFSv4 clients MUST be configured to use the NFSv4 Domain name as the "dns_domain" portion of the user@dns_domain NFSv4 ACL name. The name service MUST service only one NFSv4 Domain. The Kerberos realms and the DNS domains are independent of the NFSv4 Domain and can service more than one NFSv4 Domain. The unique NFSv4 Domain name requirement along with the single name service per NFSv4 Domain requirement ensures unique user@dns_domain names across multiple NFSv4 Domains. Each NFSv4 user participating in a multi-domain NFSv4 name space such as the federated file system has exactly one NFSv4 ACL name. 3.4. Name Translation Requirements in an NFSv4 Domain In this section we define an NFSv4 Domain which we will use to illustrate NFSv4 ACL name and GSS principal translation requirements, expanding upon the Simple Client and Server example (Figure 1). Adamson & Coffman Expires January 4, 2010 [Page 12] Internet-Draft NFSv4 Multi-Domain Access July 2009 The example NFSv4 Domain is a local NFSv4 environment consisting of a collection of client workstations and file servers running NFSv4 that share a name service, run multiple Kerberos realms, use multiple DNS domains with the file servers joined in a hierarchical name space built using NFSv4 pseudo file servers and referral exports. NFSv4 Domain name: business.com Kerberos Realm1: BUSINESS.REALM Kerberos Realm1: BUSINESS_ENG.REALM DNS Domain: business.com DNS Domain: business.eng.com The NFSv4 Domain business.com name is chosen from one of the DNS names. Figure 3: The business.com NFSv4 Domain The business.com NFSv4 Domain (Figure 4) has the following name space consisting of three servers: root.business.com, server.business.com and server.business.eng.com. There are also two client machines shown. Each machine shows the Kerberos REALM that they belong to in parentheses below their name. The Kerberos realms BUSINESS.REALM and BUSINESS_ENG.REALM share cross-realm trust between them. This means that authentications done in BUSINESS.REALM are accepted in BUSINESS_ENG.REALM, and authentications done in BUSINESS_ENG.REALM are accepted in BUSINESS.REALM. The name space starts at root.business.com which has two referral exports, and has no data. In the Federated FS [FEDFS-PROT], this is called the root file server. The clients mount "/" on root.business.com, the root of root.business.com's pseudo file system name space. Users traverse the client mount point to root.business.com, and then cross a referral to either server.business.com's or server.business.eng.com's pseudo file system name space root (dotted lines). Adamson & Coffman Expires January 4, 2010 [Page 13] Internet-Draft NFSv4 Multi-Domain Access July 2009 client.business.eng.com client.business.eng.com ( BUSINESS.REALM ) ( BUSINESS_ENG.REALM ) root.business.com ( BUSINESS.REALM ) / \ / \ server.business.com server.business.eng.com ( BUSINESS.REALM ) ( BUSINESS_ENG.REALM ) Figure 4: NFSv4 Domain with multiple Kerberos and DNS services The NFSv4 ACL name and GSS principal translations are similar to the single client and server example (Figure 1). The addition of a second Kerberos Realm with cross realm trust means that there are now potentially two GSS principal names associated with each posixAccount uid and uidNumber. e.g. bob@BUSINESS.REALM and bob@ BUSINESS_ENG.REALM. Note that there is no requirement that the principal portion of the two principal@REALM Kerberos names are the same. The posixAccount object class could still be used for all the name translations in this NFSv4 Domain example only by making Bob's POSIX login name and his Kerberos principal name in both realms the same. Adamson & Coffman Expires January 4, 2010 [Page 14] Internet-Draft NFSv4 Multi-Domain Access July 2009 4. Managing Access Across Multiple NFSv4 Domains This section presents the name translation problems in joining multiple NFSv4 Domains (Section 3.3) into a single NFSv4 namespace. These problems are addressed in a following section (Section 5.1). The federated file system [FEDFS-REQTS] is used in the example. The example (Figure 6) shows two NFSv4 Domains joined into a federation: the business.com NFSv4 Domain (Figure 3) and a new NFSv4 Domain, university.edu (Figure 5). NFSv4 Domain name: university.edu Kerberos Realm: UNIVERSITY.REALM DNS Domain: university.edu Figure 5: The university.edu NFSv4 Domain The NFSv4 Domain university.edu has a single Kerberos realm and a single DNS domain with two file servers root.university.edu and server.university.edu joined into a simple namespace with one referral. client.business.com client.university.edu ( BUSINESS.REALM ) ( UNIVERSITY.REALM ) federated_root.business.com / \ / \ root.business.com root.university.edu ( BUSINESS.REALM ) ( UNIVERSITY.REALM ) / \ | / \ | server.business.com server.business.eng.com server.university.edu ( BUSINESS.REALM ) ( BUSINESS_ENG.REALM ) ( UNIVERSITY.REALM ) Figure 6: A federation of multiple NFSv4 Domains The two NFSv4 Domains, business.com and university.edu are joined into a federated file system via junctions [FEDFS-PROT] (e.g. referrals) denoted by dashed lines which join a 'leaf' of federated_root.business.com's pseudo file system with the pseudo file system root of either root.business.com or root.university.edu. The root fileset [FEDFS-PROT] is the top-level fileset of the federation namespace, and is hosted by the NFSv4 Domain business.com on the file server federated_root.business.com. Both root.business.com and root.university.edu export their pseudo file systems with Kerberos Adamson & Coffman Expires January 4, 2010 [Page 15] Internet-Draft NFSv4 Multi-Domain Access July 2009 security only, requiring users to present appropriate Kerberos credentials to traverse the namespace. The pseudo file system on federated_root.business.com is exported with AUTH_NULL to allow universal access. The BUSINESS.REALM realm has a cross-realm trust relationship with UNIVERSITY.REALM which means that Bob and Alice can use their BUSINESS.REALM Kerberos credentials to gain access to UNIVERSITY.REALM protected resources. The client machines mount federated_root.business.com's pseudo file system root, and users traverse the junctions as their Kerberos credentials and uidNumber translations allow. Note that the 'trick' of stripping the @REALM or the @dns_domain portions of names that was used in the examples in Section 2.3.3 and Section 3.4 will not work here because the business.com NFSv4 Domain and the university.edu NFSv4 Domain do not share a name service. 4.1. Name Translation Requirements in the Federated FS This section looks at the NFSv4 ACL name and GSS principal translations required for a user in the the business.com NFSv4 Domain to traverse the federated name space (Figure 6) and access a file in the university.edu NFSv4 Domain. Once again, the POSIX setacl operation example is used. Specifically, the translations required for the user bob on client.business.com to set an NFSv4 ACL for alice@business.com across the federated name space (Figure 6) on a file foo exported by server@university.edu are examined. Bob logs into client.business.edu and performs the following POSIX setacl command. % setacl -m u:alice:r /nfsv4/root_university/server_university/foo Figure 7: A POSIX setacl granting alice read access to file foo The POSIX interface on client.business.com translates "alice" into the local uidNumber. Step 1: On client.business.com (POSIX interface) alice -> uidNumber 1002 Figure 8 Adamson & Coffman Expires January 4, 2010 [Page 16] Internet-Draft NFSv4 Multi-Domain Access July 2009 Prior to performing the setacl, the NFS client will need to parse the path to the target file on server.university.edu. Details on the translations (if any) involved follow. The federated root is mounted at /nfsv4 on client.business.com. Since this is exported with AUTH_NULL access is granted and there are no translations. The junction on federated_root.business.com to root.university.edu is (pseudo file system root)/root_university. Since this is exported Kerberos only, a Kerberos GSS context will need to be established between Bob and root.university.edu, and root.university.edu will need to translate a uidNumber for Bob's Kerberos principal. Step 2: On root.university.edu (GSS interface) bob@BUSINESS.REALM -> uidNumber ???? Here is the first problem, which is resolved in Section 5.1, Bob does not have an assigned uidNumber in the university.edu NFSv4 Domain name service used by root.university.edu. The problem of no uidNumber translation for bob@BUSINESS.REALM is repeated for the next path elements. The junction on root.business.com to server.university.edu is (pseudo file system root)/server_university. This is also exported Kerberos only, and a Kerberos GSS context will need to be established between Bob and server.university.edu which will fail on the uidNumber translation. Step 3: On server.university.edu (GSS interface) bob@BUSINESS.REALM -> uidNumber ???? This fails for the same reason as Step 2. The NFSv4 client needs the uidNumber from the setacl POSIX interface in Figure 8 translated into an NFS4 ACL name required for the SETATTR operation which peforms the setacl on the server. Step 4: On client.business.com (NFSv4 interface). The @business.com portion of the name is added after the uidNumber translation. uidNumber 1002 -> alice -> alice@business.com The server.university.edu receives the SETATTR and needs to translate the NFS4 ACL name alice@business.com into a uidNumber to be used to set the ACL on the file system object. Adamson & Coffman Expires January 4, 2010 [Page 17] Internet-Draft NFSv4 Multi-Domain Access July 2009 Step 5: On server.university.edu (NFSv4 interface) alice@business.com -> uidNumber ???? Here is another problem. alice@business.com does not have an assigned uidNumber in the university.edu NFSv4 Domain name service. This is resolved in Section 5.1 Adamson & Coffman Expires January 4, 2010 [Page 18] Internet-Draft NFSv4 Multi-Domain Access July 2009 5. New LDAP Attributes and Object Class The NFSv4 name service needs the following capabilities in order to be configured to allow foreign users to access files. The LDAP attributes presented here address these needs. o Each foreign user needs an LDAP entry with a uidNumber in the local NFSv4 Domain. o Each foreign user's NFSv4 name (user@dns_domain) needs to be associated with their uidNumber in the local NFSv4 Domain. o Each GSS principal a foreign user is allowed to authenticate as needs to be associated with their uidNumber in the local NFSv4 Domain. These LDAP attributes and object class were developed at the Center for Information Technology Integration at the University of Michigan and have been experimented with in the Linux idmap daemon 'umich_ldap translation' method since 2005. A new attribute is defined to hold the NFSv4 ACL name. It is formed by using the posixAccount uid for the 'user' portion, and the unique NFSv4 Domain name for the 'dns_domain' portion. It is not proposed that the posixAccount uid be replaced with a uid@ nfsv4_domain syntax in order to separate local and NFSv4 access. The user@dns_domain syntax only has meaning for the NFSv4 file systems and would be inappropriate for local POSIX translation. The NFSv4Name attribute provides a one-to-one correspondence between the unique NFSv4 Domain user@dns_domain NFSv4 ACL name and the uidNumber. attributetype ( 1.3.6.1.4.1.250.10.5 NAME ( 'NFSv4Name') DESC 'NFS version 4 Name' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) A second new attribute is defined to hold the per security mechanism GSS principal. A Kerberos GSSAuthName would have the principal@REALM syntax. An X.509 GSSAuthName would hold the Distinguished Name with a syntax such as "/C= /ST= /O= /OU= /CN= /USERID=/Email=". Adamson & Coffman Expires January 4, 2010 [Page 19] Internet-Draft NFSv4 Multi-Domain Access July 2009 This attribute provides a many-to-on correspondence between each GSS principal and the uidNumber. attributetype ( 1.3.6.1.4.1.250.10.6 NAME ( 'GSSAuthName') DESC 'RPCSEC GSS authenticated user name' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) The NFSv4Person class holds the minimal information required for NFSv4access. objectclass ( 1.3.6.1.4.1.250.10.7 NAME 'NFSv4Person' DESC 'NFS version4 person from remote NFSv4 Domain' SUP top AUXILIARY MUST ( uidNumber $ gidNumber $ NFSv4Name ) MAY ( cn $ GSSAuthName $ description) ) The NFSv4Person object class can be added to the LDAP schema, and then used with or without the posixAccount object class. If the administrator wants the local or remote user to have local machine access, posixAccount attributes are used along with the NFSv4Name and GSSAuthName attributes. If only NFSv4 access is desired, the administrator does not use the posixAccount attributes, only the NFS4Person class is used. The following sections demonstrate the use of the NFSv4Name and GSSAuthName attributes. 5.1. Multiple NFSv4 Domain Translation Solution In this section the translation problems demonstrated in the federated name translation example (Section 4.1) are solved using the new LDAP attributes and classes. Bob and Alice have LDAP entries in the business.com NFSv4 Domain (Figure 2). To get access to files in the university.edu NFSv4 Domain, they need a uidNumber assigned in the university.edu NFSv4 Domain name service. The university.edu NFSv4 Domain administrators want to give alice@business.com and bob@business.com access to files in their domain, but they do not wish to give these new foreign users access to local machines. So they create new LDAP entries in the university.edu NFSv4 Domains LDAP name service without using the posixAccount object class. Adamson & Coffman Expires January 4, 2010 [Page 20] Internet-Draft NFSv4 Multi-Domain Access July 2009 Here is a typical LDAP name service entries using the NFSv4Person object class. # bob, People, university, edu dn: uid=bob,ou=People,dc=university,dc=edu objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: NFSv4Person cn: Bob B. Bar sn: Bar uidNumber: 5989 gidNumber: 100 displayName: Bob B. Bar NFSv4Name: bob@business.com GSSAuthName: bob@BUSINESS.REALM # alice, People, university, edu dn: uid=alice,ou=People,dc=university,dc=edu objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: NFSv4Person cn: Alice A. Answer sn: Answer uidNumber: 5990 gidNumber: 100 displayName: Alice A. Answer NFSv4Name: alice@business.com GSSAuthName: alice@BUSINESS.REALM Figure 9 The NFSv4Person objectClass is added to the university.edu NFSv4 Domain LDAP name service schema which allows the addition of the NFSv4Name and GSSAuthName attributes to name service entries for the fictional foreign users bob@business.com and alice@business.com. The uidNumber, gidNumber, NFSv4Name, and GSSAuthName attributes all come from the NFSv4Person objectClass. Note that since the posixAccount object class is not used for these users, there is no posixAccount uid attribute. The association of the GSSAuthName attribute and the uidNumber attribute in the Figure 9 LDAP entry for Bob Barr solves the translation problem in Step 2 and Step 3 (Section 4.1). Adamson & Coffman Expires January 4, 2010 [Page 21] Internet-Draft NFSv4 Multi-Domain Access July 2009 bob@BUSINESS.REALM -> uidNumber 5989 With the appropriate LDAP query, bob@BUSINESS.REALM can now be translated to the uidNumber 5989 in the university.edu NFSv4 Domain. The association of the NFSv4Name attribute and the uidNumber attribute in the Figure 9 LDAP entry for Alice Answer solves the translation problem in Step 5 (Section 4.1). alice@business.com -> uidNumber 5990 With the appropriate LDAP query, alice@business.com can now be translated to the uidNumber 5990 in the university.edu NFSv4 Domain. 5.2. Local NFSv4 Domain LDAP Attribute Use Adding the NFSv4Person objectClass to the LDAP schema also has uses in the translations within an NFSv4 Domain. The use of the GSSAuthName attribute lifts both the restriction of using the posixAccount uid for the Kerberos principal and the requirement of stripping the @REALM portion of the Kerberos principal. The use of the NFSv4Name attribute removes the need to strip or add the @dns_domain portion of NFSv4 ACL names as they can be directly mapped to uidNumbers on both the client and the server. Adamson & Coffman Expires January 4, 2010 [Page 22] Internet-Draft NFSv4 Multi-Domain Access July 2009 6. Summary The proposed LDAP attributes and object classes enable NFSv4 name and GSS principal translation and therefore NFSv4 federated file system access in the following ways. o For local users, the NFSv4Name attribute removes the need for pre and post translation processing of the posixAccount uid (login name). o For local users, the GSSAuthName attribute removes the need to synchronize a user's posixAccount uid with some portion of a GSS principal, as well as the pre and post translation processing. o For foreign users the NFSv4Name attribute enables translation of an NFSv4 ACL name to a local uidNumber. o For foreign users the GSSAuthName attribute enables translation of an GSS principal to a local uidNumber. o The NFSv4Person object class allows the NFSv4Name and GSSAuthName attributes to be associated with a user's LDAP entry posixAccount attribute set. o The NFSv4Person object class allows the NFSv4Name and GSSAuthName attributes to be associated with a user's LDAP entry uidNumber without enabling local machine access for that user. o For all users, the removal of the NFSv4Name attribute from an LDAP entry removes access to the NFSv4 Domain, and just from the NFSv4 Doamin. For users with a posixAccount, local machine access will not be affected. Adamson & Coffman Expires January 4, 2010 [Page 23] Internet-Draft NFSv4 Multi-Domain Access July 2009 7. Security Considerations None. Adamson & Coffman Expires January 4, 2010 [Page 24] Internet-Draft NFSv4 Multi-Domain Access July 2009 8. References [NFSv40] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003. [NFSv41] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (Work in Progress), December 2008. [FEDFS-PROT] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Naik, "NSDB Protocol for Federated Filesystems (Work in Progress)", February 2009. [FEDFS-REQTS] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Naik, "Requirements for Federated File Systems (Work in Progress)", April 2009. [LDAP] Wahl, M., Howes, T., Ellard, D., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307 (Experimental), March 1998. [RFC2743] Linn, J., "Generic Security Service Application Program Interface", Version 2 Update 1, RFC 2743, January 2000. [RFC1094] Nowicki, B., "NFS: Network File System Protocol Specification", RFC 1094, March 1989. [AFS_ACM] Morris, J., Satyanarayanan, M., Conner, M., Rosenthal, D., and F. Smith, "ANDREW: A Distributed Personal Computing Environment (# 4)", Communications of the ACM Vol. 29, No. 3, March 1986. [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997. [RFC1813] Callaghan, B., Pawlowski, P., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. Adamson & Coffman Expires January 4, 2010 [Page 25] Internet-Draft NFSv4 Multi-Domain Access July 2009 [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995. [NIS] Sun Microsystems, "System and Network Administration", March 1990. [AD-LDAP] Microsoft Corporation, "Active Directory LDAP Compliance", October 2003. [RFC2119] "Normative References", RFC 2119. Adamson & Coffman Expires January 4, 2010 [Page 26] Internet-Draft NFSv4 Multi-Domain Access July 2009 Authors' Addresses William A. (Andy) Adamson NetApp Email: andros@netapp.com Kevin Coffman CITI, University of Michigan Email: kwc@umich.edu Adamson & Coffman Expires January 4, 2010 [Page 27]