diff options
Diffstat (limited to 'source4/ldap_server/devdocs/rfc2307.txt')
| -rw-r--r-- | source4/ldap_server/devdocs/rfc2307.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/source4/ldap_server/devdocs/rfc2307.txt b/source4/ldap_server/devdocs/rfc2307.txt new file mode 100644 index 0000000000..f46519f127 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc2307.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group L. Howard +Request for Comments: 2307 Independent Consultant +Category: Experimental March 1998 + + + An Approach for Using LDAP as a Network Information Service + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This document describes an experimental 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 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. + +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 + + + +Howard Experimental [Page 1] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + netgroups, booting information (boot parameters and MAC address + mappings), filesystem mounts, IP hosts and networks, and RFC822 mail + aliases. + + 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). (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 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. + +2. General Issues + +2.1. Terminology + + The key words "MUST", "SHOULD", and "MAY" used in this document are + to be interpreted as described in [RFC2119]. + + For the purposes of this document, the term "nameservice" refers to a + service, such as NIS or flat files, that is used by the operating + system to resolve entities within a single, local naming context. + Contrast this with a "directory service" such as LDAP, which supports + extensible schema and multiple naming contexts. + + + + + + +Howard Experimental [Page 2] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + 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. + + 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". + + To avoid confusion, the term "login name" refers to the user's login + name (being the value of the uid attribute) and the term "user ID" + refers to he user's integer identification number (being the value of + the uidNumber attribute). + + The phrases "resolving an entity" and "resolution of entities" refer + respectively to enumerating NIS-related entities of a given type, and + matching them against a given search criterion. One or more entities + are returned as a result of successful "resolutions" (a "match" + operation will only return one entity). + + The use of the term UNIX does not confer upon this schema the + endorsement of owners of the UNIX trademark. Where necessary, the + term "TCP/IP entity" is used to refer to protocols, services, hosts, + and networks, and the term "UNIX entity" to its complement. (The + former category does not mandate the host operating system supporting + the interfaces required for resolving UNIX entities.) + + The OIDs defined below are derived from iso(1) org(3) dod(6) + internet(1) directory(1) nisSchema(1). + +2.2. Attributes + + The attributes and classes defined in this document are summarized + below. + + The following attributes are defined in this document: + + uidNumber + gidNumber + gecos + homeDirectory + + + +Howard Experimental [Page 3] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + loginShell + shadowLastChange + shadowMin + shadowMax + shadowWarning + shadowInactive + shadowExpire + shadowFlag + memberUid + memberNisNetgroup + nisNetgroupTriple + ipServicePort + ipServiceProtocol + ipProtocolNumber + oncRpcNumber + ipHostNumber + ipNetworkNumber + ipNetmaskNumber + macAddress + bootParameter + bootFile + nisMapName + nisMapEntry + + Additionally, some of the attributes defined in [RFC2256] 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 + + Additionally, some of the classes defined in [RFC2256] are required. + + + + + +Howard Experimental [Page 4] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + +2.4. Syntax definitions + + The following syntax definitions [RFC2252] are used by this schema. + The nisNetgroupTripleSyntax represents NIS netgroup triples: + + ( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax' + DESC 'NIS netgroup triple' ) + + Values in this syntax are represented by the following: + + nisnetgrouptriple = "(" hostname "," username "," domainname ")" + hostname = "" / "-" / keystring + username = "" / "-" / keystring + domainname = "" / "-" / keystring + + X.500 servers may use the following representation of the above + syntax: + + nisNetgroupTripleSyntax ::= SEQUENCE { + hostname [0] IA5String OPTIONAL, + username [1] IA5String OPTIONAL, + domainname [2] IA5String OPTIONAL + } + + The bootParameterSyntax syntax represents boot parameters: + + ( nisSchema.0.1 NAME 'bootParameterSyntax' + DESC 'Boot parameter' ) + + where: + + bootparameter = key "=" server ":" path + key = keystring + server = keystring + path = keystring + + X.500 servers may use the following representation of the above + syntax: + + bootParameterSyntax ::= SEQUENCE { + key IA5String, + server IA5String, + path IA5String + } + + Values adhering to these syntaxes are encoded as strings by LDAP + servers. + + + + +Howard Experimental [Page 5] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + +3. Attribute definitions + + This section contains attribute definitions to be implemented by DUAs + supporting this schema. + + ( nisSchema.1.0 NAME 'uidNumber' + DESC 'An integer uniquely identifying a user in an + administrative domain' + EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.1 NAME 'gidNumber' + DESC 'An integer uniquely identifying a group in an + administrative domain' + EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.2 NAME 'gecos' + DESC 'The GECOS field; the common name' + EQUALITY caseIgnoreIA5Match + SUBSTRINGS caseIgnoreIA5SubstringsMatch + SYNTAX 'IA5String' SINGLE-VALUE ) + + ( nisSchema.1.3 NAME 'homeDirectory' + DESC 'The absolute path to the home directory' + EQUALITY caseExactIA5Match + SYNTAX 'IA5String' SINGLE-VALUE ) + + ( nisSchema.1.4 NAME 'loginShell' + DESC 'The path to the login shell' + EQUALITY caseExactIA5Match + SYNTAX 'IA5String' SINGLE-VALUE ) + + ( nisSchema.1.5 NAME 'shadowLastChange' + EQUALITY integerMatch + SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.6 NAME 'shadowMin' + EQUALITY integerMatch + SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.7 NAME 'shadowMax' + EQUALITY integerMatch + SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.8 NAME 'shadowWarning' + EQUALITY integerMatch + SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.9 NAME 'shadowInactive' + + + +Howard Experimental [Page 6] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + EQUALITY integerMatch + SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.10 NAME 'shadowExpire' + EQUALITY integerMatch + SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.11 NAME 'shadowFlag' + EQUALITY integerMatch + SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.12 NAME 'memberUid' + EQUALITY caseExactIA5Match + SUBSTRINGS caseExactIA5SubstringsMatch + SYNTAX 'IA5String' ) + + ( nisSchema.1.13 NAME 'memberNisNetgroup' + EQUALITY caseExactIA5Match + SUBSTRINGS caseExactIA5SubstringsMatch + SYNTAX 'IA5String' ) + + ( nisSchema.1.14 NAME 'nisNetgroupTriple' + DESC 'Netgroup triple' + SYNTAX 'nisNetgroupTripleSyntax' ) + + ( nisSchema.1.15 NAME 'ipServicePort' + EQUALITY integerMatch + SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.16 NAME 'ipServiceProtocol' + SUP name ) + + ( nisSchema.1.17 NAME 'ipProtocolNumber' + EQUALITY integerMatch + SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.18 NAME 'oncRpcNumber' + EQUALITY integerMatch + SYNTAX 'INTEGER' SINGLE-VALUE ) + + ( nisSchema.1.19 NAME 'ipHostNumber' + DESC 'IP address as a dotted decimal, eg. 192.168.1.1, + omitting leading zeros' + EQUALITY caseIgnoreIA5Match + SYNTAX 'IA5String{128}' ) + + ( nisSchema.1.20 NAME 'ipNetworkNumber' + DESC 'IP network as a dotted decimal, eg. 192.168, + + + +Howard Experimental [Page 7] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + omitting leading zeros' + EQUALITY caseIgnoreIA5Match + SYNTAX 'IA5String{128}' SINGLE-VALUE ) + + ( nisSchema.1.21 NAME 'ipNetmaskNumber' + DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, + omitting leading zeros' + EQUALITY caseIgnoreIA5Match + SYNTAX 'IA5String{128}' SINGLE-VALUE ) + + ( nisSchema.1.22 NAME 'macAddress' + DESC 'MAC address in maximal, colon separated hex + notation, eg. 00:00:92:90:ee:e2' + EQUALITY caseIgnoreIA5Match + SYNTAX 'IA5String{128}' ) + + ( nisSchema.1.23 NAME 'bootParameter' + DESC 'rpc.bootparamd parameter' + SYNTAX 'bootParameterSyntax' ) + + ( nisSchema.1.24 NAME 'bootFile' + DESC 'Boot image name' + EQUALITY caseExactIA5Match + SYNTAX 'IA5String' ) + + ( nisSchema.1.26 NAME 'nisMapName' + SUP name ) + + ( nisSchema.1.27 NAME 'nisMapEntry' + EQUALITY caseExactIA5Match + SUBSTRINGS caseExactIA5SubstringsMatch + SYNTAX 'IA5String{1024}' SINGLE-VALUE ) + +4. Class definitions + + This section contains class definitions to be implemented by DUAs + supporting the schema. + + The rfc822MailGroup object class MAY be used to represent a mail + group for the purpose of alias expansion. Several alternative schemes + for mail routing and delivery using LDAP directories, which are + outside the scope of this document. + + ( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY + DESC 'Abstraction of an account with POSIX attributes' + MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) + MAY ( userPassword $ loginShell $ gecos $ description ) ) + + + + +Howard Experimental [Page 8] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + ( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY + DESC 'Additional attributes for shadow passwords' + MUST uid + MAY ( userPassword $ shadowLastChange $ shadowMin + shadowMax $ shadowWarning $ shadowInactive $ + shadowExpire $ shadowFlag $ description ) ) + + ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL + DESC 'Abstraction of a group of accounts' + MUST ( cn $ gidNumber ) + MAY ( userPassword $ memberUid $ description ) ) + + ( nisSchema.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 ) ) + + ( nisSchema.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's canonical name' + MUST ( cn $ ipProtocolNumber $ description ) + MAY description ) + + ( nisSchema.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's canonical name' + MUST ( cn $ oncRpcNumber $ description ) + MAY description ) + + ( nisSchema.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 ( l $ description $ manager ) ) + + ( nisSchema.2.7 NAME 'ipNetwork' SUP top STRUCTURAL + DESC 'Abstraction of a network. The distinguished value of + the cn attribute denotes the network's canonical name' + + + +Howard Experimental [Page 9] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + MUST ( cn $ ipNetworkNumber ) + MAY ( ipNetmaskNumber $ l $ description $ manager ) ) + + ( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL + DESC 'Abstraction of a netgroup. May refer to other netgroups' + MUST cn + MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) + + ( nisSchema.2.09 NAME 'nisMap' SUP top STRUCTURAL + DESC 'A generic abstraction of a NIS map' + MUST nisMapName + MAY description ) + + ( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL + DESC 'An entry in a NIS map' + MUST ( cn $ nisMapEntry $ nisMapName ) + MAY description ) + + ( nisSchema.2.11 NAME 'ieee802Device' SUP top AUXILIARY + DESC 'A device with a MAC address; device SHOULD be + used as a structural class' + MAY macAddress ) + + ( nisSchema.2.12 NAME 'bootableDevice' SUP top AUXILIARY + DESC 'A device with boot parameters; device SHOULD be + used as a structural class' + MAY ( bootFile $ bootParameter ) ) + +5. Implementation details + +5.1. Suggested resolution methods + + The preferred means of directing a client application (one using the + shared services of the C library) to use LDAP as its information + source for the functions listed in 5.2 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". The means in which the + DUA locates LDAP servers is also implementation dependent. + + + + +Howard Experimental [Page 10] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + +5.2. Affected library functions + + The following functions are typically found in the C libraries of + most UNIX and POSIX compliant systems. An LDAP search filter + [RFC2254] which may be used to satisfy the function call is included + alongside each function name. Parameters are denoted by %s and %d for + string and integer arguments, respectively. Long lines are broken. + + getpwnam() (&(objectClass=posixAccount)(uid=%s)) + getpwuid() (&(objectClass=posixAccount) + (uidNumber=%d)) + getpwent() (objectClass=posixAccount) + + getspnam() (&(objectClass=shadowAccount)(uid=%s)) + getspent() (objectClass=shadowAccount) + + getgrnam() (&(objectClass=posixGroup)(cn=%s)) + getgrgid() (&(objectClass=posixGroup) + (gidNumber=%d)) + getgrent() (objectClass=posixGroup) + + getservbyname() (&(objectClass=ipService) + (cn=%s)(ipServiceProtocol=%s)) + getservbyport() (&(objectClass=ipService) + (ipServicePort=%d) + (ipServiceProtocol=%s)) + getservent() (objectClass=ipService) + + getrpcbyname() (&(objectClass=oncRpc)(cn=%s)) + getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d)) + getrpcent() (objectClass=oncRpc) + + getprotobyname() (&(objectClass=ipProtocol)(cn=%s)) + getprotobynumber() (&(objectClass=ipProtocol) + (ipProtocolNumber=%d)) + getprotoent() (objectClass=ipProtocol) + + gethostbyname() (&(objectClass=ipHost)(cn=%s)) + gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s)) + gethostent() (objectClass=ipHost) + + getnetbyname() (&(objectClass=ipNetwork)(cn=%s)) + getnetbyaddr() (&(objectClass=ipNetwork) + (ipNetworkNumber=%s)) + getnetent() (objectClass=ipNetwork) + + setnetgrent() (&(objectClass=nisNetgroup)(cn=%s)) + + + + +Howard Experimental [Page 11] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + +5.3. Interpreting user and group entries + + User and group resolution is initiated by the functions prefixed by + getpw and getgr respectively. The uid attribute contains the user's + login name. The cn attribute, in posixGroup entries, contains the + group's name. + + The account object class provides a convenient structural class for + posixAccount, and SHOULD be used where additional attributes are not + required. + + It is suggested that uid and cn are used as the RDN attribute type + for posixAccount and posixGroup entries, respectively. + + An account's GECOS field is preferably determined by a value of the + gecos attribute. If no gecos attribute exists, the value of the cn + attribute MUST be used. (The existence of the gecos attribute allows + information embedded in the GECOS field, such as a user's telephone + number, to be returned to the client without overloading the cn + attribute. It also accommodates directories where the common name + does not contain the user's full name.) + + An entry of class posixAccount, posixGroup, or shadowAccount without + a userPassword attribute MUST NOT be used for authentication. The + client should be returned a non-matchable password such as "x". + + userPassword values MUST be represented by following syntax: + + passwordvalue = schemeprefix encryptedpassword + schemeprefix = "{" scheme "}" + scheme = "crypt" / "md5" / "sha" / altscheme + altscheme = "x-" keystring + encryptedpassword = encrypted password + + The encrypted password contains of a plaintext key hashed using the + algorithm scheme. + + 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 sufficient to + consider only "crypt". + + Below is an example of a userPassword attribute: + + userPassword: {crypt}X5/DBrWPOQQaI + + + +Howard Experimental [Page 12] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + A future standard may specify LDAP v3 attribute descriptions to + represent hashed userPasswords, as noted below. This schema MUST NOT + be used with LDAP v2 DUAs and DSAs. + + attributetype = attributename sep attributeoption + attributename = "userPassword" + sep = ";" + attributeoption = schemeclass "-" scheme + schemeclass = "hash" / altschemeclass + scheme = "crypt" / "md5" / "sha" / altscheme + altschemeclass = "x-" keystring + altscheme = keystring + + + Below is an example of a userPassword attribute, represented with an + LDAP v3 attribute description: + + userPassword;hash-crypt: X5/DBrWPOQQaI + + + A DUA MAY utilise 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. + +5.4. Interpreting hosts and networks + + 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. + + 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 Experimental [Page 13] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + The trailing zeros in a network address MUST be omitted. CIDR-style + network addresses (eg. 192.168.1/24) MAY be used. + + Hosts with IPv6 addresses MUST be written in their "preferred" form + as defined in section 2.2.1 of [RFC1884], such that all components of + the address are indicated and leading zeros are omitted. This + provides a consistent means of resolving ipHosts by address. + +5.5. Interpreting other entities + + In general, a one-to-one mapping between entities and LDAP entries is + proposed, in that each entity has exactly one representation in the + DIT. In some cases this is not feasible; for example, a service which + is represented in more than one protocol domain. Consider the + following entry: + + dn: cn=domain, dc=aja, dc=com + cn: domain + cn: nameserver + objectClass: top + objectClass: ipService + ipServicePort: 53 + ipServiceProtocol: tcp + ipServiceProtocol: udp + + This entry MUST map to the following two (2) services entities: + + domain 53/tcp nameserver + domain 53/udp nameserver + + While the above two entities may be represented as separate LDAP + entities, with different distinguished names (such as + cn=domain+ipServiceProtocol=tcp, ... and + cn=domain+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; multivalued RDNs may be used to distinguish them.) + + With the exception of userPassword values, which are parsed according + to the syntax considered in section 5.2, any 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 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 + + + +Howard Experimental [Page 14] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + schema should be devised. Implementors 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.) + +5.6. 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.5 has the canonical + name "domain" and exactly one alias, "nameserver". + + The schema in this document generally only defines one attribute per + class which is suitable for distinguishing an entity (excluding any + attributes with integer syntax; it is assumed that entries will be + distinguished on name). Usually, this is the common name (cn) + attribute. This aids the DUA in determining the canonical name of an + entity, as it can examine the value of the relative 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. + +6. Implementation focus + + A NIS server which uses LDAP instead of local files has been + developed which supports the schema defined in this document. + + A reference implementation of the C library resolution code has been + written for the Free Software Foundation. It may support other C + libraries which support the Name Service Switch (NSS) or the + Information Retrieval Service (IRS). + + The author has made available a freely distributable set of scripts + which parses local databases such as /etc/passwd and /etc/hosts into + a form suitable for loading into an LDAP server. + + + + + +Howard Experimental [Page 15] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + +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. + + 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. + + 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 + 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. + +8. Acknowledgements + + Thanks to Leif Hedstrom of Netscape Communications Corporation, + Michael Grant and Rosanna Lee of Sun Microsystems Inc., Ed Reed of + Novell Inc., and Mark Wahl of Critical Angle Inc. for their valuable + contributions to the development of this schema. Thanks to Andrew + Josey of The Open Group for clarifying the use of the UNIX trademark, + and to Tim Howes and Peter J. Cherny for their support. + + + +Howard Experimental [Page 16] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + 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. + + [RFC1279] + Kille, S., "X.500 and Domains", RFC 1279, November 1991. + + [RFC1884] + Hinden, R., and S. Deering, "IP Version 6 Addressing + Architecture", RFC 1884, December 1995. + + [RFC2119] + Bradner, S., "Key Words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [RFC2251] + Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access + Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] + Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight + Directory Access Protocol (v3): Attribute Syntax Definitions", + RFC 2252, December 1997. + + [RFC2254] + Howes, T., "The String Representation of LDAP Search Filters", + RFC 2254, December 1997. + + [RFC2256] + Wahl, M., "A Summary of the X.500(96) User Schema for use with + LDAPv3", RFC 2256, December 1997. + + [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. + + + + + + +Howard Experimental [Page 17] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + [XOPEN] + ISO/IEC 9945-1:1990, Information Technology - Portable Operating + Systems Interface (POSIX) - Part 1: Systems Application + Programming Interface (API) [C Language] + +10. Author's Address + + Luke Howard + PO Box 59 + Central Park Vic 3145 + Australia + + EMail: lukeh@xedoc.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Howard Experimental [Page 18] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + +A. Example entries + + The examples described in this section are provided to illustrate the + schema described in this memo. They are not meant to be exhaustive. + + The following entry is an example of the posixAccount class: + + dn: uid=lester, dc=aja, dc=com + objectClass: top + objectClass: account + objectClass: posixAccount + uid: lester + cn: Lester the Nightfly + userPassword: {crypt}X5/DBrWPOQQaI + gecos: Lester + loginShell: /bin/csh + uidNumber: 10 + gidNumber: 10 + homeDirectory: /home/lester + + + This corresponds the UNIX system password file entry: + + lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh + + The following entry is an example of the ipHost class: + + dn: cn=peg.aja.com, dc=aja, dc=com + objectClass: top + objectClass: device + objectClass: ipHost + objectClass: bootableDevice + objectClass: ieee802Device + cn: peg.aja.com + cn: www.aja.com + ipHostNumber: 10.0.0.1 + macAddress: 00:00:92:90:ee:e2 + bootFile: mach + bootParameter: root=fs:/nfsroot/peg + bootParameter: swap=fs:/nfsswap/peg + bootParameter: dump=fs:/nfsdump/peg + + This entry represents the host canonically peg.aja.com, also known as + www.aja.com. The Ethernet address and four boot parameters are also + specified. + + + + + + +Howard Experimental [Page 19] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + + An example of the nisNetgroup class: + + dn: cn=nightfly, 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 entry represents the NIS map tracks, and a single map entry. + + + + + + + + + + + + + + + + + + + + + +Howard Experimental [Page 20] + +RFC 2307 Using LDAP as a Network Information Service March 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Howard Experimental [Page 21] + |