A Simpler Mechanism For Organizing FedFS NSDBs

A FedFS junction is an object stored on a fileserver that redirects file-access clients to other fileserver shares. Using junctions, multiple fileserver shares on many fileservers can be joined into a single filename namespace. Think of a junction as a symlink that points to the root directory of a share stored on another fileserver. The target locations of these remote shares are not stored in FedFS junctions. Instead, a junction contains a reference to a set of location information stored in an LDAP directory. The LDAP directory is referred to as a Name Space Data Base, or NSDB. The fundamental and most frequent operation performed with an NSDB is "FSN resolution," described in section 5.2.2 of . This is the act of reading the reference stored in a junction, retrieving the referenced location information from an NSDB, and forming a filesystem referral to send to file-access clients using a native filesystem protocol. In this scenario, a fileserver acts as an NSDB client. FedFS records in any NSDB are stored as descendants of an NSDB Container Entry, or NCE, for short. An NSDB client specifies a search base when forming an LDAP query to search an NSDB for FedFS records. The Distinguished Name of an NCE is that search base. FedFS junctions contain only the hostname and port of the NSDB service and a UUID. NSDB clients use a standard procedure for probing NSDBs for their NCEs. For the purposes of this discussion, we refer to procedures which retrieve putative NCEs from an NSDB as "NCE discovery mechanisms." Implementation experience has shown that the NCE discovery mechanism currently defined in sections 4.1 and 5.2.1 of can be problematic for some LDAP server implementations or deployments. In particular, altering the rootDSE of LDAP servers in any way is an onerous requirement. We present a new mechanism for expressing NCEs that does not require alteration of the rootDSE.

As described in Section 4.1 of , the LDAP naming context that is superior to an NCE is modified to include the fedfsNsdbContainerInfo object class. This object class carries the mandatory fedfsNceDN attribute, whose value is the Distinguished Name of the NCE that resides under that naming context. To discover all NCEs on an NSDB, NSDB clients use the procedure described in Section 5.2.1 of . NSDB clients look for naming context entries that include the fedfsNsdbContainerInfo object class. The fedfsNceDN attribute points directly to the NCE under that root suffix. Difficulty arises because there is often a high bar to altering an LDAP server's rootDSE. Because rootDSE's typically contain read-mostly or even read-only data, an LDAP server implementation may simulate its rootDSE, rather than storing it as regular LDAP records. Code changes would be necessary for such an LDAP server implementation to act as an NSDB. For security reasons, some LDAP server deployments may not wish to grant unauthenticated access to their rootDSE information. Typically, a separate NSDB administrator account is used to manage NSDB entries under an NCE, but LDAP server administrator privileges (essentially, a root password for the LDAP server) are required if an NCE needs to be added, moved, or deleted. Some LDAP server administrators may prefer using Access Control Lists (ACLs) to manage access to all FedFS record types, including NCEs. The schema specified in limits the number of NCEs per naming context to one. There does not appear to be any other architected limit in the NSDB protocol that requires a one-to-one relationship between naming context and NCE. Neither nor discuss the motivation for referring to an NCE record via the rootDSE. The use of the current NCE discovery mechanism is simply a convenience that enables the contents of junctions to exclude the LDAP search base when specifying the LDAP record containing the junction's target locations. Originally, an NSDB Container Entry DN was stored in each junction, along with an FSN UUID and the name of the NSDB where the FSN was stored. To simplify the contents of junctions, the NCE DN was removed from junctions as the design of the NSDB protocol was finalized. NSDB clients were tasked with discovering the correct LDAP search base to use by searching the target NSDB's rootDSE for the NCE DN. The current approach is described in Section 5.2.2 of : The NSDB client obtains a list of the target NSDB's naming contexts. The NSDB client obtains a list of NCEs that reside on the target NSDB by searching each of the NSDB's naming contexts for the fedfsNsdbContainerInfo object class. Finally, the NSDB client forms a series of LDAP queries using each NCE as the search base. The client supplies a filter to retrieve only objects in the fedfsFsl object class. The search stops when one or more FSLs are returned or when all NCEs have been searched. Without the fedfsNsdbContainerInfo object class, a root suffix DN is an adequate LDAP search base to use when searching for FSL records. For administrative purposes, however, the construct of NCE is maintained.

