Internet DRAFT - draft-adamson-nfsv4-multi-domain-access
draft-adamson-nfsv4-multi-domain-access
NFSv4 Working Group W. Adamson
Internet-Draft NetApp
Intended status: Standards Track K. Coffman
Expires: April 29, 2010 CITI, University of Michigan
N. Williams
Sun Microsystems
October 26, 2009
NFSv4 Multi-Domain Access
draft-adamson-nfsv4-multi-domain-access-02
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 April 29, 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, et al. Expires April 29, 2010 [Page 1]
Internet-Draft NFSv4 Multi-Domain Access October 2009
Abstract
The Network File System, version 4 (NFSv4) uses a representation of
identity that allows the use of users and groups from multiple,
distinct administrative domains, and NFSv4 allows the use of security
mechanisms that authenticate principals from multiple, distinct
administrative domains. This document describes methods by which
NFSv4 clients and servers can handle principals, users, groups from
multiple administrative domains.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
5. Local Representations of Global Identity . . . . . . . . . 9
5.1. Storing Name@Domainname . . . . . . . . . . . . . . . . . 9
5.2. Storing Remote-ID@Domainname . . . . . . . . . . . . . . . 9
5.2.1. Storing Remote-ID@Domain-ID . . . . . . . . . . . . . . . 9
5.2.2. ID Mapping . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Use of Name Services . . . . . . . . . . . . . . . . . . . 10
5.3.1. Using LDAP with RFC2307 Schema . . . . . . . . . . . . . . 10
5.3.2. Using Active Directory LDAP . . . . . . . . . . . . . . . 11
5.3.3. Resolving Domain Names to Domain IDs . . . . . . . . . . . 11
5.3.4. LDAP DIT Construction for a Federated Namespace . . . . . 11
6. GSS-API Principal-to-NFSv4 Authorization Context . . . . . 12
6.1. Using GSS-API Naming Extensions . . . . . . . . . . . . . 12
6.1.1. Using a PAC . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Mapping Principal Names to Usernames . . . . . . . . . . . 13
6.2.1. Using a Name Service to Map Principal Names to User
Accounts . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. User Group Membership Determination . . . . . . . . . . . 14
7. LDAP Schema Extensions for Multi-Domain NFSv4 . . . . . . 15
7.1. LDAP Attribute for Principal Name to Local ID
Translation . . . . . . . . . . . . . . . . . . . . . . . 15
8. Name Resolution . . . . . . . . . . . . . . . . . . . . . 16
8.1. Using LDAP Caching Proxies . . . . . . . . . . . . . . . . 16
8.2. LDAP Schema Extensions for ID Mapping . . . . . . . . . . 18
9. Multi-Domain Access Summary . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 23
Adamson, et al. Expires April 29, 2010 [Page 2]
Internet-Draft NFSv4 Multi-Domain Access October 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, et al. Expires April 29, 2010 [Page 3]
Internet-Draft NFSv4 Multi-Domain Access October 2009
2. Introduction
The NFS Version 4 [RFC3530] protocol enables the construction of a
distributed file system which can join NFSv4.0 or NFSv4.1
[I-D.ietf-nfsv4-minorversion1] servers from multiple administrative
domains, each potentially using separate name resolution services and
separate security services, into a common multi-domain name space.
NFSv4 deals with two kinds of identities: authentication identities
(referred to here as "principals") and authorization identities
("users" and "groups" of users). NFSv4 supports multiple
authentication methods, each authenticating an "initiator principal"
(typically representing a user) to an "acceptor principals" (always
corresponding to the server). NFSv4 does not prescribe how to
represent authorization identities on file systems. All file access
decisions constitute "authorization" and are made by servers using
information about client principals (such as username, group
memberships, and so on) and file metadata related to authorization,
such as a file's access control list (ACL).
Authentication in NFSv4 occurs at the the RPCSEC_GSS [RFC2203] layer
where GSS-API mechanisms [RFC2743] are used to authenticate users on
NFSv4 clients to NFSv4 servers, and to provide security services such
as confidentiality and integrity protection for the protocol's
messages. The NFSv4 protocol specifies no particular representation
for authentication identities as these are entirely mechanism-
specific
Authorization for file object access is done at the NFSv4 protocol
layer (i.e., above the RPCSEC_GSS layer), on the server side, based
on an authenticated client principal's authorization context and the
authorization meta-data of the file system objects that the client
wishes to access. File authorization meta-data is set and retrieved
in the NFSv4 RPC [RFC1831] layer, specifically via the object's
owner, owner_group and acl, dacl and sacl attributes (the last three
being ACLs). ACLs are lists of ACL entries (ACEs). Each ACE has a
"who" field identifying a subject to whom some permision is granted
or denied. The owner and owner_group attributes and the who ACE
field, all reference users and groups. On the wire, the protocol
represents users and groups as strings of characters with this form:
name@domain, where <name> is a user or group name, and <domain> is a
the name of an administrative domain, more specifically a DNS
[RFC1034] domainname.
NFSv4 server implementations usually do not, and really ought not,
store authorization identities on disk in the same form as is used on
the wire. The reason is that users' and groups' names change all too
often, while searching for and updating file authorization meta-data
Adamson, et al. Expires April 29, 2010 [Page 4]
Internet-Draft NFSv4 Multi-Domain Access October 2009
after a user/group name change is not trivial, particularly in a
global namespace spanning multiple administrative domains.
NFSv4 servers therefore must perform two kinds of mappings: a)
authentication identity to authorization context (a principal's user
ID, group memberships, etcetera), and on-the-wire authorization
identity representation to on-disk authorization identity
representation. Many aspects of these mappings are entirely
implementation-specific, but some require name resolution services,
and in order to interoperate servers must use such services in
compatible ways. Many implementations are limited to being able to
represent users and groups from a single domain.
In this document we address both of those kind of mappings,
describing possible implementation strategies, and specifying a name
service for interoperation in a global namespace
[I-D.ietf-nfsv4-federated-fs-reqts].
Adamson, et al. Expires April 29, 2010 [Page 5]
Internet-Draft NFSv4 Multi-Domain Access October 2009
3. Background
NFSv4 uses a syntax of the form "name@domain" to represent, on the
wire, the NFSv4 ACL name for users and groups. This design provides
a level of indirection that allows a client and server with different
internal representations of authorization identity to interoperate
even when referring to authorization identities from different
administrative domains.
Multi-domain capable sites need to meet certain requirements in order
to ensure that clients and servers can map name@domain to internal
representations reliably:
o name@domain MUST be unique within the DNS domain.
o Every local representation of a user and of a group MUST have a
canonical name@domain, and it must be possible to return the
canonical name@domain for any identity stored on disk, at least
when required infrastructure servers (such as name services) are
online.
As described in [I-D.ietf-nfsv4-minorversion1] section 2.2.1.1 "RPC
Security Flavors":
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_NONE security flavor can be useful to the multi-domain NFSv4
or federated name space to grant universal access to public data
without any credentials.
The AUTH_SYS security flavor uses a host-based authentication model
where the [weakly-authenticated] client asserts the user's
authorization identities using small integers as user and group
identity representations. Because of the small integer authorization
ID representation, AUTH_SYS can only be used in a name space where
all clients and servers share a uidNumber and gidNumber translation
service. A shared translation service is required because uidNumbers
and gidNumbers are passed in the RPC credential; there is no
negotiation of namespace in AUTH_SYS. Collisions can occur if
multiple translation services are used. These and other issues are
addressed in [I-D.williams-rpcsecgssv3] which describes a new version
of RPCSEC_GSS that includes a modernized replacement for AUTH_SYS.
Adamson, et al. Expires April 29, 2010 [Page 6]
Internet-Draft NFSv4 Multi-Domain Access October 2009
4. Terminology
Identity: a way to refer to a user or group.
Principal: an entity that is authenticated by RPCSEC_GSS (usually,
but not always, a user; rarely, if ever, a group; sometimes a
host).
Authorization context: the set of user and group IDs, privileges,
labels, and other items relevant to authorization, corresponding
to a subject (user or principal).
Domain-local ID: Most installations assign numeric, local
identifiers to users and groups, using a namespace local to their
domain. We call this a domain-local ID.
Local representation of identity: an item such as a POSIX user
IDentifier (UID) or group ID (GID), or a Windows Security
IDentifier (SID), or other such local representation of a user or
a group of users.
Global representation of identity: a tuple consisting of a domain
identifier (possibly the domain's name itself) and a domain-local
user/group ID. We do not propose a standard global representation
of identity, but the concept is useful.
Domain: a set of users and computers administered by a single
entity, and identified by a DNS domain name.
POSIX IDs: small non-negative integers (typically 0..2^31 or
0..2^32) identifiers. The namespace of user IDs (UIDs) is
distinct from the namespace of group IDs (GIDs).
Windows SIDs: an identifier of security entities, including users
and groups. The form of a SID is: S-1-
<authority><RID_0><RID_1><RID_n> By convention some authority
numbers denote security entities, identified by RID_n, local to a
domain identified by RIDs 0..n-1. Domain RIDs are usually
generated randomly within a "forest" of domains.
Name resolution: mapping from {domain, name} to {domain, ID}, and
vice-versa via lookups. Can be applied to local or remote
domains.
ID mapping: {domain-remote ID } to { domain-local ID } mappings.
Adamson, et al. Expires April 29, 2010 [Page 7]
Internet-Draft NFSv4 Multi-Domain Access October 2009
Logon service: { user ID } -> { groups user is a member of, and
other authorization context }
Adamson, et al. Expires April 29, 2010 [Page 8]
Internet-Draft NFSv4 Multi-Domain Access October 2009
5. Local Representations of Global Identity
Multi-domain support starts at the fileserver where local ID forms
need to be able to represent global identities from both, local and
remote domains. Local representation of global identity also applies
to clients, particularly clients with local filesystems. There's a
range of local solutions to this multi-domain ID representation
problem. In this section we describe several approaches to
representing a <name>@<local or remote domain> on disk. None of
these approaches are REQUIRED; all are INFORMATIVE. However,
conventions relating to the use of name services are NORMATIVE.
5.1. Storing Name@Domainname
One simple approach to the multiple domain problem is the identity
function applied to name@domain, with the resultant ID stored on
disk.
This approach imposes a severe constraint on the administrators of
these domains: user and group names must never be reused, as there is
also no realistic way to keep the name@domain on disk representation
up to date with user, group or domain renames and removals. Consider
a remote domain's NFSv4 servers where real-time employee join/leave
data may be (typically is!) considered privileged, and remote servers
may not be sufficiently privileged to access it [elaborate...].
5.2. Storing Remote-ID@Domainname
Most installations assign numeric, local identifiers to users and
groups, using a namespace local to their domain. We call this a
domain-local ID. We can then construct a global identity form
consisting of a domain ID and a domain-local user/group ID.
The user or group renaming issue can be addressed by using a global
identity form where domain-local IDs are required. I.e., use name
resolution to lookup name@domain to find the ID local to the domain,
and join the ID with the result of the identity function applied to
the domain. This function still has a renaming problem with respect
to DNS domain renames, but that is a realistically manageable
problem.
5.2.1. Storing Remote-ID@Domain-ID
The DNS domain renaming issue in the previous section can be
addressed by assigning and publishing a unique ID to each DNS domain.
I.e., use name resolution to lookup name@domain to find some ID local
to the domain, lookup the domain ID and store <remote-ID,domain-ID>.
Adamson, et al. Expires April 29, 2010 [Page 9]
Internet-Draft NFSv4 Multi-Domain Access October 2009
5.2.2. ID Mapping
Many file systems exported by NFS only store 32-bit user and group
IDs which limit their ability to utilize the on disk representation
described in Section 5.2. Such systems may need to use an additional
service to map between <remote users, local user IDs> and <remote
groups, local group IDs>. We call this an "ID mapping service".
The use of an ID mapping service is not strictly necessary if the
system operates on IDs large enough such that <user/group ID, domain
ID> can be encoded into a native ID. However, a large class of
operating systems, those which are Unix or Unix-like operating
systems, such as Solaris and Linux, use 32-bit UIDs and GIDs in many
services and therefore need mapping for backwards compatibility
reasons.
One example of such a service is to keep a local or distributed
database for dynamically assigning a local 32 bit ID to every <ID>@
<domain-ID>, or one could do that only for remote domains, reserving
only a small part of the local 32-bit ID namespace for remote
domains' users/groups.
The remote ID and remote domain are then used as inputs to a name
resolution service which contacts the remote domain name service to
resolve the remote name.
5.3. Use of Name Services
Such file systems often use a distributed directory service for
assigning domain local 32 bit IDs to remote users and groups. The
Network Information Service [NIS] and the Lightweight Directory
Access Protocol [RFC4511] are the two broadly used distributed
directory service protocols used for this purpose. LDAP is used
instead of NIS in environments where scale and security are issues.
Section 7 expands the LDAP protocol to include mappings between
name@domain and local user and group IDs.
Support for LDAP [RFC4511] with the RFC2307 schema [RFC2307] is
REQUIRED.
5.3.1. Using LDAP with RFC2307 Schema
Name resolution consists of searches with scope 'sub', a base DN
corresponding to a domain (more on this below) and a filter of either
of these forms, with matching on objectClass being optional:
Adamson, et al. Expires April 29, 2010 [Page 10]
Internet-Draft NFSv4 Multi-Domain Access October 2009
o ((objectClass=posixAccount)(uid="<username>))
o ((objectClass=posixGroup)(cn="<groupname>))
o ((objectClass=posixAccount)(uidNumber="<UID>))
o ((objectClass=posixGroup)(gidNumber="<GID>))
The base DN should be formatted from a domain's DNS domainname as
follows. First format the domainname as a string, then strip the
trailing dot ('.'), if any, then replace all dots ('.') with ",DC=",
then prepend "DC=" to the resulting string. For example,
foo.bar.example becomes "DC=foo,DC=bar,DC=example". This convention
is REQUIRED to be implemented. Domains with base DNs that do not
match this convention may be used, but their domainname-to-base-DN
mappings must be published where NFSv4 clients and servers may find
them; we provide no conventions for publishing such mappings.
Implementations MUST support the use of LDAP referrals to find LDAP
servers authoritative for any given base DN.
For example, to resolve a user named joe@foo.bar.example to a remote
ID a system would do an LDAP search with DC=foo,DC=bar,DC=example as
the base DN, scope='sub' and with a filter of
((objectClass=posixAccount)(uid="<username>)) looking for the
uidNumber attribute.
5.3.2. Using Active Directory LDAP
[Add text describing searches by which to resolve name@domain to SIDs
and vice versa.]
5.3.3. Resolving Domain Names to Domain IDs
[Add text on mapping domainnames to domain IDs.]
5.3.4. LDAP DIT Construction for a Federated Namespace
[Add text on federated namespace LDAP DIT construction, and caching
services.
Adamson, et al. Expires April 29, 2010 [Page 11]
Internet-Draft NFSv4 Multi-Domain Access October 2009
6. GSS-API Principal-to-NFSv4 Authorization Context
In order to authorize user access to files, the NFSv4 server must map
the RPCSEC_GSS client principal name or the underlying GSS-API
security context to local security information including a local ID,
a set of group IDs and other user privileges. This security
information is contained in an "authorization context" (also called
an "access token" in some systems).
Authorization contexts consist of:
1. UserID: This field contains the principal's global ID and/or
local ID mapping thereof, and the name@domain form thereof.
2. PrimarygroupID: This field contains the global ID and/or local ID
mapping thereof for the principal's primary group, and the
name@domain form thereof.
3. Groups: This field contains an array of group IDs for the groups
that the user is a member of, in global ID form and/or local ID
mappings thereof, as well as in name@domain name@domain forms.
4. As yet unspecified field(s) for privileges and authorizations
granted to the principal, if any.
5. As yet unspecified field(s) for other privilege information such
as the multi-level security label range/set of the principal.
6. Implementation-specific items relevant to authorization.
The RPCSEC_GSS client principal authorization context determination
may be mechanism-specific, and even operating system-specific, but
from the NFSv4 server's point of view, it is a generic facility.
Below we describe several methods of authorization context
determination.
The NFSv4 authorization context SHOULD be obtained via discrete GSS-
API name attributes [I-D.ietf-kitten-gssapi-naming-exts]
corresponding to the above elements of authorization contexts. URIs
for those attributes are TBD. If the named attribute interface is
not available, or the attributes are not available, other means of
determining a principal's authorization context SHOULD be used, such
as those described in Section 6.1 and Section 6.2.
6.1. Using GSS-API Naming Extensions
Authorization context information can sometimes be obtained from the
credentials authenticating a principal; the GSS-API represents such
Adamson, et al. Expires April 29, 2010 [Page 12]
Internet-Draft NFSv4 Multi-Domain Access October 2009
information as attributes of the initiator prinicpal's name. For
example: Kerberos 5 [RFC4120] has a method for conveying
"authorization data", both client-asserted as well as KDC-
authenticated authorization data, and one KDC implementation uses
this feature to convey a "privilege attribute certificate" (PAC)
listing the principal's user and group "security identifiers" (SIDs).
PKIX [RFC5280] certificates allow for extensions that could be used
similarly.
6.1.1. Using a PAC
The Windows operating system uses something called a "PAC", which
contains a user Security IDentifier (SID) and a list of group SIDs.
Some Kerberos Key Distribution Centers (KDCs), notably Windows KDCs,
issue Kerberos Tickets with PACs as Kerberos authorization data.
When a client principal is authenticated using such a ticket, the
server SHOULD extract the PAC from the client's ticket and map, if
need be, the SIDs in the PAC to local ID representations.
The authorization context information in a PAC can be considered a
single, authenticated, discrete GSS-API name attribute, in which case
the server must parse it into its individual elements.
[Add references.]
6.2. Mapping Principal Names to Usernames
If suitable and sufficient authenticated name attributes for the
client principal are not available, then the server may try to map
the client principal name to a local notion of user account, and then
lookup that user account's authorization context information through
name service lookups.
One simple method for Kerberos principal-to-username mapping is to
first apply an algorithmic or table-based Kerberos client principal
realm name to domain name mapping, then a client principal name to
username mapping. Finally, the server can look up the user's
authorization context using the user's domain's name services.
A trivial Kerberos realm-name-to-domainname mapping consists of case-
folding the realm name to lower-case. [Add notes about
internationalization.] Servers MUST implement this mapping as an
option, possibly as a default option.
A trivial Kerberos principal name to username mapping for 1-component
principal names, is the identity function. Servers MUST implement
this mapping as an option, possibly as a default option.
Adamson, et al. Expires April 29, 2010 [Page 13]
Internet-Draft NFSv4 Multi-Domain Access October 2009
6.2.1. Using a Name Service to Map Principal Names to User Accounts
Name services such as the Solaris gsscred database where the local
identity is looked up in a database keyed by the GSS exported name
token, or LDAP with the extension described in Section 7.1, can be
used to map principal names to user accounts.
6.3. User Group Membership Determination
User group membership is easy to determine for users in a system's
local domain: the operating system will already know how to do that.
User group membership in remote domain's groups, or for remote users,
may be determined using LDAP with the RFC2307 schema. The RFC2307
schema does not define the values of the 'memberUid' attribute, but
in practice it seems that those are expected to be the names of users
as found in the 'uid' attribute of 'posixAccount' entries. There is
work in progress to update RFC2307 [I-D.howard-rfc2307bis] to allow
the use of DNs in the memberUid attribute, as well as group nesting.
Such use of memberUid should be backwards-compatible, since
implementations that don't know about that use of memberUid will end
up ignoring values which are not plain usernames.
Assuming the ability to store DNs in the memberUid attribute, then,
group membership determination can be done as follows. Given a user
ID whose DN has been resolved:
1. Search the user's domain for groups that the user is a member of
in the user's home domain. Filter out groups that are not local
to the user's home domain.
2. Search the server's domain for groups that the user is a member
of in the server's home domain.
3. Search the server's domain for groups that the user's group
memberships determined in step 1 are members of.
4. Continue searching for nested group memberships given the list of
groups from steps 2 and 3.
However, the above procedure has the same user/group name renaming
issue. By skipping step 2 we can get down to just a group renaming
issue. To fully address the rename issue we need either a new
attribute or value type for memberUid, storing user/group IDs in some
global ID representation.
[Add text defining such a new attribute/value type.]
Adamson, et al. Expires April 29, 2010 [Page 14]
Internet-Draft NFSv4 Multi-Domain Access October 2009
7. LDAP Schema Extensions for Multi-Domain NFSv4
7.1. LDAP Attribute for Principal Name to Local ID Translation
The gSSPrincipal objectclass allows for the use of the gSSAuthName
attribute described in the following section.
objectclass ( 1.3.6.1.4.1.250.10.7
NAME 'gSSPrincipal'
DESC 'GSS Principal Name'
SUP posixAccount
MAY ( gSSAuthName ) )
Here we present a new LDAP attribute that provides a method for the
translations between a local ID and (multiple) GSS-API security
principals, used as described in Section 6.2.
The gSSAuthName attribute stores a user's GSS-API principal name in
exported name token form (see [RFC2743]).
attributetype ( 1.3.6.1.4.1.250.10.6
NAME ( 'gSSAuthName')
DESC 'GSS-API exported principal name
exported token'
EQUALITY bitStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6)
Adamson, et al. Expires April 29, 2010 [Page 15]
Internet-Draft NFSv4 Multi-Domain Access October 2009
8. Name Resolution
As noted in Section 5.2.1, most local representations require a name
service to perform ID to name translations. Implementations are
REQUIRED to support the use of LDAP as a name service, relying on
LDAP referrals for federated namespace construction.
Note that in a topographically widely separated set of domains the
need to do name service lookups in various domains' name services may
prove brittle, resulting in non-deterministic server behavior (e.g.,
sometimes a user can access share, sometimes they cannot; sometimes
they appear to be members of some group, sometimes they do not). To
avoid this, site administrators may wish to maintain local caches of
remote domains' name services such that LDAP searches for users/
groups in remote domains can be satisfied locally for some set of key
attributes (such as naming and ID attributes), with referrals used in
all other cases.
Domains in a federated namespace may provide each other with LDAP
LDIF delta feeds by which to maintain cached LDAP contents up to
date.
8.1. Using LDAP Caching Proxies
Many sites use a distributed name service such as Lightweight
Directory Access Protocol [RFC4511] for distributing system
configuration data and providing name translation. 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 LDAP posixAccount schema can be used to map between the multiple
domain local ID and the NFSv4 name@domain form by adding remote
domain DN hierarchies to the local LDAP name service.
An LDAP service set up in this way is a caching proxy because it
caches remote domain information. The DN hierarchy structure has the
advantage of aiding delta feeds from remote domains because each
domain's information is in it's own DN subtree.
An example follows that shows the DN hierarchy for sample.com's LDAP
service.
Adamson, et al. Expires April 29, 2010 [Page 16]
Internet-Draft NFSv4 Multi-Domain Access October 2009
dc=com/
dc=sample/
ou=People/
[all the rfc2307 people entries for
sample.com]
uid=bob
dc=edu/
dc=university/
ou=People/
[all the rfc2307 people entries for the
remote domain university.edu]
uid=alice
An LDAP hierarchy for two domains, the local sample.com domain and
the remote university.edu domain.
Figure 1
Adamson, et al. Expires April 29, 2010 [Page 17]
Internet-Draft NFSv4 Multi-Domain Access October 2009
More detail on two entries from sample.com's LDAP service:
dn: uid=bob,ou=People,dc=sample,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: gSSPrincipal
cn: Bob B. Bar
sn: Bar
uidNumber: 5989
gidNumber: 100
gSSAuthName: <bob@SAMPLE.COM>
gSSAuthName: <bob@SAMPLE-ENG.COM>
dn: uid=alice,ou=People,dc=university,dc=edu
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: gSSPrincipal
cn: Alice A. Answer
sn: Answer
uidNumber: 5990
gidNumber: 100
remoteID: 1234
gSSAuthName: <alice@UNIVERSITY.EDU>
Figure 2
Figure 2 shows two entries in the sample.com LDAP service also shown
in Figure 1. One entry is for a local user Bob and one entry for a
remote user alice. The mappings of the local uidNumber to an NFSv4
name@domain are also shown where the NFSv4 name@domain is expressed
as a concatenation of the posixAccount uid attribute and the DN
domain.
Figure 2 also demonstrates the use of the gSSAuthName and remoteID
attributes. User bob@sample.com has a principal in both the
SAMPLE.COM and the SAMPLE_ENG.COM Kerberos realms, and both map to
his uidNumber. User alice@university.edu has a principal in the
UNIVERSITY.EDU Kerberos realm, and a remoteID of 1234 which is her
uidNumber in the university.edu name service.
8.2. LDAP Schema Extensions for ID Mapping
[Add text.]
Adamson, et al. Expires April 29, 2010 [Page 18]
Internet-Draft NFSv4 Multi-Domain Access October 2009
9. Multi-Domain Access Summary
File systems exported by the NFSv4 file server need to be able to
represent user and group IDs from multiple domains.
The RPCSEC_GSS client presents the GSS principal to the NFSv4 server
which maps the GSS principal into the principal's authorization
context via methods described in Section 6. The authorization
context information is used to determine file access. Depending on
the local representation as described in Section 5, ID mapping and/or
name resolution may be required to translate between IDs and names
contained in the authorization context.
An NFSv4 SETATTR or GETATTR with an acl attribute presented to the
NFSv4 server may also require ID mapping and/or name resolution to
translate between the name@domain and the local file system ID.
Adamson, et al. Expires April 29, 2010 [Page 19]
Internet-Draft NFSv4 Multi-Domain Access October 2009
10. Security Considerations
Yet to be determined
Adamson, et al. Expires April 29, 2010 [Page 20]
Internet-Draft NFSv4 Multi-Domain Access October 2009
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC3530] 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.
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network
Information Service", RFC 2307, March 1998.
[I-D.howard-rfc2307bis]
Howard, L. and H. Chu, "An Approach for Using LDAP as a
Network Information Service", draft-howard-rfc2307bis-02
(work in progress), August 2009.
[I-D.ietf-nfsv4-federated-fs-reqts]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems",
draft-ietf-nfsv4-federated-fs-reqts-06 (work in progress),
October 2009.
[I-D.ietf-kitten-gssapi-naming-exts]
Williams, N. and L. Johansson, "GSS-API Naming
Extensions", draft-ietf-kitten-gssapi-naming-exts-05 (work
in progress), July 2009.
Adamson, et al. Expires April 29, 2010 [Page 21]
Internet-Draft NFSv4 Multi-Domain Access October 2009
[I-D.ietf-nfsv4-minorversion1]
Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4
Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work
in progress), December 2008.
11.2. Informative References
[I-D.williams-rpcsecgssv3]
Williams, N., "Remote Procedure Call (RPC) Security
Version 3", draft-williams-rpcsecgssv3-00 (work in
progress), January 2009.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[NIS] Sun Microsystems, "System and Network Administration",
March 1990.
Adamson, et al. Expires April 29, 2010 [Page 22]
Internet-Draft NFSv4 Multi-Domain Access October 2009
Authors' Addresses
William A. (Andy) Adamson
NetApp
Email: andros@netapp.com
Kevin Coffman
CITI, University of Michigan
Email: kwc@umich.edu
Nicolas Williams
Sun Microsystems
Email: Nicolas.Williams@sun.com
Adamson, et al. Expires April 29, 2010 [Page 23]
