From c73efa3d57fbe4590d38e064205ef1503e1b5983 Mon Sep 17 00:00:00 2001 From: Howard Chu Date: Mon, 10 Aug 2009 02:06:46 +0000 Subject: [PATCH] Revision 01 (expired) --- doc/drafts/draft-howard-rfc2307bis-xx.txt | 1344 +++++++++++++++++++++ 1 file changed, 1344 insertions(+) create mode 100644 doc/drafts/draft-howard-rfc2307bis-xx.txt diff --git a/doc/drafts/draft-howard-rfc2307bis-xx.txt b/doc/drafts/draft-howard-rfc2307bis-xx.txt new file mode 100644 index 0000000000..74ebd78552 --- /dev/null +++ b/doc/drafts/draft-howard-rfc2307bis-xx.txt @@ -0,0 +1,1344 @@ + + +Application Working Group L. Howard +INTERNET-DRAFT PADL Software +Expires in six months M. Ansari + Infoblox + + 20 February 2005 +Intended Category: Informational +Obsoletes: RFC 2307 + + + + + An Approach for Using LDAP as a Network Information Service + + + +Status of this Memo + + This document is intended to be, after appropriate review and revi- + sion, submitted to the RFC Editor for publication as an Experimen- + tal document. Distribution of this memo is unlimited. Technical + discussion of this document will take place on the IETF LDAP Exten- + sions mailing list . Please send editorial com- + ments directly to the author . + + By submitting this Internet-Draft, I accept the provisions of Sec- + tion 4 of RFC 3667. By submitting this Internet-Draft, I certify + that any applicable patent or other IPR claims of which I am aware + have been disclosed, or will be disclosed, and any of which I + become aware will be disclosed, in accordance with RFC 3668. + + 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 docu- + ments 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/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + + +Howard [Page 1] + +Internet Draft NIS X.500 schema February 2005 + + + Copyright (C) The Internet Society (2005). All Rights Reserved. + + Please see the Full Copyright section near the end of this document + for more information. + + +Abstract + + This document describes a mechanism for mapping entities related to + TCP/IP and the UNIX system into X.500 [X500] entries so that they + may be resolved with the Lightweight Directory Access Protocol + [RFC2251]. A set of attribute types and object classes are pro- + posed, along with specific guidelines for interpreting them. + + The intention is to assist the deployment of LDAP as an organiza- + tional nameservice. No proposed solutions are intended as standards + for the Internet. Rather, it is hoped that a general consensus + will emerge as to the appropriate solution to such problems, lead- + ing eventually to the adoption of standards. The proposed mechanism + has already been implemented with some success. + + +1. Background and Motivation + + The UNIX (R) operating system, and its derivatives (specifically, + those which support TCP/IP and conform to the X/Open Single UNIX + specification [XOPEN]) require a means of looking up entities, by + matching them against search criteria or by enumeration. (Other + operating systems that support TCP/IP may provide some means of + resolving some of these entities. This schema is applicable to + those environments also.) + + These entities include users, groups, IP services (which map names + to IP ports and protocols, and vice versa), IP protocols (which map + names to IP protocol numbers and vice versa), RPCs (which map names + to ONC Remote Procedure Call [RFC1057] numbers and vice versa), NIS + netgroups, booting information (boot parameters and MAC address + mappings), filesystem mounts, IP hosts and networks. + + Resolution requests are made through a set of C functions, provided + in the UNIX system's C library. For example, the UNIX system util- + ity "ls", which enumerates the contents of a filesystem directory, + uses the C library function getpwuid() in order to map user IDs to + login names. Once the request is made, it is resolved using a + "nameservice" which is supported by the client library. The name- + service may be, at its simplest, a collection of files in the local + filesystem which are opened and searched by the C library. Other + common nameservices include the Network Information Service (NIS) + + + +Howard [Page 2] + +Internet Draft NIS X.500 schema February 2005 + + + and the Domain Name System (DNS). (The latter is typically used for + resolving hosts, services and networks.) Both these nameservices + have the advantage of being distributed and thus permitting a com- + mon set of entities to be shared amongst many clients. + + LDAP is a distributed, hierarchical directory service access proto- + col which is used to access repositories of users and other net- + work-related entities. Because LDAP is often not tightly integrated + with the host operating system, information such as users may need + to be kept both in LDAP and in an operating system supported name- + service such as NIS. By using LDAP as the the primary means of + resolving these entities, these redundancy issues are minimized and + the scalability of LDAP can be exploited. (By comparison, NIS ser- + vices based on flat files do not have the scalability or extensi- + bility of LDAP or X.500.) + + The object classes and attributes defined below are suitable for + representing the aforementioned entities in a form compatible with + LDAP and X.500 directory services. + + +2. General Issues + +2.1 Terminology + + The key words "MUST", "SHOULD", and "MAY" used in this document are + to be interpreted as described in [RFC2119]. + + For the purposes of this document, the term "nameservice" refers to + a service, such as NIS or flat files, that is used by the operating + system to resolve entities within a single, local naming context. + Contrast this with a "directory service" such as LDAP, which sup- + ports extensible schema and multiple naming contexts. + + The term "NIS-related entities" broadly refers to entities which + are typically resolved using the Network Information Service. (NIS + was previously known as YP.) Deploying LDAP for resolving these + entities does not imply that NIS be used, as a gateway or other- + wise. In particular, the host and network classes are generically + applicable, and may be implemented on any system that wishes to use + LDAP or X.500 for host and network resolution. + + The "DUA" (directory user agent) refers to the LDAP client querying + these entities, such as an LDAP to NIS gateway or the C library. + The "client" refers to the application which ultimately makes use + of the information returned by the resolution. It is irrelevant + whether the DUA and the client reside within the same address + space. The act of the DUA making this information to the client is + + + +Howard [Page 3] + +Internet Draft NIS X.500 schema February 2005 + + + termed "republishing". + + To avoid confusion, the term "login name" refers to the user's + login name (being the value of the uid attribute) and the term + "user ID" refers to he user's integer identification number (being + the value of the uidNumber attribute). + + The phrases "resolving an entity" and "resolution of entities" + refer respectively to enumerating NIS-related entities of a given + type, and matching them against a given search criterion. One or + more entities are returned as a result of successful "resolutions" + (a "match" operation will only return one entity). + + The use of the term UNIX does not confer upon this schema the + endorsement of owners of the UNIX trademark. Where necessary, the + term "TCP/IP entity" is used to refer to protocols, services, + hosts, and networks, and the term "UNIX entity" to its complement. + (The former category does not mandate the host operating system + supporting the interfaces required for resolving UNIX entities.) + + The OIDs defined below are derived from iso(1) org(3) dod(6) inter- + net(1) directory(1) nisSchema(1). + +2.2 Attributes + + The attributes and classes defined in this document are summarized + below. + + The following attributes are defined in this document: + + uidNumber + gidNumber + gecos + homeDirectory + loginShell + shadowLastChange + shadowMin + shadowMax + shadowWarning + shadowInactive + shadowExpire + shadowFlag + memberUid + memberNisNetgroup + nisNetgroupTriple + ipServicePort + ipServiceProtocol + ipProtocolNumber + + + +Howard [Page 4] + +Internet Draft NIS X.500 schema February 2005 + + + oncRpcNumber + ipHostNumber + ipNetworkNumber + ipNetmaskNumber + macAddress + bootParameter + bootFile + nisMapName + nisMapEntry + nisPublicKey + nisSecretKey + nisDomain + automountMapName + automountKey + automountInformation + + Additionally, some of the attributes defined in [RFC2256] and + [RFC3112] are required. + +2.3 Object classes + + The following object classes are defined in this document: + + posixAccount + shadowAccount + posixGroup + ipService + ipProtocol + oncRpc + ipHost + ipNetwork + nisNetgroup + nisMap + nisObject + ieee802Device + bootableDevice + nisKeyObject + nisDomainObject + automountMap + automount + + Additionally, some of the classes defined in [RFC2256] are + required. + + +3. Attribute definitions + + This section contains attribute definitions to be implemented by + + + +Howard [Page 5] + +Internet Draft NIS X.500 schema February 2005 + + + DUAs supporting this schema. + + ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' + DESC 'An integer uniquely identifying a user in an + administrative domain' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' + DESC 'An integer uniquely identifying a group in an + administrative domain' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.2 NAME 'gecos' + DESC 'The GECOS field; the common name' + EQUALITY caseIgnoreMatch + SUBSTRINGS caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' + DESC 'The absolute path to the home directory' + EQUALITY caseExactIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.4 NAME 'loginShell' + DESC 'The path to the login shell' + EQUALITY caseExactIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.6 NAME 'shadowMin' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.7 NAME 'shadowMax' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + + + +Howard [Page 6] + +Internet Draft NIS X.500 schema February 2005 + + + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.8 NAME 'shadowWarning' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.9 NAME 'shadowInactive' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.10 NAME 'shadowExpire' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.11 NAME 'shadowFlag' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.12 NAME 'memberUid' + EQUALITY caseExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + ( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup' + EQUALITY caseExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' + DESC 'Netgroup triple' + EQUALITY caseIgnoreMatch + SUBSTRINGS caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + ( 1.3.6.1.1.1.1.15 NAME 'ipServicePort' + DESC 'Service port number' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.16 NAME 'ipServiceProtocol' + DESC 'Service protocol name' + EQUALITY caseIgnoreMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + ( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber' + + + +Howard [Page 7] + +Internet Draft NIS X.500 schema February 2005 + + + DESC 'IP protocol number' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.18 NAME 'oncRpcNumber' + DESC 'ONC RPC number' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.19 NAME 'ipHostNumber' + DESC 'IPv4 addresses as a dotted decimal omitting leading + zeros or IPv6 addresses as defined in RFC2373' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + ( 1.3.6.1.1.1.1.20 NAME 'ipNetworkNumber' + DESC 'IP network omitting leading zeros, eg. 192.168' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.21 NAME 'ipNetmaskNumber' + DESC 'IP netmask omitting leading zeros, eg. 255.255.255.0' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.22 NAME 'macAddress' + DESC 'MAC address in maximal, colon separated hex + notation, eg. 00:00:92:90:ee:e2' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + ( 1.3.6.1.1.1.1.23 NAME 'bootParameter' + DESC 'rpc.bootparamd parameter' + EQUALITY caseExactIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + ( 1.3.6.1.1.1.1.24 NAME 'bootFile' + DESC 'Boot image name' + EQUALITY caseExactIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + ( 1.3.6.1.1.1.1.26 NAME 'nisMapName' + DESC 'Name of a generic NIS map' + EQUALITY caseIgnoreMatch + + + +Howard [Page 8] + +Internet Draft NIS X.500 schema February 2005 + + + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} ) + + ( 1.3.6.1.1.1.1.27 NAME 'nisMapEntry' + DESC 'A generic NIS entry' + EQUALITY caseExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.28 NAME 'nisPublicKey' + DESC 'NIS public key' + EQUALITY octetStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.29 NAME 'nisSecretKey' + DESC 'NIS secret key' + EQUALITY octetStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.30 NAME 'nisDomain' + DESC 'NIS domain' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) + + ( 1.3.6.1.1.1.1.31 NAME 'automountMapName' + DESC 'automount Map Name' + EQUALITY caseExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.32 NAME 'automountKey' + DESC 'Automount Key value' + EQUALITY caseExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE ) + + ( 1.3.6.1.1.1.1.33 NAME 'automountInformation' + DESC 'Automount information' + EQUALITY caseExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE ) + + +4. Class definitions + + This section contains class definitions to be implemented by DUAs + supporting the schema. + + + +Howard [Page 9] + +Internet Draft NIS X.500 schema February 2005 + + + Various schema for mail routing and delivery using LDAP directories + have been proposed, and as such this document does not consider + schema for representing mail aliases or distribution lists. + + + ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY + DESC 'Abstraction of an account with POSIX attributes' + MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) + MAY ( authPassword $ userPassword $ loginShell $ gecos $ + description ) ) + + ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' SUP top AUXILIARY + DESC 'Additional attributes for shadow passwords' + MUST uid + MAY ( authPassword $ userPassword $ description $ + shadowLastChange $ shadowMin $ shadowMax $ + shadowWarning $ shadowInactive $ + shadowExpire $ shadowFlag ) ) + + ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top AUXILIARY + DESC 'Abstraction of a group of accounts' + MUST gidNumber + MAY ( authPassword $ userPassword $ memberUid $ + description ) ) + + ( 1.3.6.1.1.1.2.3 NAME 'ipService' SUP top STRUCTURAL + DESC 'Abstraction an Internet Protocol service. + Maps an IP port and protocol (such as tcp or udp) + to one or more names; the distinguished value of + the cn attribute denotes the service's canonical + name' + MUST ( cn $ ipServicePort $ ipServiceProtocol ) + MAY description ) + + ( 1.3.6.1.1.1.2.4 NAME 'ipProtocol' SUP top STRUCTURAL + DESC 'Abstraction of an IP protocol. Maps a protocol number + to one or more names. The distinguished value of the cn + attribute denotes the protocol canonical name' + MUST ( cn $ ipProtocolNumber ) + MAY description ) + + ( 1.3.6.1.1.1.2.5 NAME 'oncRpc' SUP top STRUCTURAL + DESC 'Abstraction of an Open Network Computing (ONC) + [RFC1057] Remote Procedure Call (RPC) binding. + This class maps an ONC RPC number to a name. + The distinguished value of the cn attribute denotes + the RPC service canonical name' + MUST ( cn $ oncRpcNumber ) + + + +Howard [Page 10] + +Internet Draft NIS X.500 schema February 2005 + + + MAY description ) + + ( 1.3.6.1.1.1.2.6 NAME 'ipHost' SUP top AUXILIARY + DESC 'Abstraction of a host, an IP device. The distinguished + value of the cn attribute denotes the host's canonical + name. Device SHOULD be used as a structural class' + MUST ( cn $ ipHostNumber ) + MAY ( authPassword $ userPassword $ l $ description $ manager ) ) + + ( 1.3.6.1.1.1.2.7 NAME 'ipNetwork' SUP top STRUCTURAL + DESC 'Abstraction of a network. The distinguished value of + the cn attribute denotes the network canonical name' + MUST ipNetworkNumber + MAY ( cn $ ipNetmaskNumber $ l $ description $ manager ) ) + + ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL + DESC 'Abstraction of a netgroup. May refer to other netgroups' + MUST cn + MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) + + ( 1.3.6.1.1.1.2.9 NAME 'nisMap' SUP top STRUCTURAL + DESC 'A generic abstraction of a NIS map' + MUST nisMapName + MAY description ) + + ( 1.3.6.1.1.1.2.10 NAME 'nisObject' SUP top STRUCTURAL + DESC 'An entry in a NIS map' + MUST ( cn $ nisMapEntry $ nisMapName ) + MAY description ) + + ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' SUP top AUXILIARY + DESC 'A device with a MAC address; device SHOULD be + used as a structural class' + MAY macAddress ) + + ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice' SUP top AUXILIARY + DESC 'A device with boot parameters; device SHOULD be + used as a structural class' + MAY ( bootFile $ bootParameter ) ) + + ( 1.3.6.1.1.1.2.14 NAME 'nisKeyObject' SUP top AUXILIARY + DESC 'An object with a public and secret key' + MUST ( cn $ nisPublicKey $ nisSecretKey ) + MAY ( uidNumber $ description ) ) + + ( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top AUXILIARY + DESC 'Associates a NIS domain with a naming context' + MUST nisDomain ) + + + +Howard [Page 11] + +Internet Draft NIS X.500 schema February 2005 + + + ( 1.3.6.1.1.1.2.16 NAME 'automountMap' SUP top STRUCTURAL + MUST ( automountMapName ) + MAY description ) + + ( 1.3.6.1.1.1.2.17 NAME 'automount' SUP top STRUCTURAL + DESC 'Automount information' + MUST ( automountKey $ automountInformation ) + MAY description ) + + +5. Implementation details + +5.1 Suggested resolution methods + + The preferred means of directing a client application (one using + the shared services of the C library) to use LDAP as its informa- + tion source for the functions listed in Appendix B is to modify the + source code to directly query LDAP. As the source to commercial C + libraries and applications is rarely available to the end-user, one + could emulate a supported nameservice (such as NIS). (This is also + an appropriate opportunity to perform caching of entries across + process address spaces.) In the case of NIS, reference implementa- + tions are widely available and the RPC interface is well known. + + The means by which the operating system is directed to use LDAP is + implementation dependent. For example, some operating systems and C + libraries support end-user extensible resolvers using dynamically + loadable libraries and a nameservice "switch". The means in which + the DUA locates LDAP servers is also implementation dependent. + +5.2 Interpreting user and group entries + + User and group resolution is initiated by the functions prefixed by + getpw and getgr respectively. The uid attribute contains the user's + login name. The cn attribute, in posixGroup entries, contains the + group's name. This document preserves the use of the uid attribute + even though, being a naming attribute, its syntax is case insensi- + tive. This may cause a problem with existing deployments where + there exist login names differing only in case. If DUAs support + attribute mapping, a different attribute may be used to represent + users' login names. + + The account object class provides a convenient structural class for + posixAccount, and SHOULD be used where additional attributes are + not required. For groups with one of more distinguished names, the + groupOfUniqueNames object class MUST be used as a structural object + class. For groups whose members are only login names, the namedOb- + ject [namedObject] object class MAY be used as a structural object + + + +Howard [Page 12] + +Internet Draft NIS X.500 schema February 2005 + + + class. + + It is suggested that uid and cn are used as the naming attribute + for posixAccount and posixGroup entries, respectively. Group mem- + bers may either be login names (values of memberUid) or distin- + guished names (values of uniqueMember). In the latter case, the + distinguished name must be mapped to one or more login names by + examining the name's RDN or, if it is not distinguished by uid, + performing a base search on the DN with a filter of "(object- + class=*)". DUAs may wish to cache DN to login name mappings. The + DUA MAY traverse nested groups. + + An account's GECOS field is preferably determined by a value of the + gecos attribute. If no gecos attribute exists, the value of the cn + attribute MUST be used. (The existence of the gecos attribute + allows information embedded in the GECOS field, such as a user's + telephone number, to be returned to the client without overloading + the cn attribute. It also accommodates directories where the common + name does not contain the user's full name.) + + An entry of class posixAccount, posixGroup, or shadowAccount with- + out an authPassword or userPassword attribute MUST NOT be used for + authentication. In this case the client SHOULD be returned a non- + matchable password such as "x". + + If userPassword is used, its values MUST be represented by follow- + ing syntax: + + passwordvalue = schemeprefix encryptedpasswd + schemeprefix = "{" scheme "}" + scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme + altscheme = "x-" keystring + encryptedpasswd = encrypted password + + + The encrypted password contains of a plaintext key hashed using the + algorithm scheme. If the schema is "sha", the encrypted password + is the base64 encoding of the SHA-1 digest of the plaintext pass- + word. + + userPassword values which do not adhere to this syntax MUST NOT be + used for authentication. The DUA MUST iterate through the values of + the attribute until a value matching the above syntax is found. + Only if encryptedpassword is an empty string does the user have no + password. DUAs are not required to consider encryption schemes + which the client will not recognize; in most cases, it may be suf- + ficient to consider only "crypt". + + + + +Howard [Page 13] + +Internet Draft NIS X.500 schema February 2005 + + + DUA MAY use the authPassword attribute instead of userPassword, + defined in [RFC3112]. The DUA MUST iterate the values of the auth- + Password attribute until a value whose scheme is CRYPT is found. + The DUA MAY iterate through the values of the userPassword + attribute, using the syntax defined in RFC 2307, until a value + whose scheme is CRYPT is found. If no conforming value is found, + the client MUST be returned a non-matchable password such as "x". + Authentication using schemes other than CRYPT is, although advis- + able, beyond the scope of this document. + + Below is an example of an authPassword attribute: + + authPassword: CRYPT$X5/DBrWPOQQaI + + + Below is an example of a (deprecated) userPassword attribute: + + userPassword: {CRYPT}X5/DBrWPOQQaI + + + A DUA MAY utilize the attributes in the shadowAccount class to pro- + vide shadow password service (getspnam() and getspent()). In such + cases, the DUA MUST NOT make use of the userPassword attribute for + getpwnam() et al, and MUST return a non-matchable password (such as + "x") to the client instead. + +5.4 Interpreting hosts and networks + + The ipHostNumber and ipNetworkNumber attributes are defined in + preference to dNSRecord (defined in [RFC1279]), in order to sim- + plify the DUA's role in interpreting entries in the directory. A + dNSRecord expresses a complete resource record, including time to + live and class data, which is extraneous to this schema. + + Additionally, the ipHost and ipNetwork classes permit a host or + network (respectively) and all its aliases to be represented by a + single entry in the directory. This is not necessarily possible if + a DNS resource record is mapped directly to an LDAP entry. Imple- + mentations that wish to use LDAP to master DNS zone information are + not precluded from doing so, and may simply avoid the ipHost and + ipNetwork classes. + + This document redefines, although not exclusively, the ipNetwork + class defined in [RFC1279], in order to achieve consistent naming + with ipHost. The ipNetworkNumber attribute is also used in the + siteContact object class [ROSE]. + + The authPassword and userPassword attributes are included in ipHost + + + +Howard [Page 14] + +Internet Draft NIS X.500 schema February 2005 + + + such that hosts may be treated as authentication principals. The + treatment of these attribute and inherent caveats considered in + section 5.2 apply here also. + + The trailing zeros in a network address MUST be omitted. CIDR-style + network addresses (eg. 192.168.1/24) MAY be used. + + Leading zeros MUST be removed from all components of an IPv6 + address string as defined by [RFC2373], section 2.2, item 1. The + IPv6 address string MUST be further normalized by following the + "::" syntax as defined in section 2.2, item 2. In addition, "::" + MUST be used to replace the longest string of zero bits. If there + are two or more longest strings of zero bits, then the first string + MUST be replaced. In addition, the syntax defined by [RFC2373], + section 2.2, item 3 MUST NOT be used. IPv4 addresses MUST be rep- + resented by the IPv4 dotted decimal string syntax. + + For example the following address: + + 1080:0000:0:0:08:800:200C:417A + FF01:0:0:0:0:0:01 + 0:0:0:0:0:0:0:0001 + 0:0:0:0:0:0:0:0 + + MUST be normalized as: + + 1080::8:800:200C:417A + FF01::101 + 0::1 + :: + +5.5 Interpreting other entities + + In general, a one-to-one mapping between entities and LDAP entries + is proposed, in that each entity has exactly one representation in + the DIT. In some cases this is not feasible; for example, a service + which is represented in more than one protocol domain. Consider the + following entry: + + dn: cn=domain,ou=services,dc=aja,dc=com + objectClass: top + objectClass: ipService + cn: domain + cn: nameserver + ipServicePort: 53 + ipServiceProtocol: tcp + ipServiceProtocol: udp + + + + +Howard [Page 15] + +Internet Draft NIS X.500 schema February 2005 + + + This entry MUST map to the following two (2) services entities: + + domain 53/tcp nameserver + domain 53/udp nameserver + + While the above two entities may be represented as separate LDAP + entities, with different distinguished names (such as + cn=domain+ipServiceProtocol=tcp, ... and cn=domain+ipServiceProto- + col=udp, ...) it is convenient to represent them as a single entry. + (If a service is represented in multiple protocol domains with dif- + ferent ports, then multiple entries are required; multivalued RDNs + may be used to distinguish them.) + + With the exception of authPassword and userPassword values, empty + values (consisting of a zero length string) are returned by the DUA + to the client. The DUA MUST reject any entries which do not conform + to the schema (missing mandatory attributes). Non-conforming + entries SHOULD be ignored while enumerating entries. + + The nisDomainObject object class is provided to associate a NIS + domain with a naming context. A DUA would retrieve the NIS domain + name from a configuration file and enumerate the naming contexts + served by an LDAP server, searching each naming context for (nisDo- + main=%s). The first matching entry that is found may be used as a + search base for configuration profile information or for entries + themselves. For example, the following example shows an association + between the NIS domain "nis.aja.com" and the naming context + "dc=aja,dc=com": + + dn: dc=aja,dc=com + objectClass: top + objectClass: domain + objectClass: nisDomainObject + dc: aja + nisDomain: nis.aja.com + + + The nisObject object class MAY be used as a generic means of repre- + senting NIS entities. Its use is not encouraged; where support for + entities not described in this schema is desired, an appropriate + schema should be devised. Implementors are strongly advised to sup- + port end-user extensible mappings between NIS entities and object + classes. (Where the nisObject class is used, the nisMapName + attribute may be used as a RDN.) The nisObject class might be used + to represent automount information. + +5.6 Canonicalizing entries with multi-valued naming attributes + + + + +Howard [Page 16] + +Internet Draft NIS X.500 schema February 2005 + + + For entities such as hosts, services, networks, protocols, and + RPCs, where there may be one or more aliases, the respective + entry's relative distinguished name SHOULD be used to determine the + canonical name. Any other values for the same attribute are used + as aliases. For example, the service described in section 5.5 has + the canonical name "domain" and exactly one alias, "nameserver". + + The schema in this document generally only defines one attribute + per class which is suitable for distinguishing an entity (excluding + any attributes with integer syntax; it is assumed that entries will + be distinguished on name). Usually, this is the common name (cn) + attribute. This aids the DUA in determining the canonical name of + an entity, as it can examine the value of the relative distin- + guished name. Aliases are thus any values of the distinguishing + attribute (such as cn) which do not match the canonical name of the + entity. + + In the event that a different attribute is used to distinguish the + entry, as may be the case where these object classes are used as + auxiliary classes, the entry's canonical name may not be present in + the RDN. In this case, the DUA MUST choose one of the non-distin- + guished values to represent the entity's canonical name. As the + directory server guarantees no ordering of attribute values, it may + not be possible to distinguish an entry deterministically. This + ambiguity SHOULD NOT be resolved by mapping one directory entry + into multiple entities. + + +6. Implementation focus + + Gateways between NIS and LDAP have been developed by PADL Software + and Sun Microsystems. They both support this schema. + + An open source implementation of the C library resolution code has + been written and is available from PADL Software. It supports C + libraries on GNU, BSD, AIX, and Solaris operating systems. PADL + have also made available a set of scripts for migrating flat files + into a form suitable for loading into an LDAP server. + + +7. Security considerations + + The entirety of related security considerations are outside the + scope of this document. It is noted that making passwords + encrypted with a widely understood hash function (such as crypt()) + available to non-privileged users is dangerous because it exposes + them to dictionary and brute-force attacks. This is proposed only + for compatibility with existing UNIX system implementations. Sites + + + +Howard [Page 17] + +Internet Draft NIS X.500 schema February 2005 + + + where security is critical SHOULD consider using a strong authenti- + cation service for user authentication. + + Alternatively, the encrypted password could be made available only + to a subset of privileged DUAs, which would provide "shadow" pass- + word service to client applications. This may be difficult to + enforce. + + Because the schema represents operating system-level entities, + access to these entities SHOULD be granted on a discretionary + basis. (There is little point in restricting access to data which + will be republished without restriction, however.) It is particu- + larly important that only administrators can modify entries defined + in this schema, with the exception of allowing a principal to + change their password (which may be done on behalf of the user by a + client bound as a superior principal, such that password restric- + tions may be enforced). For example, if a user were allowed to + change the value of their uidNumber attribute, they could subvert + security by equivalencing their account with the superuser account. + + A subtree of the DIT which is to be republished by a DUA (such as a + NIS gateway) SHOULD be within the same administrative domain that + the republishing DUA represents. (For example, principals outside + an organization, while conceivably part of the DIT, should not be + considered with the same degree of authority as those within the + organization.) + + Finally, care should be exercised with integer attributes of a sen- + sitive nature (particularly the uidNumber and gidNumber attributes) + which contain zero-length values. DUAs MAY treat such values as + corresponding to the "nobody" or "nogroup" user and group, respec- + tively. + + +8. Acknowledgements + + Thanks to Bob Joslin of the Hewlett Packard Company, and to all + those that helped with this document's predecessor, RFC 2307. + + UNIX is a registered trademark of The Open Group. + + +9. References + + [RFC1057] + Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol + Specification Version 2", RFC 1057, June 1988. + + + + +Howard [Page 18] + +Internet Draft NIS X.500 schema February 2005 + + + [RFC1279] + S. Kille, "X.500 and Domains", RFC 1279, November 1991. + + [RFC2373] + R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", + RFC 2373, July 1998. + + [RFC2119] + S. Bradner, "Key Words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + [RFC2251] + M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access + Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] + M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Direc- + tory Access Protocol (v3): Attribute Syntax Definitions", RFC + 2252, December 1997. + + [RFC2254] + T. Howes, "The String Representation of LDAP Search Filters", + RFC 2254, December 1997. + + [RFC2256] + M. Wahl, "A Summary of the X.500(96) User Schema for use with + LDAPv3", RFC 2256, December 1997. + + [RFC3112] + K. Zeilenga, "LDAP Authentication Password Schema", RFC 3112, + May 2001. + + [ROSE] + M. T. Rose, "The Little Black Book: Mail Bonding with OSI + Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc., + 1992. + + [X500] + "Information Processing Systems - Open Systems Interconnection + - The Directory: Overview of Concepts, Models and Service", + ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. + + [XOPEN] + ISO/IEC 9945-1:1990, Information Technology - Portable Operat- + ing Systems Interface (POSIX) - Part 1: Systems Application + Programming Interface (API) [C Language] + + [namedObject] + + + +Howard [Page 19] + +Internet Draft NIS X.500 schema February 2005 + + + L. Howard, "A Structural Object Class for Arbitrary Auxiliary + Object Classes", INTERNET-DRAFT , July 2002. + + +10. Authors' Address + + Luke Howard + PADL Software Pty. Ltd. + PO Box 59 + Central Park, Vic 3145 + Australia + EMail: lukeh@padl.com + + Morteza Ansari + Infoblox Inc. + 475 Potrero Avenue + Sunnyvale, CA 94085 + USA + Phone: +1 408 716 4344 + EMail: morteza@infoblox.com + + +A. Example entries + + The examples described in this section are provided to illustrate + the schema described in this draft. They are not meant to be + exhaustive. + + The following entry is an example of the posixAccount class: + + dn: uid=lester,ou=people,dc=aja,dc=com + objectClass: top + objectClass: account + objectClass: posixAccount + uid: lester + cn: Lester the Nightfly + gecos: Lester + uidNumber: 10 + gidNumber: 10 + loginShell: /bin/csh + userPassword: {crypt}$X5/DBrWPOQQaI + homeDirectory: /home/lester + + + This corresponds the UNIX system password file entry: + + lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh + + + +Howard [Page 20] + +Internet Draft NIS X.500 schema February 2005 + + + The following entry is an example of the ipHost class: + + dn: cn=josie.aja.com,ou=hosts,dc=aja,dc=com + objectClass: top + objectClass: device + objectClass: ipHost + objectClass: bootableDevice + objectClass: ieee802Device + cn: josie.aja.com + cn: www.aja.com + ipHostNumber: 10.0.0.1 + macAddress: 00:00:92:90:ee:e2 + bootFile: mach + bootParameter: root=dan.aja.com:/nfsroot/peg + bootParameter: swap=dan.aja.com:/nfsswap/peg + bootParameter: dump=dan.aja.com:/nfsdump/peg + + This entry represents the host canonically josie.aja.com, also + known as www.aja.com. The Ethernet address and four boot parameters + are also specified. + + An example of the nisNetgroup class: + + dn: cn=nightfly,ou=netgroup,dc=aja,dc=com + objectClass: top + objectClass: nisNetgroup + cn: nightfly + nisNetgroupTriple: (charlemagne,peg,dunes.aja.com) + nisNetgroupTriple: (lester,-,) + memberNisNetgroup: kamakiriad + + This entry represents the netgroup nightfly, which contains two + triples (the user charlemagne, the host peg, and the domain + dunes.aja.com; and, the user lester, no host, and any domain) and + one netgroup (kamakiriad). + + Finally, an example of the nisObject class: + + dn: nisMapName=tracks,dc=dunes,dc=aja,dc=com + objectClass: top + objectClass: nisMap + nisMapName: tracks + + dn: cn=Maxine,nisMapName=tracks,dc=dunes,dc=aja,dc=com + objectClass: top + objectClass: nisObject + cn: Maxine + nisMapName: tracks + + + +Howard [Page 21] + +Internet Draft NIS X.500 schema February 2005 + + + nisMapEntry: Nightfly$4 + + This entry represents the NIS map tracks, and a single map entry. + + +B. Affected library functions + + The following functions are typically found in the C libraries of + most UNIX and POSIX compliant systems. An LDAP search filter + [RFC2254] which may be used to satisfy the function call is + included alongside each function name. Parameters are denoted by %s + and %d for string and integer arguments, respectively. Long lines + are broken. + + getpwnam() (&(objectClass=posixAccount)(uid=%s)) + getpwuid() (&(objectClass=posixAccount)(uidNumber=%d)) + getpwent() (objectClass=posixAccount) + getspnam() (&(objectClass=shadowAccount)(uid=%s)) + getspent() (objectClass=shadowAccount) + + getgrnam() (&(objectClass=posixGroup)(cn=%s)) + getgrgid() (&(objectClass=posixGroup)(gidNumber=%d)) + getgrent() (objectClass=posixGroup) + + getservbyname() (&(objectClass=ipService)(cn=%s) + (ipServiceProtocol=%s)) + getservbyport() (&(objectClass=ipService)(ipServicePort=%d) + (ipServiceProtocol=%s)) + getservent() (objectClass=ipService) + + getrpcbyname() (&(objectClass=oncRpc)(cn=%s)) + getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d)) + getrpcent() (objectClass=oncRpc) + + getprotobyname() (&(objectClass=ipProtocol)(cn=%s)) + getprotobynumber() (&(objectClass=ipProtocol)(ipProtocolNumber=%d)) + getprotoent() (objectClass=ipProtocol) + + gethostbyname() (&(objectClass=ipHost)(cn=%s)) + gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s)) + gethostent() (objectClass=ipHost) + + getnetbyname() (&(objectClass=ipNetwork)(cn=%s)) + getnetbyaddr() (&(objectClass=ipNetwork)(ipNetworkNumber=%s)) + getnetent() (objectClass=ipNetwork) + + setnetgrent() (&(objectClass=nisNetgroup)(cn=%s)) + + + + +Howard [Page 22] + +Internet Draft NIS X.500 schema February 2005 + + + getpublickey() (&(objectClass=nisKeyObject)(...)) + + + +C. Suggested DIT structure + + The cn attribute is typically used to name entities. The ipHostNum- + ber, ipNetworkNumber, and ipServiceProtocol attributes are also + naming attributes, such that multi-valued RDNs may be used to dis- + tinguish between, for example, different interfaces of a multi- + homed host. + + The following DIT structure MAY be used for deploying this schema. + It is not required that DC-naming be used, but it is encouraged. + + Naming context ObjectClass + ============================================================ + ou=people,dc=... posixAccount + shadowAcount + ou=group,dc=... posixGroup + ou=services,dc=... ipService + ou=protocols,dc=... ipProtocol + ou=rpc,dc=... oncRpc + ou=hosts,dc=... ipHost + ou=ethers,dc=... ieee802Device + bootableDevice + ou=networks,dc=... ipNetwork + ou=netgroup,dc=... nisNetgroup + nisMapName=...,dc=... nisObject + automountMapName=...,dc=... automountMap + + +Intellectual Property Rights + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology described + in this document or the extent to which any license under such + rights might or might not be available; nor does it represent that + it has made any independent effort to identify any such rights. + Information on the procedures with respect to rights in RFC docu- + ments can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this speci- + fication can be obtained from the IETF on-line IPR repository at + + + +Howard [Page 23] + +Internet Draft NIS X.500 schema February 2005 + + + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). This document is sub- + ject to the rights, licenses and restrictions contained in BCP 78, + and except as set forth therein, the authors retain all their + rights. + + This document and the information contained herein are provided on + an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REP- + RESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Howard [Page 24] + + -- 2.39.5