Rather than relying on a Distinguish Name stored in an attribute by an administrative tool, an NSDB client might instead use a search query that is natural to LDAP to obtain that DN. Currently an NSDB Container Entry record is entirely unremarkable, except for its position in the DIT. It includes no special object class, Distinguished Name, or attribute that defines it as an NCE. It becomes an NCE only because its parent naming context points to it via the context's fedfsNceDN attribute. If each NCE were instead tagged with an object class specific only to NCEs, NSDB clients could discover NCEs simply by filtering on that object class. Then no change to the LDAP server's rootDSE is required. The following sections provide a protocol specification, similar to , for the new NCE discovery mechanism.

An NSDB is constructed using an LDAP Directory. This LDAP Directory can have multiple naming contexts. The LDAP Directory's DSA-specific entry (its rootDSE) has a multi-valued namingContext attribute. Each value of the namingContext attribute is the DN of the naming context's root entry (see ). For each naming context that contains federation entries (e.g., FSNs and FSLs): Typically, all of a naming context's federation entries are descended from one LDAP entry in the Directory Information Tree (DIT). This entry is termed an NSDB Container Entry (NCE). NSDB clients filter with "(objectClass=fedfsNsdbContainerEntry)" to locate the naming context's NCEs. Therefore, every NCE MUST include fedfsNsdbContainerEntry as one of its object classes. NSDB clients search for FSNs with a scope ONE search, based on an NCE. Therefore, all FSN entries under the naming context MUST be immediate children of an NCE. NSDB clients search for FSLs with a scope ONE search, based on an FSN entry. Therefore, all FSL entries under the naming context MUST be immediate children of an FSN entry. An NCE may have no children. When an NSDB is first created, there are no federation entries aside from the NCE, which therefore has no federation-related descendents. NSDB administrative operations, such as those described in Section 5.1 of , may use NCEs to demark the position of repositories for federation entries. If a naming context does not host an NSDB DIT, it MUST NOT contain an entry that includes the fedfsNsdbContainerEntry object class. For example, an LDAP directory might have the following entries:

-+ [root DSE] | namingContext: o=fedfs | namingContext: dc=example,dc=com | namingContext: ou=system | | +---- [o=fedfs] | objectClass: fedfsNsdbContainerEntry | | +---- [dc=example,dc=com] | +-------- [ou=corp-it,dc=example,dc=com] | +------------ [ou=fedfs,ou=corp-it,dc=example,dc=com] | objectClass: fedfsNsdbContainerEntry | | +---- [ou=system] In this case, the o=fedfs naming context is also an NSDB Container Entry; the dc=example,dc=com naming context has an NSDB Container Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system naming context has no NSDB Container Entry. The NSDB SHOULD be configured with one or more privileged LDAP users. These users are able to modify the contents of the LDAP database. To perform the operations described in Section 5.1 of , a user SHOULD authenticate using the DN of a privileged LDAP user. It MUST be possible for an unprivileged (unauthenticated) user to perform LDAP queries that access NSDB data. A fileserver performs the operations described in Section 5.2 of as an unprivileged user. All NSDB implementations SHOULD use the same schema. At minimum, each MUST use a schema that includes all attributes and objects named in Section 4.2 of and in . If it is necessary for an implementation to privately extend the schema defined there, consider using one of the following ways: Define a fedfsAnnotation key and values (see Section 4.2.1.6 of ). Register the new key and values with IANA. Define additional attribute types and object classes, then have entries inherit from a class defined in Section 4.1 of and in , and from the implementation-defined ones.

