--- /dev/null
+
+
+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
+ <draft-howard-rfc2307bis-01.txt>
+
+
+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 <ldapext@ietf.org>. Please send editorial com-
+ ments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+Internet Draft NIS X.500 schema February 2005
+
+
+ L. Howard, "A Structural Object Class for Arbitrary Auxiliary
+ Object Classes", INTERNET-DRAFT <draft-howard-namedOb-
+ ject-02.txt>, 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+
projects / openldap / commitdiff