-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
+Network Working Group L. Howard
+Internet-Draft PADL Software
+Obsoletes: 2307 (if approved) H. Chu, Ed.
+Intended status: Informational Symas Corp.
+Expires: February 10, 2010 August 9, 2009
+ An Approach for Using LDAP as a Network Information Service
+ draft-howard-rfc2307bis-02.txt
+Status of this Memo
- An Approach for Using LDAP as a Network Information Service
- <draft-howard-rfc2307bis-01.txt>
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
-Status of this Memo
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
- 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>.
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
- 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.
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
- 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.
+ This Internet-Draft will expire on February 10, 2010.
- 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."
+Copyright Notice
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
- 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.
+Howard & Chu Expires February 10, 2010 [Page 1]
+\f
+Internet-Draft LDAP NameService Schema August 2009
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]
+ This document describes a mechanism for mapping entities related to
+ TCP/IP and the UNIX system [UNIX] into [X.500] entries so that they
+ may be resolved with the Lightweight Directory Access Protocol
+ [RFC4511]. A set of attribute types and object classes are proposed,
+ along with specific guidelines for interpreting them. The intention
+ is to assist the deployment of LDAP as an organizational 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, leading eventually to the
+ adoption of standards. The proposed mechanism has already been
+ implemented with some success.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 2]
+\f
+Internet-Draft LDAP NameService Schema August 2009
+
+
+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 [UNIX]) 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 utility
+ "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
+ nameservice 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) and the Domain Name System (DNS) [RFC1034]. (The latter is
+ typically used for resolving hosts, services and networks.) Both
+ these nameservices have the advantage of being distributed and thus
+ permitting a common set of entities to be shared amongst many
+ clients.
+
+ LDAP is a distributed, hierarchical directory service access protocol
+ which is used to access repositories of users and other network-
+ 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 nameservice
+ such as NIS. By using LDAP as the primary means of resolving these
+ entities, these redundancy issues are minimized and the scalability
+ of LDAP can be exploited. (By comparison, NIS services based on flat
+ files do not have the scalability or extensibility 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.
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 3]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
- 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.
+2. General Issues
- 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.)
+2.1. Terminology
- 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.
+ 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 supports
+ extensible schema and multiple naming contexts.
-2. General Issues
+ 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 otherwise. 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.
-2.1 Terminology
+ 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 termed
+ "republishing".
- The key words "MUST", "SHOULD", and "MAY" used in this document are
- to be interpreted as described in [RFC2119].
+ 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 the user's integer identification number (being the value
+ of the uidNumber attribute).
- 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 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 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 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 "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
+ The OIDs defined below are derived from iso(1) org(3) dod(6)
-Howard [Page 3]
+Howard & Chu Expires February 10, 2010 [Page 4]
+\f
+Internet-Draft LDAP NameService Schema August 2009
+
+
+ internet(1) directory(1) nisSchema(1)
+
+2.2. Schema
+
+ The attributes and classes defined in this document are summarized
+ below.
+
+2.2.1. Attributes
+
+ 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
+ oncRpcNumber
+ ipHostNumber
+ ipNetworkNumber
+ ipNetmaskNumber
+ macAddress
+ bootParameter
+ bootFile
+ nisMapName
+ nisMapEntry
+ nisPublicKey
+ nisSecretKey
+ nisDomain
+ automountMapName
+ automountKey
+ automountInformation
+
+ Additionally, some of the attributes defined in [RFC4519] and
+ [RFC3112] are required.
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 5]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
- termed "republishing".
+2.2.2. Attribute Option
- 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).
+ Centralizing a name service in LDAP allows heterogeneous systems to
+ obtain their information from a single place. However in some cases,
+ this information cannot be used uniformly on all of the client
+ systems. These attribute options are defined to allow system-
+ specific values to be used where necessary. The options are defined
+ as the following:
- 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).
+ host-<hostname>
+ hostos-<ostype>
- 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.)
+ where hostname is a string representing the name of a specific
+ machine, and ostype is a string representing a particular operating
+ system.
- The OIDs defined below are derived from iso(1) org(3) dod(6) inter-
- net(1) directory(1) nisSchema(1).
+ For example, a user named "Babs Jensen" may have a different home
+ directory on different machines. This could be represented as:
-2.2 Attributes
+ homeDirectory: /home/babsj
+ homeDirectory;hostos-sunos: /export/home/bjensen
+ homeDirectory;host-babshost: /home/root
- The attributes and classes defined in this document are summarized
- below.
+ These attribute options follow sub-typing semantics. If a DUA
+ requests an attribute to be returned in a search operation, and does
+ not specify an option, all subtypes of that attribute are returned.
- The following attributes are defined in this document:
+2.2.3. Object Classes
- uidNumber
- gidNumber
- gecos
- homeDirectory
- loginShell
- shadowLastChange
- shadowMin
- shadowMax
- shadowWarning
- shadowInactive
- shadowExpire
- shadowFlag
- memberUid
- memberNisNetgroup
- nisNetgroupTriple
- ipServicePort
- ipServiceProtocol
- ipProtocolNumber
+ 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
-Howard [Page 4]
+
+Howard & Chu Expires February 10, 2010 [Page 6]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+
+ Additionally, some of the attributes defined in [RFC4519] are
+ required.
+
+
+
+
+
+
+
+
+
+
+
+
- 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]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 7]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+3. Attribute Definitions
- DUAs supporting this schema.
+ This section contains attribute definitions to be implemented by 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.0 NAME 'uidNumber'
+ DESC 'An integer uniquely identifying a user in an
+ administrative domain'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ 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.1 NAME 'gidNumber'
+ DESC 'An integer uniquely identifying a group in an
+ administrative domain'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ 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.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.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.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.7 NAME 'shadowMax'
- EQUALITY integerMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ ( 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 )
-Howard [Page 6]
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 8]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+ ( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
- 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.6 NAME 'shadowMin'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ 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.7 NAME 'shadowMax'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ 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.8 NAME 'shadowWarning'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
- ( 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.9 NAME 'shadowInactive'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
- ( 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.10 NAME 'shadowExpire'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
- ( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber'
+ ( 1.3.6.1.1.1.1.11 NAME 'shadowFlag'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
-Howard [Page 7]
+
+
+Howard & Chu Expires February 10, 2010 [Page 9]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+
+ ( 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 )
- 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.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.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.15 NAME 'ipServicePort'
+ DESC 'Service port number'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
- ( 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.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.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.17 NAME 'ipProtocolNumber'
+ DESC 'IP protocol number'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
- ( 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
+ ( 1.3.6.1.1.1.1.18 NAME 'oncRpcNumber'
+ DESC 'ONC RPC number'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
-Howard [Page 8]
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 10]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+
+ ( 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 )
- 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.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.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.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.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.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.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 )
+ ( 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 )
-4. Class definitions
+ ( 1.3.6.1.1.1.1.26 NAME 'nisMapName'
+ DESC 'Name of a generic NIS map'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} )
- This section contains class definitions to be implemented by DUAs
- supporting the schema.
-Howard [Page 9]
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 11]
\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]
+Internet-Draft LDAP NameService Schema August 2009
+
+
+ ( 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 )
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 12]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
- MAY description )
+4. Class Definitions
- ( 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 ) )
+ This section contains class definitions to be implemented by DUAs
+ supporting the schema.
- ( 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 ) )
+ 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.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.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.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.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.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.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.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 )
+ ( 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 )
-Howard [Page 11]
+
+
+Howard & Chu Expires February 10, 2010 [Page 13]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+ ( 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 )
+ MAY description )
- ( 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 )
+ ( 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 ) )
-5. Implementation details
+ ( 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 ) )
-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.
+ ( 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 ) )
- 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
+ ( 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 )
- 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
+ ( 1.3.6.1.1.1.2.10 NAME 'nisObject' SUP top STRUCTURAL
+ DESC 'An entry in a NIS map'
+ MUST ( cn $ nisMapEntry $ nisMapName )
+ ( 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 )
-Howard [Page 12]
+
+
+Howard & Chu Expires February 10, 2010 [Page 14]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+
+ ( 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 ) )
- class.
+ ( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top AUXILIARY
+ DESC 'Associates a NIS domain with a naming context'
+ MUST nisDomain )
- 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.)
+ ( 1.3.6.1.1.1.2.16 NAME 'automountMap' SUP top STRUCTURAL
+ MUST ( automountMapName )
+ MAY description )
- 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:
+ ( 1.3.6.1.1.1.2.17 NAME 'automount' SUP top STRUCTURAL
+ DESC 'Automount information'
+ MUST ( automountKey $ automountInformation )
+ MAY description )
- passwordvalue = schemeprefix encryptedpasswd
- schemeprefix = "{" scheme "}"
- scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme
- altscheme = "x-" keystring
- encryptedpasswd = encrypted password
+ ( 1.3.6.1.1.1.2.18 NAME 'groupOfMembers' SUP top STRUCTURAL
+ DESC 'A group with members (DNs)'
+ MUST cn
+ MAY ( businessCategory $ seeAlso $ owner $ ou $ o $
+ description $ member ) )
- 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]
+
+
+
+
+
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 15]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
- 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.
+5. Implementation Details
- Below is an example of an authPassword attribute:
+5.1. Suggested Resolution Methods
- authPassword: CRYPT$X5/DBrWPOQQaI
+ The preferred means of directing a client application (one using the
+ shared services of the C library) to use LDAP as its information
+ 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 implementations 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" (NSS). The means in
+ which the DUA locates LDAP servers is also implementation dependent.
- Below is an example of a (deprecated) userPassword attribute:
+5.2. Interpreting User and Group Entries
- userPassword: {CRYPT}X5/DBrWPOQQaI
+ 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
+ insensitive. 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. Likewise, the groupOfMembers object class SHOULD be used
+ for groups. (The groupOfUniqueNames object class is deprecated and
+ SHOULD NOT be used.)
- 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.
+ It is suggested that uid and cn are used as the naming attribute for
+ posixAccount and posixGroup entries, respectively. Group members may
+ either be login names (values of memberUid) or distinguished names
+ (values of member). 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 "(objectclass=*)". DUAs MAY wish to cache DN to
+ login name mappings. The DUA MAY traverse nested groups.
-5.4 Interpreting hosts and networks
+ An account's GECOS field is preferably determined by a value of the
- 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].
+Howard & Chu Expires February 10, 2010 [Page 16]
+\f
+Internet-Draft LDAP NameService Schema August 2009
- The authPassword and userPassword attributes are included in ipHost
+ 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.)
+5.2.1. Using Attribute Options
-Howard [Page 14]
+ Some posixAccount attributes may be accompanied by options
+ (Section 2.2.2) identifying particular hosts or operating system
+ types. The attribute with a hostos option matching the operating
+ system of the DUA SHOULD be used in preference to an attribute
+ without any associated options. The attribute with a host option
+ matching the hostname of the DUA SHOULD be used in preference to any
+ other attribute.
+
+5.2.2. Authentication Considerations
+
+5.2.2.1. Using Password Values
+
+ When authenticating using a NIS to LDAP gateway or using NSS, a
+ lookup is performed to retrieve the password attribute and the value
+ is used in the DUA to authenticate a user. This approach to
+ authentication is deprecated, as it requires that read access to the
+ password attribute be granted across a network.
+
+ An entry of class posixAccount, posixGroup, or shadowAccount without
+ 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 the
+ following syntax:
+
+ passwordvalue = schemeprefix hashedpasswd
+ schemeprefix = "{" scheme "}"
+ scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme
+ altscheme = "x-" keystring
+ hashedpasswd = hashed password
+
+ The hashed password contains a plaintext key hashed using the
+ algorithm scheme. If the schema is "sha", the hashed password is the
+ base64 encoding of the SHA-1 digest of the plaintext password.
+
+ 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
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 17]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+ if hashedpassword is an empty string does the user have no password.
+ DUAs are not required to consider hashing schemes which the client
+ will not recognize; in most cases, it may be sufficient to consider
+ only "crypt".
- 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.
+ DUA MAY use the authPassword attribute instead of userPassword,
+ defined in [RFC3112]. The DUA MUST iterate the values of the
+ authPassword 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 here, 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 advisable, beyond the scope of this
+ document
- The trailing zeros in a network address MUST be omitted. CIDR-style
- network addresses (eg. 192.168.1/24) MAY be used.
+ Below is an example of an authPassword attribute:
- 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.
+ authPassword: CRYPT$X5/DBrWPOQQaI
- For example the following address:
+ Below is an example of a (deprecated) userPassword attribute:
- 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
+ userPassword: {CRYPT}X5/DBrWPOQQaI
- MUST be normalized as:
+ A DUA MAY utilize the attributes in the shadowAccount class to
+ provide 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.
- 1080::8:800:200C:417A
- FF01::101
- 0::1
- ::
+5.2.2.2. Using LDAP Bind
-5.5 Interpreting other entities
+ The preferred method for authenticating users with LDAP is to perform
+ an LDAP Bind operation with the user's name and password. In this
+ case the method the DSA uses to store and verify the password is
+ completely internal to the DSA and not of any concern to the DUA.
- 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:
+ Likewise, using the shadowAccount attributes requires the DUA to
+ handle password policy enforcement. However the policies expressed
+ in the shadowAccount are limited in scope, and not uniformly
+ applicable to all the systems that will be using LDAP.
- dn: cn=domain,ou=services,dc=aja,dc=com
- objectClass: top
- objectClass: ipService
- cn: domain
- cn: nameserver
- ipServicePort: 53
- ipServiceProtocol: tcp
- ipServiceProtocol: udp
+ The preferred method is to leave password policy enforcement to the
+ DSA, so that it will be uniformly enforced across all of the various
+ systems that rely on the directory. This enforcement occurs
+ implicitly when authenticating using LDAP Bind if the DSA supports
+ the LDAP password policy [I-D.behera-ldap-password-policy]
+ mechanisms.
-Howard [Page 15]
+Howard & Chu Expires February 10, 2010 [Page 18]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
- This entry MUST map to the following two (2) services entities:
+ The means in which authentication in the DUA is configured is
+ implementation dependent. Typically it is accomplished using [PAM].
+ Further details of authentication are beyond the scope of this
+ document.
- domain 53/tcp nameserver
- domain 53/udp nameserver
+5.2.3. Naming Considerations
- 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.)
+ On UNIX systems, users and groups reside in separate name spaces and
+ it is common for the same name to be used by both a user and a group.
+ Since they are in separate name spaces there is no ambiguity and no
+ conflict. However, when integrating a name service into LDAP the
+ directory may be used with other systems besides UNIX and its
+ derivatives. In particular, the Microsoft Windows operating system
+ may also use LDAP for its own name service. In Windows, users and
+ groups reside in a single name space and so one cannot use the same
+ name for both a user and a group.
- 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.
+ Conflicts in naming conventions may arise in other deployments as
+ well, and should be carefully taken into account when migrating from
+ other naming services into LDAP.
- 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":
+5.3. Interpreting Hosts and Networks
- dn: dc=aja,dc=com
- objectClass: top
- objectClass: domain
- objectClass: nisDomainObject
- dc: aja
- nisDomain: nis.aja.com
+ The ipHostNumber and ipNetworkNumber attributes are defined in
+ preference to dNSRecord (defined in [RFC1279]), in order to simplify
+ 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.
+ Implementations 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.
- 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.
+ 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].
-5.6 Canonicalizing entries with multi-valued naming attributes
+ The authPassword and userPassword attributes are included in ipHost
+ such that hosts MAY be treated as authentication principals. The
+ treatment of these attributes and inherent caveats considered in
+ Section 5.2 apply here also.
+ The trailing zeros in a network address MUST be omitted. CIDR-style
-Howard [Page 16]
+Howard & Chu Expires February 10, 2010 [Page 19]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
- 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".
+ 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
+ [RFC2373], 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 represented by the IPv4
+ dotted decimal string syntax.
- 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.
+ For example the following address:
- 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.
+ 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:
-6. Implementation focus
+ 1080::8:800:200C:417A
+ FF01::101
+ 0::1
+ ::
- Gateways between NIS and LDAP have been developed by PADL Software
- and Sun Microsystems. They both support this schema.
+5.4. Interpreting Other Entities
- 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.
+ 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
-7. Security considerations
+ This entry MUST map to the following two (2) services entities:
- 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
+ domain 53/tcp nameserver
+ domain 53/udp nameserver
+ While the above two entities may be represented as separate LDAP
-Howard [Page 17]
+
+Howard & Chu Expires February 10, 2010 [Page 20]
+\f
+Internet-Draft LDAP NameService Schema August 2009
+
+
+ entities, with different distinguished names (such as cn=domain+
+ ipServiceProtocol=tcp, ... and cn=domain+ipServiceProtocol=udp, ...)
+ it is convenient to represent them as a single entry. If a service
+ is represented in multiple protocol domains with different ports,
+ then multiple entries are required; multi-valued 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
+ (nisDomain=%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
+ representing NIS entities. Its use is not encouraged; where support
+ for entities not described in this schema is desired, an appropriate
+ schema should be devised. Implementers are strongly advised to
+ support 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.5. Canonicalizing entries with multi-valued naming attributes
+
+ 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.4 has the canonical
+ name "domain" and exactly one alias, "nameserver".
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 21]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+
+ 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 distinguished
+ 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-
+ distinguished 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.
+
+
+
+
+
+
+
+
- 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]
+
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 22]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+
+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. Another open source
+ implementation of the C library code is available from the OpenLDAP
+ Project.
- [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]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 23]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+
+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 where security is
+ critical SHOULD consider using a strong authentication service for
+ user authentication.
- L. Howard, "A Structural Object Class for Arbitrary Auxiliary
- Object Classes", INTERNET-DRAFT <draft-howard-namedOb-
- ject-02.txt>, July 2002.
+ Alternatively, the encrypted password could be made available only to
+ a subset of privileged DUAs, which would provide "shadow" password
+ 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 particularly
+ 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 restrictions 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.
-10. Authors' Address
+ 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.)
- Luke Howard
- PADL Software Pty. Ltd.
- PO Box 59
- Central Park, Vic 3145
- Australia
- EMail: lukeh@padl.com
+ Finally, care should be exercised with integer attributes of a
+ sensitive 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,
+ respectively.
- 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]
+Howard & Chu Expires February 10, 2010 [Page 24]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
- 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]
+
+
+
+
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 25]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+9. References
- nisMapEntry: Nightfly$4
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
- This entry represents the NIS map tracks, and a single map entry.
+ [RFC1057] Sun Microsystems, Inc., "RPC: Remote Procedure Call
+ Protocol specification: Version 2", RFC 1057, June 1988.
+ [RFC1279] Hardcastle-Kille, S., "X.500 and Domains", RFC 1279,
+ November 1991.
-B. Affected library functions
+ [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
- 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.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
- getpwnam() (&(objectClass=posixAccount)(uid=%s))
- getpwuid() (&(objectClass=posixAccount)(uidNumber=%d))
- getpwent() (objectClass=posixAccount)
- getspnam() (&(objectClass=shadowAccount)(uid=%s))
- getspent() (objectClass=shadowAccount)
+ [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
+ (LDAP): The Protocol", RFC 4511, June 2006.
- getgrnam() (&(objectClass=posixGroup)(cn=%s))
- getgrgid() (&(objectClass=posixGroup)(gidNumber=%d))
- getgrent() (objectClass=posixGroup)
+ [RFC4515] Smith, M. and T. Howes, "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Search Filters",
+ RFC 4515, June 2006.
- getservbyname() (&(objectClass=ipService)(cn=%s)
- (ipServiceProtocol=%s))
- getservbyport() (&(objectClass=ipService)(ipServicePort=%d)
- (ipServiceProtocol=%s))
- getservent() (objectClass=ipService)
+ [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
+ (LDAP): Schema for User Applications", RFC 4519,
+ June 2006.
- getrpcbyname() (&(objectClass=oncRpc)(cn=%s))
- getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d))
- getrpcent() (objectClass=oncRpc)
+ [RFC3112] Zeilenga, K., "LDAP Authentication Password Schema",
+ RFC 3112, May 2001.
- getprotobyname() (&(objectClass=ipProtocol)(cn=%s))
- getprotobynumber() (&(objectClass=ipProtocol)(ipProtocolNumber=%d))
- getprotoent() (objectClass=ipProtocol)
+ [I-D.behera-ldap-password-policy]
+ Sermersheim, J., Poitou, L., and H. Chu, "Password Policy
+ for LDAP Directories",
+ draft-behera-ldap-password-policy-10 (work in progress),
+ August 2009.
- gethostbyname() (&(objectClass=ipHost)(cn=%s))
- gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s))
- gethostent() (objectClass=ipHost)
+ [ROSE] Rose, M., "The Little Black Book: Mail Bonding with OSI
+ Directory Services", ISBN 0-13-683210-5, 2001.
- getnetbyname() (&(objectClass=ipNetwork)(cn=%s))
- getnetbyaddr() (&(objectClass=ipNetwork)(ipNetworkNumber=%s))
- getnetent() (objectClass=ipNetwork)
+ [X.500] ISO/IEC JTC 1/SC21, "Information Processing Systems - Open
+ Systems Interconnection - The Directory: Overview of
+ Concepts, Models and Service", 1988.
- setnetgrent() (&(objectClass=nisNetgroup)(cn=%s))
+ [UNIX] Institute of Electrical and Electronics Engineers and The
+ Open Group, "IEEE Std 1003.1, 2004 Edition, Single UNIX
+ Specification Version 3", IEEE Standard 1003.1, 2004.
-Howard [Page 22]
+Howard & Chu Expires February 10, 2010 [Page 26]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+
+ [PAM] Samar, V. and R. Schemers, "Unified Login with Pluggable
+ Authentication Modules (PAM)", OSF RFC 86.0, October 1995.
+
+
+
+
+
+
+
+
+
+
+
- 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]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 27]
\f
-Internet Draft NIS X.500 schema February 2005
+Internet-Draft LDAP NameService Schema August 2009
+
+Appendix A. Example Entries
- http://www.ietf.org/ipr.
+ The examples described in this section are provided to illustrate the
+ schema described in this draft. They are not meant to be exhaustive.
- 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.
+ 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
-Full Copyright Statement
+ This corresponds to the UNIX system password file entry:
- 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.
+ lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh
- 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.
+ 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:
+Howard & Chu Expires February 10, 2010 [Page 28]
+\f
+Internet-Draft LDAP NameService Schema August 2009
+ 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
+ nisMapEntry: Nightfly$4
+ This represents the NIS map tracks, and a single map entry.
-Howard [Page 24]
+
+
+
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 29]
+\f
+Internet-Draft LDAP NameService Schema August 2009
+
+
+Appendix B. Affected Library Functions
+
+ The following functions are typically found in the C libraries of
+ most UNIX and POSIX compliant systems [UNIX]. An LDAP search filter
+ string [RFC4515] 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))
+ getpublickey() (&(objectClass=nisKeyObject)(...))
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 30]
\f
+Internet-Draft LDAP NameService Schema August 2009
+
+
+Appendix C. Suggested DIT structure
+
+ The cn attribute is typically used to name entities. The
+ ipHostNumber, ipNetworkNumber, and ipServiceProtocol attributes are
+ also naming attributes, such that multi-valued RDNs may be used to
+ distinguish between, for example, different interfaces of a
+ multihomed 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 31]
+\f
+Internet-Draft LDAP NameService Schema August 2009
+
+
+Authors' Addresses
+
+ Luke Howard
+ PADL Software Pty. Ltd.
+ PO Box 59
+ Central Park, Vic 3145
+ AU
+
+ Email: lukeh@padl.com
+
+
+ Howard Chu (editor)
+ Symas Corp.
+ 18740 Oxnard Street, Suite 313A
+ Tarzana, California 91356
+ US
+
+ Phone: +1 818 757-7087
+ Email: hyc@symas.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard & Chu Expires February 10, 2010 [Page 32]
+\f
--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+ <!ENTITY rfc1034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
+ <!ENTITY rfc1057 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1057.xml'>
+ <!ENTITY rfc1279 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1279.xml'>
+ <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
+ <!ENTITY rfc2195 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2195.xml'>
+ <!ENTITY rfc2373 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2373.xml'>
+ <!ENTITY rfc4422 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml'>
+ <!ENTITY rfc4511 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4511.xml'>
+ <!ENTITY rfc4513 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4513.xml'>
+ <!ENTITY rfc4515 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4515.xml'>
+ <!ENTITY rfc4517 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4517.xml'>
+ <!ENTITY rfc4519 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4519.xml'>
+ <!ENTITY rfc2831 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2831.xml'>
+ <!ENTITY rfc3062 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3062.xml'>
+ <!ENTITY rfc3112 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3112.xml'>
+ <!ENTITY rfc3383 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3383.xml'>
+ <!ENTITY rfc3672 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3672.xml'>
+ <!ENTITY ppolicy PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.behera-ldap-password-policy.xml'>
+]>
+<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
+<?rfc symrefs="yes" ?>
+<rfc
+ obsoletes="2307"
+ ipr="trust200902"
+ category="info"
+ docName="draft-howard-rfc2307bis-02">
+ <front>
+ <title abbrev="LDAP NameService Schema">
+ An Approach for Using LDAP as a Network Information Service
+ </title>
+ <author initials="L." surname="Howard" fullname="Luke Howard">
+ <organization abbrev="PADL Software">
+ PADL Software Pty. Ltd.
+ </organization>
+ <address>
+ <postal>
+ <street>PO Box 59</street>
+ <city>Central Park</city>
+ <region>Vic</region>
+ <code>3145</code>
+ <country>AU</country>
+ </postal>
+ <email>lukeh@padl.com</email>
+ </address>
+ </author>
+ <author initials="H." fullname="Howard Chu" surname="Chu" role="editor">
+ <organization>Symas Corp.</organization>
+ <address>
+ <postal>
+ <street>18740 Oxnard Street, Suite 313A</street>
+ <city>Tarzana</city>
+ <region>California</region>
+ <code>91356</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 818 757-7087</phone>
+ <email>hyc@symas.com</email>
+ </address>
+ </author>
+ <date month="August" year="2009"/>
+ <abstract>
+ <t>This document describes a mechanism for mapping
+ entities related to <xref target="UNIX">TCP/IP and the UNIX
+ system </xref> into <xref target="X.500"/> entries so
+ that they may be resolved with the <xref target="RFC4511">
+ Lightweight Directory Access Protocol</xref>. A set of attribute types
+ and object classes are proposed, along with specific guidelines for
+ interpreting them. The intention is to assist the deployment of
+ LDAP as an organizational 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, leading eventually to the adoption of standards. The
+ proposed mechanism has already been implemented with some success.
+</t>
+ </abstract>
+ </front>
+
+ <middle>
+ <section anchor="background" title="Background and Motivation">
+ <t>The UNIX (R) operating system, and its derivatives (specifically,
+ those which support TCP/IP and conform to the <xref target="UNIX">
+ X/Open Single UNIX specification</xref>) 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.)</t>
+ <t>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 <xref target="RFC1057">ONC Remote Procedure Call</xref>
+ numbers and vice versa), NIS netgroups, booting information (boot
+ parameters and MAC address mappings), filesystem mounts, IP hosts
+ and networks.</t>
+ <t>Resolution requests are made through a set of C functions, provided
+ in the UNIX system's C library. For example, the UNIX system utility
+ "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
+ nameservice 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)
+ and the <xref target="RFC1034">Domain Name System (DNS)</xref>. (The latter is typically used for
+ resolving hosts, services and networks.) Both these nameservices
+ have the advantage of being distributed and thus permitting a common
+ set of entities to be shared amongst many clients.</t>
+ <t>LDAP is a distributed, hierarchical directory service access
+ protocol which is used to access repositories of users and other
+ network-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
+ nameservice such as NIS. By using LDAP as the primary means of
+ resolving these entities, these redundancy issues are minimized and
+ the scalability of LDAP can be exploited. (By comparison, NIS services
+ based on flat files do not have the scalability or extensibility of
+ LDAP or X.500.)</t>
+ <t>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.</t>
+ </section>
+ <section anchor="general" title="General Issues">
+ <section anchor="genera.terms" title="Terminology">
+ <t>The key words "MUST", "SHOULD", and "MAY" used in this document
+ are to be interpreted as described in
+ <xref target="RFC2119"/>.</t>
+ <t>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
+ supports extensible schema and multiple naming contexts.</t>
+ <t>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 otherwise.
+ 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.</t>
+ <t>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 termed "republishing".</t>
+ <t>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 the user's integer identification number (being
+ the value of the uidNumber attribute).</t>
+ <t>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).</t>
+ <t>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.)</t>
+ <t>The OIDs defined below are derived from iso(1) org(3) dod(6)
+ internet(1) directory(1) nisSchema(1)</t>
+ </section>
+ <section title="Schema">
+ <t>The attributes and classes defined in this document are summarized
+ below.</t>
+ <section anchor="general.attrs" title="Attributes">
+ <t>The following attributes are defined in this document:
+ <list style="empty">
+ <t>
+ uidNumber<vspace blankLines="0"/>
+ gidNumber<vspace blankLines="0"/>
+ gecos<vspace blankLines="0"/>
+ homeDirectory<vspace blankLines="0"/>
+ loginShell<vspace blankLines="0"/>
+ shadowLastChange<vspace blankLines="0"/>
+ shadowMin<vspace blankLines="0"/>
+ shadowMax<vspace blankLines="0"/>
+ shadowWarning<vspace blankLines="0"/>
+ shadowInactive<vspace blankLines="0"/>
+ shadowExpire<vspace blankLines="0"/>
+ shadowFlag<vspace blankLines="0"/>
+ memberUid<vspace blankLines="0"/>
+ memberNisNetgroup<vspace blankLines="0"/>
+ nisNetgroupTriple<vspace blankLines="0"/>
+ ipServicePort<vspace blankLines="0"/>
+ ipServiceProtocol<vspace blankLines="0"/>
+ ipProtocolNumber<vspace blankLines="0"/>
+ oncRpcNumber<vspace blankLines="0"/>
+ ipHostNumber<vspace blankLines="0"/>
+ ipNetworkNumber<vspace blankLines="0"/>
+ ipNetmaskNumber<vspace blankLines="0"/>
+ macAddress<vspace blankLines="0"/>
+ bootParameter<vspace blankLines="0"/>
+ bootFile<vspace blankLines="0"/>
+ nisMapName<vspace blankLines="0"/>
+ nisMapEntry<vspace blankLines="0"/>
+ nisPublicKey<vspace blankLines="0"/>
+ nisSecretKey<vspace blankLines="0"/>
+ nisDomain<vspace blankLines="0"/>
+ automountMapName<vspace blankLines="0"/>
+ automountKey<vspace blankLines="0"/>
+ automountInformation<vspace blankLines="0"/>
+ </t>
+ </list>
+ Additionally, some of the attributes defined in
+ <xref target="RFC4519"/> and
+ <xref target="RFC3112"/> are required.
+ </t>
+ </section>
+ <section anchor="attroptions" title="Attribute Option">
+ <t>Centralizing a name service in LDAP allows heterogeneous
+ systems to obtain their information from a single place. However
+ in some cases, this information cannot be used uniformly on all
+ of the client systems. These attribute options are defined to allow
+ system-specific values to be used where necessary. The options
+ are defined as the following:
+ <list style="empty">
+ <t>host-<hostname><vspace blankLines="0"/>
+ hostos-<ostype></t>
+ </list>
+ where hostname is a string representing the name of a specific
+ machine, and ostype is a string representing a particular
+ operating system.</t>
+ <t>For example, a user named "Babs Jensen" may have a different
+ home directory on different machines. This could be represented as:
+ <list style="empty">
+ <t>
+ homeDirectory: /home/babsj<vspace blankLines="0"/>
+ homeDirectory;hostos-sunos: /export/home/bjensen<vspace blankLines="0"/>
+ homeDirectory;host-babshost: /home/root
+ </t>
+ </list></t>
+ <t>These attribute options follow sub-typing semantics. If a DUA
+ requests an attribute to be returned in a search operation, and
+ does not specify an option, all subtypes of that attribute are
+ returned.</t>
+ </section>
+ <section anchor="general.classes" title="Object Classes">
+ <t>The following object classes are defined in this document:
+ <list style="empty">
+ <t>
+ posixAccount<vspace blankLines="0"/>
+ shadowAccount<vspace blankLines="0"/>
+ posixGroup<vspace blankLines="0"/>
+ ipService<vspace blankLines="0"/>
+ ipProtocol<vspace blankLines="0"/>
+ oncRpc<vspace blankLines="0"/>
+ ipHost<vspace blankLines="0"/>
+ ipNetwork<vspace blankLines="0"/>
+ nisNetgroup<vspace blankLines="0"/>
+ nisMap<vspace blankLines="0"/>
+ nisObject<vspace blankLines="0"/>
+ ieee802Device<vspace blankLines="0"/>
+ bootableDevice<vspace blankLines="0"/>
+ nisKeyObject<vspace blankLines="0"/>
+ nisDomainObject<vspace blankLines="0"/>
+ automountMap<vspace blankLines="0"/>
+ automount<vspace blankLines="0"/>
+ </t>
+ </list>
+ Additionally, some of the attributes defined in
+ <xref target="RFC4519"/> are required.
+ </t>
+ </section>
+ </section>
+ </section>
+ <section anchor="attrdefs" title="Attribute Definitions">
+ <t>This section contains attribute definitions to be implemented
+ by DUAs supporting this schema:
+ <figure title="">
+ <artwork>
+ ( 1.3.6.1.1.1.1.0 NAME 'uidNumber'
+ DESC 'An integer uniquely identifying a user in an
+ administrative domain'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.1 NAME 'gidNumber'
+ DESC 'An integer uniquely identifying a group in an
+ administrative domain'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.6 NAME 'shadowMin'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.7 NAME 'shadowMax'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.8 NAME 'shadowWarning'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.9 NAME 'shadowInactive'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.10 NAME 'shadowExpire'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.11 NAME 'shadowFlag'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.12 NAME 'memberUid'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.15 NAME 'ipServicePort'
+ DESC 'Service port number'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber'
+ DESC 'IP protocol number'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.18 NAME 'oncRpcNumber'
+ DESC 'ONC RPC number'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.1.26 NAME 'nisMapName'
+ DESC 'Name of a generic NIS map'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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} )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure></t>
+ </section>
+ <section anchor="classdefs" title="Class Definitions">
+ <t>This section contains class definitions to be implemented by DUAs
+ supporting the schema.</t>
+ <t>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.
+ <figure>
+ <artwork>
+ ( 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 ) )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 ) )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 ) )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ MAY description )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 ) )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 ) )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 ) )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.2.10 NAME 'nisObject' SUP top STRUCTURAL
+ DESC 'An entry in a NIS map'
+ MUST ( cn $ nisMapEntry $ nisMapName )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 ) )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 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 ) )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top AUXILIARY
+ DESC 'Associates a NIS domain with a naming context'
+ MUST nisDomain )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.2.16 NAME 'automountMap' SUP top STRUCTURAL
+ MUST ( automountMapName )
+ MAY description )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.2.17 NAME 'automount' SUP top STRUCTURAL
+ DESC 'Automount information'
+ MUST ( automountKey $ automountInformation )
+ MAY description )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( 1.3.6.1.1.1.2.18 NAME 'groupOfMembers' SUP top STRUCTURAL
+ DESC 'A group with members (DNs)'
+ MUST cn
+ MAY ( businessCategory $ seeAlso $ owner $ ou $ o $
+ description $ member ) )
+ </artwork>
+ </figure></t>
+ </section>
+ <section anchor="impl" title="Implementation Details">
+ <section anchor="impl.res_methods"
+ title="Suggested Resolution Methods">
+ <t>The preferred means of directing a client application (one using
+ the shared services of the C library) to use LDAP as its information
+ source for the functions listed in <xref target="appendixb"/> 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
+ implementations are widely available and the RPC interface is well
+ known.</t>
+ <t>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" (NSS).
+ The means in which the DUA locates LDAP servers is also
+ implementation dependent.</t>
+ </section>
+ <section anchor="impl.interp_user_group"
+ title="Interpreting User and Group Entries">
+ <t>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
+ insensitive. 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.</t>
+ <t>The account object class provides a convenient structural class
+ for posixAccount, and SHOULD be used where additional attributes
+ are not required. Likewise, the groupOfMembers object class
+ SHOULD be used for groups. (The groupOfUniqueNames object class
+ is deprecated and SHOULD NOT be used.)</t>
+ <t>It is suggested that uid and cn are used as the naming attribute
+ for posixAccount and posixGroup entries, respectively. Group members
+ may either be login names (values of memberUid) or distinguished
+ names (values of member). 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 "(objectclass=*)". DUAs MAY wish
+ to cache DN to login name mappings. The DUA MAY traverse nested
+ groups.</t>
+ <t>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.)</t>
+
+ <section title="Using Attribute Options">
+ <t>Some posixAccount attributes may be accompanied by <xref target="attroptions">options</xref>
+ identifying particular hosts or operating system types. The
+ attribute with a hostos option matching the operating system of
+ the DUA SHOULD be used in preference to an attribute without
+ any associated options. The attribute with a host option matching
+ the hostname of the DUA SHOULD be used in preference to any
+ other attribute.</t>
+ </section>
+ <section title="Authentication Considerations">
+ <section title="Using Password Values">
+ <t>When authenticating using a NIS to LDAP gateway or using NSS,
+ a lookup is performed to retrieve the password attribute and
+ the value is used in the DUA to authenticate a user. This
+ approach to authentication is deprecated, as it requires that
+ read access to the password attribute be granted across a
+ network.</t>
+ <t>An entry of class posixAccount, posixGroup, or shadowAccount
+ without 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".</t>
+ <t>If userPassword is used, its values MUST be represented by
+ the following syntax:
+ <figure>
+ <artwork>
+ passwordvalue = schemeprefix hashedpasswd
+ schemeprefix = "{" scheme "}"
+ scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme
+ altscheme = "x-" keystring
+ hashedpasswd = hashed password
+ </artwork>
+ </figure></t>
+ <t>The hashed password contains a plaintext key hashed using
+ the algorithm scheme. If the schema is "sha", the hashed
+ password is the base64 encoding of the SHA-1 digest of the plaintext
+ password.</t>
+ <t>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 hashedpassword is an empty string does the user have no
+ password. DUAs are not required to consider hashing schemes
+ which the client will not recognize; in most cases, it may be
+ sufficient to consider only "crypt".</t>
+ <t>DUA MAY use the authPassword attribute instead of userPassword,
+ defined in <xref target="RFC3112"/>. The DUA MUST iterate the values of the
+ authPassword 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 here, 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 advisable,
+ beyond the scope of this document</t>
+ <t>Below is an example of an authPassword attribute:
+ <figure>
+ <artwork>
+ authPassword: CRYPT$X5/DBrWPOQQaI
+ </artwork>
+ </figure></t>
+ <t>Below is an example of a (deprecated) userPassword attribute:
+ <figure>
+ <artwork>
+ userPassword: {CRYPT}X5/DBrWPOQQaI
+ </artwork>
+ </figure></t>
+ <t>A DUA MAY utilize the attributes in the shadowAccount class to
+ provide 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.</t>
+ </section>
+ <section title="Using LDAP Bind">
+ <t>The preferred method for authenticating users with LDAP is to
+ perform an LDAP Bind operation with the user's name and password.
+ In this case the method the DSA uses to store and verify the password
+ is completely internal to the DSA and not of any concern to the DUA.</t>
+ <t>Likewise, using the shadowAccount attributes requires the DUA to
+ handle password policy enforcement. However the policies expressed
+ in the shadowAccount are limited in scope, and not uniformly
+ applicable to all the systems that will be using LDAP.</t>
+ <t>The preferred method is to leave password policy enforcement
+ to the DSA, so that it will be uniformly enforced across all of
+ the various systems that rely on the directory. This enforcement
+ occurs implicitly when authenticating using LDAP Bind if the
+ DSA supports the
+ <xref target="I-D.behera-ldap-password-policy">LDAP password
+ policy</xref> mechanisms.</t>
+ <t>The means in which authentication in the DUA is configured
+ is implementation dependent. Typically it is accomplished using
+ <xref target="PAM"/>. Further details of authentication are
+ beyond the scope of this document.</t>
+ </section>
+ </section>
+ <section title="Naming Considerations">
+ <t>On UNIX systems, users and groups reside in separate name spaces
+ and it is common for the same name to be used by both a user and a
+ group. Since they are in separate name spaces there is no ambiguity
+ and no conflict. However, when integrating a name service into LDAP
+ the directory may be used with other systems besides UNIX and its
+ derivatives. In particular, the Microsoft Windows operating system
+ may also use LDAP for its own name service. In Windows, users and
+ groups reside in a single name space and so one cannot use the same
+ name for both a user and a group.</t>
+ <t>Conflicts in naming conventions may arise in other deployments
+ as well, and should be carefully taken into account when migrating
+ from other naming services into LDAP.</t>
+ </section>
+ </section>
+ <section anchor="impl.interp_host_net"
+ title="Interpreting Hosts and Networks">
+ <t>The ipHostNumber and ipNetworkNumber attributes are defined in
+ preference to dNSRecord (defined in <xref target="RFC1279"/>), in order to simplify
+ 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.</t>
+ <t>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.
+ Implementations 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.</t>
+ <t>This document redefines, although not exclusively, the ipNetwork
+ class defined in <xref target="RFC1279"/>, in
+ order to achieve consistent naming with ipHost. The ipNetworkNumber
+ attribute is also used in the <xref target="ROSE">siteContact
+ object class</xref>.</t>
+ <t>The authPassword and userPassword attributes are included in
+ ipHost such that hosts MAY be treated as authentication principals.
+ The treatment of these attributes and inherent caveats considered in
+ <xref target="impl.interp_user_group"></xref> apply here also.</t>
+ <t>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 <xref target="RFC2373"/>, section 2.2,
+ item 1. The IPv6 address string MUST be further normalized
+ by following the "::" syntax as defined in
+ <xref target="RFC2373"/>, 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 <xref target="RFC2373"/>, section 2.2, item 3
+ MUST NOT be used. IPv4 addresses MUST be represented by the IPv4
+ dotted decimal string syntax.</t>
+ <t>For example the following address:
+ <figure>
+ <artwork>
+ 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
+ </artwork>
+ </figure>
+ MUST be normalized as:
+ <figure>
+ <artwork>
+ 1080::8:800:200C:417A
+ FF01::101
+ 0::1
+ ::
+ </artwork>
+ </figure></t>
+ </section>
+ <section anchor="impl.interp_other"
+ title="Interpreting Other Entities">
+ <t>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:
+ <figure>
+ <artwork>
+ dn: cn=domain,ou=services,dc=aja,dc=com
+ objectClass: top
+ objectClass: ipService
+ cn: domain
+ cn: nameserver
+ ipServicePort: 53
+ ipServiceProtocol: tcp
+ ipServiceProtocol: udp
+ </artwork>
+ </figure>
+ This entry MUST map to the following two (2) services entities:
+ <figure>
+ <artwork>
+ domain 53/tcp nameserver
+ domain 53/udp nameserver
+ </artwork>
+ </figure>
+ 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+ipServiceProtocol=udp, ...) it is convenient to represent
+ them as a single entry. If a service is represented in multiple
+ protocol domains with different ports, then multiple entries are
+ required; multi-valued RDNs MAY be used to distinguish them.)</t>
+ <t>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.</t>
+ <t>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
+ (nisDomain=%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":
+ <figure>
+ <artwork>
+ dn: dc=aja,dc=com
+ objectClass: top
+ objectClass: domain
+ objectClass: nisDomainObject
+ dc: aja
+ nisDomain: nis.aja.com
+ </artwork>
+ </figure>
+ The nisObject object class MAY be used as a generic means of
+ representing NIS entities. Its use is not encouraged; where support
+ for entities not described in this schema is desired, an appropriate
+ schema should be devised. Implementers are strongly advised to
+ support 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.</t>
+ </section>
+ <section anchor="impl.canon_entries"
+ title="Canonicalizing entries with multi-valued naming attributes">
+ <t>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
+ <xref target="impl.interp_other" /> has the canonical name "domain"
+ and exactly one alias, "nameserver".</t>
+ <t>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 distinguished
+ name. Aliases are thus any values of the distinguishing attribute
+ (such as cn) which do not match the canonical name of the entity.</t>
+ <t>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-distinguished 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.</t>
+ </section>
+ </section>
+ <section anchor="focus" title="Implementation Focus">
+ <t>Gateways between NIS and LDAP have been developed by PADL Software
+ and Sun Microsystems. They both support this schema.</t>
+ <t>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. Another
+ open source implementation of the C library code is available from
+ the OpenLDAP Project.</t>
+ </section>
+ <section anchor="security" title="Security Considerations">
+ <t>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
+ where security is critical SHOULD consider using a strong
+ authentication service for user authentication.</t>
+ <t>Alternatively, the encrypted password could be made available only
+ to a subset of privileged DUAs, which would provide "shadow" password
+ service to client applications. This may be difficult to enforce.</t>
+ <t>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 particularly
+ 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 restrictions 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.</t>
+ <t>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.)</t>
+ <t>Finally, care should be exercised with integer attributes of a
+ sensitive 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,
+ respectively.</t>
+ </section>
+ <section anchor="acks" title="Acknowledgements">
+ <t> Thanks to Bob Joslin of the Hewlett Packard Company, and to all
+ those that helped with this document's predecessor, RFC 2307.</t>
+ <t> UNIX is a registered trademark of The Open Group.</t>
+ </section>
+ </middle>
+ <back>
+ <references>
+ &rfc1034;
+ &rfc1057;
+ &rfc1279;
+ &rfc2373;
+ &rfc2119;
+ &rfc4511;
+ &rfc4515;
+ &rfc4519;
+ &rfc3112;
+ &ppolicy;
+ <reference anchor="ROSE">
+ <front>
+ <title>
+ The Little Black Book: Mail Bonding with OSI Directory Services
+ </title>
+ <author initials="M. T." surname="Rose">
+ <organization abbrev="Prentice-Hall">
+ Prentice-Hall, Inc
+ </organization>
+ </author>
+ <date month="" year="2001"/>
+ </front>
+ <seriesInfo name="ISBN" value="0-13-683210-5"/>
+ </reference>
+ <reference anchor="X.500">
+ <front>
+ <title>
+ Information Processing Systems - Open Systems Interconnection -
+ The Directory: Overview of Concepts, Models and Service
+ </title>
+ <author>
+ <organization>
+ ISO/IEC JTC 1/SC21
+ </organization>
+ </author>
+ <date month="" year="1988"/>
+ </front>
+ </reference>
+ <reference anchor="UNIX">
+ <front>
+ <title>
+ IEEE Std 1003.1, 2004 Edition, Single UNIX Specification Version 3
+ </title>
+ <author>
+ <organization>
+ Institute of Electrical and Electronics Engineers
+ </organization>
+ </author>
+ <author>
+ <organization>
+ The Open Group
+ </organization>
+ </author>
+ <date month="" year="2004" />
+ </front>
+ <seriesInfo name="IEEE" value="Standard 1003.1" />
+ </reference>
+ <reference anchor="PAM">
+ <front>
+ <title>
+ Unified Login with Pluggable Authentication Modules (PAM)
+ </title>
+ <author initials="V." surname="Samar" fullname="Vipin Samar">
+ <organization>SunSoft, Inc.</organization>
+ </author>
+ <author initials="R.J." surname="Schemers"
+ fullname="Roland J. Schemers III">
+ <organization>SunSoft, Inc.</organization>
+ </author>
+ <date month="October" year="1995"/>
+ </front>
+ <seriesInfo name="OSF RFC" value="86.0"/>
+ <format type="TXT" octets="67952"
+ target="http://www.opengroup.org/rfc/mirror-rfc/rfc86.0.txt"/>
+ <format type="HTML" octets="59468"
+ target="http://www.opengroup.org/rfc/rfc86.0.html" />
+ </reference>
+ </references>
+ <section anchor="appendixa" title="Example Entries">
+ <t>The examples described in this section are provided to illustrate
+ the schema described in this draft. They are not meant to be
+ exhaustive.</t>
+ <t>The following entry is an example of the posixAccount class:
+ <figure>
+ <artwork>
+ 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
+ </artwork>
+ </figure>
+ This corresponds to the UNIX system password file entry:
+ <figure>
+ <artwork>
+ lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh
+ </artwork>
+ </figure>
+ The following entry is an example of the ipHost class:
+ <figure>
+ <artwork>
+ 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
+ </artwork>
+ </figure>
+ 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.</t>
+ <t>An example of the nisNetgroup class:
+ <figure>
+ <artwork>
+ 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
+ </artwork>
+ </figure>
+ 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).</t>
+ <t>Finally, an example of the nisObject class:
+ <figure>
+ <artwork>
+ 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
+ nisMapEntry: Nightfly$4
+ </artwork>
+ </figure>
+ This represents the NIS map tracks, and a single map entry.</t>
+ </section>
+ <section anchor="appendixb" title="Affected Library Functions">
+ <t>The following functions are typically found in the C libraries of
+ most <xref target="UNIX">UNIX and POSIX compliant systems</xref>.
+ An <xref target="RFC4515"> LDAP search filter string</xref> 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:
+ <figure>
+ <artwork>
+ 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))
+ getpublickey() (&(objectClass=nisKeyObject)(...))
+ </artwork>
+ </figure></t>
+ </section>
+ <section anchor="appendixc" title="Suggested DIT structure">
+ <t>The cn attribute is typically used to name entities. The
+ ipHostNumber, ipNetworkNumber, and ipServiceProtocol attributes are also
+ naming attributes, such that multi-valued RDNs may be used to
+ distinguish between, for example, different interfaces of a multihomed
+ host.</t>
+ <t>The following DIT structure MAY be used for deploying this schema.
+ It is not required that DC-naming be used, but it is encouraged:
+ <figure>
+ <artwork>
+ 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
+ </artwork>
+ </figure></t>
+ </section>
+ </back>
+</rfc>
projects / openldap / commitdiff