This section is an addendum to the FedFS NSDB schema specified in Section 4.1 of . The fedfsNsdbContainerEntry object class signifies that an LDAP record acts as an NSDB Container Entry (NCE). A fedfsNsdbContainerEntry's has no mandatory attributes. A fedfsNsdbContainerEntry's fedfsAnnotation and fedfsDescr attributes are OPTIONAL. RFC Editor: please replace "a.b.c.d.e.f.g.h.i" with the object class's OID assigned by IANA as requested in "IANA Considerations". <CODE BEGINS>

/// /// objectclass ( /// a.b.c.d.e.f.g.h.i NAME 'fedfsNsdbContainerEntry' /// DESC 'Denotes an NSDB Container Entry' /// SUP top AUXILIARY /// MAY ( /// fedfsAnnotation /// $ fedfsDescr /// )) /// <CODE ENDS>

To find NCEs residing on the NSDB nsdb.example.com, an NSDB client SHOULD do the following: <CODE BEGINS>

nce_list = empty connect to the LDAP directory at nsdb.example.com for each namingContext value $BAR in the root DSE /* $BAR is a DN */ query for fedfsNsdbContainerEntry objects under $BAR include the DN of such objects on the nce_list <CODE ENDS> The LDAP URL for the search query inside the loop would be:

ldap://nsdb.example.com:389/$BAR??sub? (objectClass=fedfsNsdbContainerEntry)

NSDBs might serve NSDB client populations that contain clients that comply only with as well as clients that use the query described in . In this case, both the mechanism described in and the mechanism described in can be concurrently implemented in the NSDB to support both types of NSDB client. To remain compatible with NSDB clients that comply with , each naming context on such an NSDB MUST contain either zero or one NCE records.

During a transition period to the new NCE discovery mechanism, NSDB clients may have to resolve FSNs on NSDBs that comply with as well as NSDBs that have deployed the mechanism described in . In this case, an NSDB client can try the query described in first. If no NCE is found by this method, the NSDB client can try the query described in Section 5.2.1 of . An NSDB client that encounters more than one NCE record under a naming context MUST return FEDFS_ERR_NSDB_NONCE if it does not support multiple NCEs per naming context.

To maintain separation of privileges, privileged users that are permitted to perform NSDB administrative operations should not be permitted access to other areas of the LDAP server's DIT. The use of LDAP ACLs is recommended to permit unauthenticated access to FedFS records (FSNs, FSLs, and NCEs) while restricting the ability to change these records to one or a few privileged user accounts.

IANA is to update the registry entitled "FedFS Object Identifiers" for the purpose of recording the change in status of existing FedFS Object Identifiers (OIDs) mentioned by this document. This includes the fedfsNceDN entry (OID 1.3.6.1.4.1.31103.1.14) and the fedfsNsdbContainerInfo entry (OID 1.3.6.1.4.1.31103.1.1001). The designation of "historic" is to be added to the "Reference" column of both entries. In accordance with Section 5.2 of , object identifier descriptors for the fedfsNsdbContainerInfo object class and the fedfsNceDN attribute are to be marked as "historic in nature" in IANA's LDAP parameters "Object Identifier Descriptors" table, after Expert Review.

In accordance with Section 3.4 and Section 4 of , object identifier descriptors for the new fedfsNsdbContainerEntry object class defined in this document will be assigned and registered via the Expert Review process. RFC Editor: please replace "draft-cel-nfsv4-federated-fs-nce" with this specification's RFC number and title, and replace TBD with the newly assigned OID. Request for LDAP Descriptor Registration See "Author/Change Controller" draft-cel-nfsv4-federated-fs-nce IESG (iesg@ietf.org) TBD fedfsNsdbContainerEntry object class

The author of this document gratefully acknowledges the contributions and patience of Rob Thurlow, Tom Haynes, and David Noveck. This work would not have been possible without the efforts of the authors and contributors to .