idnits 2.17.1 draft-howard-nis-schema-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 367: '... MUST ( cn $ uid $ uidNumber ...' RFC 2119 keyword, line 368: '... MAY ( userPassword $ loginSh...' RFC 2119 keyword, line 372: '... MUST uid...' RFC 2119 keyword, line 373: '... MAY ( userPassword $ shadowL...' RFC 2119 keyword, line 379: '... MUST ( cn $ gidNumber )...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 667 has weird spacing: '... 53/tcp names...' == Line 668 has weird spacing: '... 53/udp names...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (12 September 1997) is 9716 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '7' is defined on line 844, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1779 (ref. '10') (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 1884 (ref. '15') (Obsoleted by RFC 2373) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Application Working Group L. Howard 2 INTERNET-DRAFT Independent Consultant 3 Expires in six months from 12 September 1997 4 Intended Category: Experimental 6 An Approach for Using LDAP as a Network Information Service 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced, or made obsolete by 18 other documents at any time. It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Distribution of this document is unlimited. 30 Abstract 32 This document describes an experimental mechanism for mapping 33 entities related to TCP/IP and the UNIX system into X.500 entries so 34 that they may be resolved with the Lightweight Directory Access 35 Protocol [1]. A set of attribute types and object classes are 36 proposed, along with specific guidelines for interpreting them. 38 The intention is to assist the deployment of LDAP as an 39 organizational nameservice. No proposed solutions are intended as 40 standards for the Internet. Rather, it is hoped that a general 41 consensus will emerge as to the appropriate solution to such 42 problems, leading eventually to the adoption of standards. The 43 proposed mechanism has already been implemented with some success. 45 1. Background and Motivation 47 The UNIX (R) operating system, and its derivatives (specifically, 48 those which support TCP/IP and conform to the X/Open Single UNIX 49 specification [13]) require a means of looking up entities, by 50 matching them against search criteria or by enumeration. (Other 51 operating systems that support TCP/IP may provide some means of 52 resolving some of these entities. This schema is applicable to those 53 environments also.) 55 These entities include users, groups, IP services (which map names to 56 IP ports and protocols, and vice versa), IP protocols (which map 57 names to IP protocol numbers and vice versa), RPCs (which map names 58 to ONC Remote Procedure Call [12] numbers and vice versa), NIS 59 netgroups, booting information (boot parameters and MAC address 60 mappings), filesystem mounts, IP hosts and networks, and RFC822 mail 61 aliases. 63 Resolution requests are made through a set of C functions, provided 64 in the UNIX system's C library. For example, the UNIX system utility 65 'ls', which enumerates the contents of a filesystem directory, uses 66 the C library function getpwuid(3c) in order to map user IDs to login 67 names. Once the request is made, it is resolved using a 'nameservice' 68 which is supported by the client library. The nameservice may be, at 69 its simplest, a collection of files in the local filesystem which are 70 opened and searched by the C library. Other common nameservices 71 include the Network Information Service (NIS) and the Domain Name 72 System (DNS). (The latter is typically only used for resolving hosts, 73 services and networks.) Both these nameservices have the advantage of 74 being distributed and thus permitting a common set of entities to be 75 shared amongst many clients. 77 LDAP is a distributed, hierarchical directory service access protocol 78 which is used to access repositories of users and other network- 79 related entities. Because LDAP is usually not tightly integrated with 80 the operating system, information such as users needs to be kept both 81 in LDAP and in an operating system supported nameservice such as NIS. 82 By using LDAP as the the primary means of resolving these entities, 83 these redundancy issues are minimized and the scalability of LDAP can 84 be exploited. (By comparison, NIS services based on flat files do not 85 have the scalability or extensibility of LDAP or X.500.) 87 "In general, it is advantageous for different network 88 applications and services to refer to the directory for 89 user account information, rather than each service keeping 90 its own collection of user account records, which requires 91 the network administrator to separately create or destroy 92 user entities, passwords, etc., in many different systems 93 each time a user joins or leaves the organization." [4] 95 The object classes and attributes defined below are suitable for 96 representing the aforementioned entities in a form compatible with 97 LDAP and X.500 directory services. While the schema is by no means 98 deemed to be authoritative, it is considered desirable to have a 99 single, open schema rather than the proliferation of multiple 100 proprietary schema. This document is one step towards such a schema. 102 2. General Issues 104 2.1. Terminology 106 In this document, the term 'NIS-related entities' is used rather 107 loosely to refer to those entities (described in the previous 108 section) which are typically represented in the Network Information 109 Service. (NIS was previously known as Yellow Pages, or YP.) It should 110 not be inferred from this that deploying LDAP for resolving such 111 entities (nisObject excluded) requires NIS to be used, as a gateway 112 or otherwise. The host and network classes are generically 113 applicable, and may be implemented on operating systems other than 114 the UNIX system that wish to use LDAP to resolve these entities. 116 The 'DUA' (directory user agent) refers to the LDAP client querying 117 these entities, such as an LDAP to NIS gateway or the C library. The 118 'client' refers to the application which ultimately makes use of the 119 information returned by the resolution. It is irrelevant whether the 120 DUA and the client reside within the same address space. The act of 121 the DUA making this information to the client is termed 122 'republishing'. 124 To avoid confusion, the term 'login name' refers to the user's login 125 name (being the value of the uid attribute) and the term 'user ID' 126 refers to he user's integer identification number (being the value of 127 the uidNumber attribute). The term 'principal' is used to 128 distinguish accounts that may be used for authentication from those 129 that are not. 131 The term 'nameservice' refers to a service, such as NIS or flat 132 files, that is used by the operating system to resolve entities 133 within a single, local naming context. Contrast this with a 134 'directory service' such as LDAP, which support extensible schema and 135 multiple naming contexts. 137 The phrase 'resolving an entity' or 'resolution of entities' refers 138 to enumerating NIS-related entities of a given type, or matching them 139 against a given search criterion. One or more entities are returned 140 as a result of successful 'resolutions' (a 'match' operation will 141 only return one entity). 143 The use of the term UNIX does not confer upon this schema the 144 endorsement of owners of the UNIX trademark. Where necessary, the 145 term 'TCP/IP entity' is used to refer to protocols, services, hosts, 146 and networks, and the term 'UNIX entity' to its complement. (The 147 former category does not mandate the host operating system supporting 148 the interfaces required for resolving UNIX entities.) 150 The OIDs defined below are rooted at iso(1) org(3) dod(6) internet(1) 151 directory(1) nisSchema(1). 153 2.2. Attributes 155 The attributes and classes defined in this document are summarized 156 below. The reader is referred to [2] for the BFN for attribute type 157 definitions. 159 The following attributes are defined in this document: 161 uidNumber 162 gidNumber 163 gecos 164 homeDirectory 165 loginShell 166 shadowLastChange 167 shadowMin 168 shadowMax 169 shadowWarning 170 shadowInactive 171 shadowExpire 172 shadowFlag 173 memberUid 174 memberNisNetgroup 175 nisNetgroupTriple 176 ipServicePort 177 ipServiceProtocol 178 ipProtocolNumber 179 oncRpcNumber 180 ipHostNumber 181 ipNetworkNumber 182 ipNetmaskNumber 183 macAddress 184 bootParameter 185 bootFile 186 automountInformation 187 nisMapName 188 nisMapEntry 190 Additionally, the attributes defined in [2], [9] and [16] are 191 imported. 193 2.3. Object classes 195 The reader is referred to [2] for the BFN for object class 196 definition. 198 The following object classes are defined in this document: 200 posixAccount 201 shadowAccount 202 posixGroup 203 ipService 204 ipProtocol 205 oncRpc 206 ipHost 207 ipNetwork 208 nisNetgroup 209 automount 210 nisObject 212 Additionally, the classes defined in [2] and [9] are imported. 214 2.4. Syntax definitions 216 The following syntax definition [2] is used in representing NIS 217 netgroup triples. 219 ( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax' 220 DESC 'NIS netgroup triple' ) 222 Values in this syntax are encoded according to the following BNF: 224 nisnetgrouptriple = "(" hostname "," username "," domainname ")" 225 hostname = "" / "-" / keystring 226 username = "" / "-" / keystring 227 domainname = "" / "-" / keystring 229 3. Attribute definitions 231 This section contains attribute definitions which must be implemented 232 by DUAs supporting the schema. 234 ( nisSchema.1.0 NAME 'uidNumber' 235 DESC 'An integer uniquely identifying a user in an 236 administrative domain' 238 EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) 240 ( nisSchema.1.1 NAME 'gidNumber' 241 DESC 'An integer uniquely identifying a group in an 242 administrative domain' 243 EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) 245 ( nisSchema.1.2 NAME 'gecos' 246 DESC 'The GECOS field, including the user's common name' 247 EQUALITY caseIgnoreIA5Match 248 SUBSTRINGS caseIgnoreIA5SubstringsMatch 249 SYNTAX 'IA5String' SINGLE-VALUE ) 251 ( nisSchema.1.3 NAME 'homeDirectory' 252 DESC 'The absolute path of the user's home directory' 253 EQUALITY caseExactIA5Match 254 SYNTAX 'IA5String' SINGLE-VALUE ) 256 ( nisSchema.1.4 NAME 'loginShell' 257 DESC 'The absolute path of the user's shell' 258 EQUALITY caseExactIA5Match 259 SYNTAX 'IA5String' SINGLE-VALUE ) 261 ( nisSchema.1.5 NAME 'shadowLastChange' EQUALITY integerMatch 262 SYNTAX 'INTEGER' SINGLE-VALUE ) 264 ( nisSchema.1.6 NAME 'shadowMin' EQUALITY integerMatch 265 SYNTAX 'INTEGER' SINGLE-VALUE ) 267 ( nisSchema.1.7 NAME 'shadowMax' EQUALITY integerMatch 268 SYNTAX 'INTEGER' SINGLE-VALUE ) 270 ( nisSchema.1.8 NAME 'shadowWarning' EQUALITY integerMatch 271 SYNTAX 'INTEGER' SINGLE-VALUE ) 273 ( nisSchema.1.9 NAME 'shadowInactive' EQUALITY integerMatch 274 SYNTAX 'INTEGER' SINGLE-VALUE ) 276 ( nisSchema.1.10 NAME 'shadowExpire' EQUALITY integerMatch 277 SYNTAX 'INTEGER' SINGLE-VALUE ) 279 ( nisSchema.1.11 NAME 'shadowFlag' EQUALITY integerMatch 280 SYNTAX 'INTEGER' SINGLE-VALUE ) 282 ( nisSchema.1.12 NAME 'memberUid' EQUALITY caseExactIA5Match 283 SUBSTRINGS caseExactIA5SubstringsMatch 284 SYNTAX 'IA5String{128}' ) 286 ( nisSchema.1.13 NAME 'memberNisNetgroup' EQUALITY caseExactIA5Match 287 SUBSTRINGS caseExactIA5SubstringsMatch 288 SYNTAX 'IA5String' ) 290 ( nisSchema.1.14 NAME 'nisNetgroupTriple' 291 DESC 'Netgroup triple' SYNTAX 'nisNetgroupTripleSyntax' ) 293 ( nisSchema.1.15 NAME 'ipServicePort' EQUALITY integerMatch 294 SYNTAX 'INTEGER' SINGLE-VALUE ) 296 ( nisSchema.1.16 NAME 'ipServiceProtocol' EQUALITY caseIgnoreIA5Match 297 SYNTAX 'IA5String' ) 299 ( nisSchema.1.17 NAME 'ipProtocolNumber' EQUALITY integerMatch 300 SYNTAX 'INTEGER' SINGLE-VALUE ) 302 ( nisSchema.1.18 NAME 'oncRpcNumber' EQUALITY integerMatch 303 SYNTAX 'INTEGER' SINGLE-VALUE ) 305 ( nisSchema.1.19 NAME 'ipHostNumber' 306 DESC 'IP address in dotted decimal notation, eg. 192.168.1.1' 307 EQUALITY caseIgnoreIA5Match 308 SYNTAX 'IA5String{128}' ) 310 ( nisSchema.1.20 NAME 'ipNetworkNumber' 311 DESC 'IP address in dotted decimal notation, eg. 192.168' 312 EQUALITY caseIgnoreIA5Match 313 SYNTAX 'IA5String{128}' ) 315 ( nisSchema.1.21 NAME 'ipNetmaskNumber' 316 DESC 'IP address in dotted decimal notation, eg. 255.255.255.0' 317 EQUALITY caseIgnoreIA5Match 318 SYNTAX 'IA5String{128}' ) 320 ( nisSchema.1.22 NAME 'macAddress' 321 DESC 'MAC address in colon-separated hex notation, for 322 example 0:0:92:90:ee:e2' 323 EQUALITY caseIgnoreIA5Match 324 SYNTAX 'IA5String{128}' ) 326 ( nisSchema.1.23 NAME 'bootParameter' 327 DESC 'rpc.bootparamd parameter; informal syntax is key=value' 328 EQUALITY caseExactIA5Match 329 SYNTAX 'IA5String' ) 331 ( nisSchema.1.24 NAME 'bootFile' 332 DESC 'name of the boot image, which may be used by bootpd. 333 Alternatively, this may specified as a value of 334 bootParameter.' 335 EQUALITY caseExactIA5Match 336 SYNTAX 'IA5String' ) 338 ( nisSchema.1.25 NAME 'automountInformation' 339 DESC 'An entry in an automount map.' 340 EQUALITY caseExactIA5Match 341 SUBSTRINGS caseExactIA5SubstringsMatch 342 SYNTAX 'IA5String' ) 344 ( nisSchema.1.26 NAME 'nisMapName' 345 EQUALITY caseExactIA5Match 346 SUBSTRINGS caseExactIA5SubstringsMatch 347 SYNTAX 'IA5String{1024}' SINGLE-VALUE ) 349 ( nisSchema.1.27 NAME 'nisMapEntry' 350 EQUALITY caseExactIA5Match 351 SUBSTRINGS caseExactIA5SubstringsMatch 352 SYNTAX 'IA5String{1024}' SINGLE-VALUE ) 354 4. Class definitions 356 This section contains class definitions which must be implemented by 357 DUAs supporting the schema. 359 The definitions under the OID 2.5.6 are imported. The rfc822MailGroup 360 object class may used to represent a mail group for the purpose of 361 alias expansion. (Several alternative schemes for mail routing and 362 delivery using LDAP directories have been proposed [4]; these issues 363 will not be considered in detail here.) 365 ( nisSchema.2.0 NAME 'posixAccount' SUP top STRUCTURAL 366 DESC 'Abstraction of an account with POSIX attributes.' 367 MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) 368 MAY ( userPassword $ loginShell $ gecos $ description ) ) 370 ( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY 371 DESC 'Additional attributes for shadow passwords.' 372 MUST uid 373 MAY ( userPassword $ shadowLastChange $ shadowMin 374 shadowMax $ shadowWarning $ shadowInactive $ 375 shadowExpire $ shadowFlag $ description ) ) 377 ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL 378 DESC 'Abstraction of a group of posixAccounts.' 379 MUST ( cn $ gidNumber ) 380 MAY ( userPassword $ memberUid $ description ) ) 382 ( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL 383 DESC 'Abstraction an Internet Protocol service. Maps an IP 384 port and protocol (eg. tcp or udp) to one or more names. 385 The distinguished value of the cn attribute denotes the 386 service's canonical name.' 387 MUST ( cn $ ipServicePort $ ipServiceProtocol ) 388 MAY description ) 390 ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL 391 DESC 'Abstraction of an IP protocol. Maps a protocol number to 392 one or more names. The distinguished value of the cn 393 attribute denotes the protocol's canonical name.' 394 MUST ( cn $ ipProtocolNumber $ description ) 395 MAY description ) 397 ( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL 398 DESC 'Abstraction of an Open Network Computing (ONC) [12] 399 Remote Procedure Call (RPC) binding. Maps an ONC RPC 400 number to a name. The distinguished value of the cn 401 attribute denotes the RPC service's canonical name.' 402 MUST ( cn $ oncRpcNumber $ description ) 403 MAY description ) 405 ( nisSchema.2.6 NAME 'ipHost' SUP top STRUCTURAL 406 DESC 'Abstraction of a host. The schema defined in [3] is used 407 to denote the canonical hostname, by mapping the 408 distinguished name into a DNS domain name. 409 The associatedDomain attribute is used for interrogating 410 the DIT, and as such must contain values for the host's 411 canonical name and its aliases.' 412 MUST ( dc $ ipHostNumber $ associatedDomain ) 413 MAY ( macAddress $ bootParameter $ bootFile $ 414 l $ description $ manager $ serialNumber ) ) 416 ( nisSchema.2.7 NAME 'ipNetwork' SUP top 417 STRUCTURAL 418 DESC 'Abstraction of a network.' 419 MUST ( dc $ ipNetworkNumber $ associatedDomain ) 420 MAY ( ipNetmaskNumber $ l $ description $ manager ) ) 422 ( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL 423 DESC 'Abstraction of a netgroup. May refer to other netgroups.' 424 MUST cn 425 MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) 427 ( nisSchema.2.9 NAME 'automount' SUP top STRUCTURAL 428 DESC 'Abstraction of an automount map; each entry in the map 429 is represented by a value of the automountInformation 430 attribute. The map name is given by the cn attribute. 431 Each value of the automountInformation attribute 432 constitutes a mount entry.' 433 MUST cn 434 MAY ( automountInformation $ description ) ) 436 ( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL 437 DESC 'Abstraction of a generic NIS map or entry.' 438 MUST nisMapName 439 MAY ( cn $ nisMapEntry $ description ) ) 441 5. Implementation details 443 5.1. Resolution methods 445 The ideal means of directing a client application (one using the 446 shared services of the C library) to use LDAP as its information 447 source for the functions listed in 5.2 is to modify the source code 448 to directly query LDAP. As the source code to commercial C libraries 449 and applications is rarely available to the end-user, it is 450 acceptable to emulate a supported nameservice (such as NIS) and 451 modify the resolution code to use LDAP. (This is also an appropriate 452 opportunity to perform caching of entries across client address 453 spaces.) In the case of NIS, reference implementations are widely 454 available and the client-server RPC interface is well known. 456 There exists no standard mechanism, other than NIS, for resolving 457 automount and nisObject entries. The former may be supported by the 458 automounter itself; both classes should be supported by an LDAP to 459 NIS gateway. However, an implementation which claims to conform to 460 this specification is not required to support these classes. (To 461 mandate otherwise would exclude implementations integrated with the C 462 library.) 464 Some operating systems and C libraries support end-user extensible 465 resolvers using dynamically loadable libraries and a nameservice 466 "switch". Others allow end-user defined symbols to be substituted at 467 runtime. Regardless, the means by which the operating system is 468 directed to use LDAP is implementation dependent, as is the means by 469 which the DUA locates LDAP servers. (It is anticipated that the 470 Dynamic Host Configuration Protocol (DHCP) may be used for the latter 471 [16].) 473 5.2. Affected resolver calls 474 The following entry points are found in the C libraries of most UNIX 475 and POSIX compliant systems. An LDAP search filter [5] which may be 476 used to satisfy the function call is included alongside each function 477 name, with printf(3s) format notation used to denote the function 478 parameter(s), if any. Generally, those functions in section 3n of the 479 UNIX system's manual pages refer to TCP/IP entries, and those in 480 section 3c refer to the remainder. Long lines are broken with the '\' 481 character. 483 getpwnam(3c) (&(objectClass=posixAccount)(uid=%s)) 484 getpwuid(3c) (&(objectClass=posixAccount)\ 485 (uidNumber=%d)) 486 getpwent(3c) (objectClass=posixAccount) 488 getspnam(3c) (&(objectClass=shadowAccount)(uid=%s)) 489 getspent(3c) (objectclass=shadowAccount) 491 getgrnam(3c) (&(objectClass=posixGroup)(cn=%s)) 492 getgrgid(3c) (&(objectClass=posixGroup)\ 493 (gidNumber=%d)) 494 getgrent(3c) (objectClass=posixGroup) 496 getservbyname(3n) (&(objectClass=ipService)\ 497 (cn=%s)(ipServiceProtocol=%s)) 498 getservbyport(3n) (&(objectClass=ipService)\ 499 (ipServicePort=%d)\ 500 (ipServiceProtocol=%s)) 501 getservent(3n) (objectClass=ipService) 503 getrpcbyname(3n) (&(objectClass=oncRpc)(cn=%s)) 504 getrpcbynumber(3n) (&(objectClass=oncRpc)(oncRpcNumber=%d)) 505 getrpcent(3n) (objectClass=oncRpc) 507 getprotobyname(3n) (&(objectClass=ipProtocol)(cn=%s)) 508 getprotobynumber(3n) (&(objectClass=ipProtocol)\ 509 (ipProtocolNumber=%d)) 510 getprotoent(3n) (objectClass=ipProtocol) 512 gethostbyname(3n) (&(objectClass=ipHost)\ 513 (associatedDomain=%s)) 514 gethostbyaddr(3n) (&(objectClass=ipHost)(ipHostNumber=%s)) 515 gethostent(3n) (objectClass=ipHost) 517 getnetbyname(3n) (&(objectClass=ipNetwork)\ 518 (associatedDomain=%s)) 519 getnetbyaddr(3n) (&(objectClass=ipNetwork)\ 520 (ipNetworkNumber=%s)) 521 getnetent(3n) (objectClass=ipNetwork) 522 setnetgrent(3n) (&(objectClass=nisNetgroup)(cn=%s)) 524 getaliasbyname(3n) (&(objectClass=rfc822MailGroup)(cn=%s)) 525 getaliasent(3n) (objectClass=rfc822MailGroup) 527 5.3. Interpreting user and group entries 529 User and group resolution is initiated by the functions prefixed by 530 getpw and getgr respectively. A user's login name is denoted by the 531 value of the uid attribute (which will typically be used as a 532 relative distinguished name); a group's name is denoted by a value of 533 the cn attribute. 535 An account's GECOS field is preferably determined by a value of the 536 gecos attribute. If no gecos attribute exists, the value of the cn 537 attribute must be used. (The existence of the gecos attribute allows 538 attributes embedded in the GECOS field, such as a user's telephone 539 number, to be returned to the client without overloading the cn 540 attribute.) 542 An entry of class posixAccount or shadowAccount without a 543 userPassword attribute must be denied the opportunity to 544 authenticate. For example, the client may be returned a non-matchable 545 password such as "*" by the DUA. 547 A user which is a member of a posixGroup which has no userPassword 548 attribute must not be allowed to authenticate themself as a member of 549 that group, unless the user's gidNumber attribute implies a user has 550 the same group ID (in which case the operating system may determine 551 this implicitly). 553 userPassword values must be represented by following BNF syntax: 555 passwordvalue = schemeprefix encryptedpassword 556 schemeprefix = "{" scheme "}" 557 scheme = "crypt" / "md5" / "sha" / altscheme 558 altscheme = keystring 559 encryptedpassword = encrypted password 561 (where the encrypted password consists of a plaintext key encrypted 562 using appropriate encoding algorithm; for example, crypt(3) with a 563 two-character random salt for "crypt") 565 userPassword values which do not adhere to the BNF above must not be 566 used for authentication. (The DUA must iterate through the values of 567 the attribute until a value matching the above BNF is found.) Only if 568 encryptedPassword is an empty string does the user have no password. 570 DUAs are not required to consider encryption schemes which the client 571 will not recognise; in many cases, it may be sufficient to consider 572 only "crypt". 574 A future document may use LDAP v3 attribute descriptions to represent 575 hashed userPasswords, as in the following: 577 attributetype = attributename sep attributeoption 578 attributename = "userPassword" 579 sep = ";" 580 attributeoption = schemeclass "-" scheme 581 schemeclass = "hash" / altschemeclass 582 scheme = "crypt" / "md5" / "sha" / altscheme 583 altschemeclass = keystring 584 altscheme = keystring 586 For example, consider the attribute: 588 userPassword;hash-crypt: X5/DBrWPOQQaI 590 which would otherwise be represented as 592 userPassword: {crypt}X5/DBrWPOQQaI. 594 A DUA may make use of the attributes in the shadowAccount class to 595 provide shadow password service (getspnam(3c) and getspent(3c)). In 596 such cases, the DUA must not make use of the userPassword attribute 597 for getpwnam(3c) et al, and must return a non-matchable password 598 (such as "x") to the client instead. 600 5.4. Interpreting hosts and networks 602 The means for representing DNS [6] domains in LDAP distinguished 603 names described in [3] and [9] is used in part to represent TCP/IP 604 hosts and networks in LDAP. 606 Note the use of the ipHostNumber attribute instead of the dNSRecord 607 attribute. The rationale is that, in order to minimize the 608 responsibility placed on the DUA, attribute values ought to directly 609 contain the information they seek to represent. This contrasts with, 610 for example, a dNSRecord value which expresses a complete DNS 611 resource record including time to live and class data. It is 612 considered that this information is extraneous to using LDAP as a 613 direct means to resolve hosts and networks. Additionally, it is 614 considered more appropriate for an entity, and all its aliases, to be 615 represented by a single entry in the DIT, which is not always 616 possible when a DNS resource record is mapped directly to an LDAP 617 entry. 619 This document redefines (although not to the extent of excluding the 620 existing definition) the ipNetwork class defined in [3], for naming 621 consistency with ipHost. The ipNetworkNumber attribute is also used 622 in the siteContact object class [14]. (The trailing zeros in a 623 network address should be omitted.) CIDR-style network addresses (eg. 624 192.168.1/24) can be used but this is not required. 626 If an entry of class ipHost or ipNetwork belongs to a naming context 627 denoted by relative distinguished names (RDNs) [10] of attribute type 628 dc (domainComponent), then the distinguished name (DN) is transformed 629 into a domain name system (DNS) suffix by concatenating each RDN 630 value with a period ('.'). 632 For example, an entry of class ipHost with a DN of dc=foo, dc=bar, 633 dc=edu or dc=foo, dc=bar, dc=edu, o=Internet is parsed into the host 634 name foo.bar.edu. If the naming context is does not contain 'dc' 635 values, a non-qualified host name is returned. For organizations 636 which wish to use existing X.500 container classes to form their 637 context (ie. organization and organizationalUnit) the RDN values of 638 unrequired type are skipped by the DUA in determining the domain 639 name. As such, a DN of dc=foo, dc=bar, dc=edu, o=Ace Industry, c=US 640 may be parsed as foo.bar.edu. As this may be considered a naming 641 violation, this document does not specifically endorse this. 643 Hosts with IPv6 addresses should be written in their "preferred" form 644 as defined in section 2.2.1 of [15], such that all components of the 645 address are indicated and leading zeros are omitted. This is to 646 provide a consistent means of resolving ipHosts by address. 648 5.5. Interpreting other entities 650 In general, a one-to-one mapping between entities and LDAP entries is 651 proposed, in that each entity has exactly one representation in the 652 DIT. In some cases this is not feasible; for example, a service which 653 is represented in more than one protocol domain. Consider the 654 following entry: 656 dn: cn=domain, dc=aceindustry, dc=com 657 cn: domain 658 cn: nameserver 659 objectClass: top 660 objectClass: ipService 661 ipServicePort: 53 662 ipServiceProtocol: tcp 663 ipServiceProtocol: udp 665 This entry would map to the following two (2) services entities: 667 domain 53/tcp nameserver 668 domain 53/udp nameserver 670 While the above two entities could have been equally represented as 671 separate LDAP entities, with different distinguished names (such as 672 cn=domain+ipServiceProtocol=tcp, ... and 673 cn=domain+ipServiceProtocol=udp, ...) it is considered that 674 representing them as a single entry is more convenient. (If a service 675 is represented in multiple protocol domains with different respective 676 ports, then multiple entries are mandatory, with multivalued RDNs 677 being used to distinguish between them.) 679 Entries of class automount inherently represent more than one entity: 680 each value of the automountInformation attribute is a NIS record. 682 With the exception of userPassword values, which must be parsed 683 according to the BNF considered in section 5.2, any empty values 684 (those that consist of a zero length string) are returned by the DUA 685 to the client. The client may not make sense of them, but this 686 situation is no different to parsing files which contain empty 687 fields. (By contrast, the DUA must reject any entries which do not 688 conform to the schema, ie. are missing certain mandatory attributes. 689 Non-conforming entries should be ignored while enumerating entries; 690 whether the enumeration is terminated at such an entry is 691 implementation dependent, although it is strongly suggested that the 692 offending entry be treated as if it were not present.) 694 The nisObject object class is provided as a generic means of 695 representing NIS entities. Its use is not encouraged; where support 696 for entities not described in this schema is desired, an appropriate 697 schema should be devised. Implementors are strongly advised to 698 support end-user extensible mappings between NIS entities and object 699 classes. The nisObject class may be useful were one to use LDAP to 700 query a NIS server, although it is anticipated that the converse will 701 be more common. (Where the nisObject class is used, the nisMapName 702 attribute may establish part of the DN, to assist the DUA in locating 703 entries belonging to a particular map.) 705 Entries which inherit also from the cacheObject object class (and 706 thus contain the 'ttl' attribute) may be used by DUAs to perform 707 cache validation. [17] 709 5.6. Canonicalizing entries with multi-valued naming attributes 710 For entities such as services, protocols, and RPCs, where there may 711 be one or more aliases, the respective entry's relative distinguished 712 name is used to form the canonical name. Any other values for the 713 same attribute are used as aliases. For example, the service 714 described in section 5.5 has the canonical name 'domain' and exactly 715 one alias, 'nameserver'. 717 The schema in this document generally only defines one attribute per 718 class which is suitable for distinguishing an entity (excluding any 719 attributes with integer syntax; it is assumed that entries will be 720 distinguished based on name). Usually, this is the common name (cn) 721 attribute. (For users, either the cn or uid attributes may be used 722 to canonicalize an entry. For hosts and networks, the entire 723 distinguished name is considered, as per section 5.4.) This fact aids 724 the DUA in determining the canonical name of an entity: it can simply 725 examine the value of the relative distinguished name. Aliases are 726 thus any values of the distinguishing attribute (such as cn) which do 727 not match the canonical name of the entity. 729 In the event that a different attribute is used to distinguish the 730 entry, as may be the case with conforming entries that belong to 731 additional object classes, it is possible that the entity's canonical 732 name cannot be deduced from the RDN. In this situation, the DUA must 733 choose one of the non-distinguished values to represent the entity's 734 canonical name. Because the directory server guarantees no ordering 735 of attribute values, attempting to distinguish an entry in a 736 deterministic fashion may require the DUA to maintain a mapping 737 between entries' DNs and their canonical names as considered by the 738 DUA. This document does not require this, nor does it advocate that 739 such situations be resolved by mapping one DIT entry into multiple 740 entities. 742 6. Implementation focus 744 A NIS daemon which uses LDAP instead of local files has been 745 developed which supports the schema defined in this document. A set 746 of extensions to a particular implementation of the Mach operating 747 system has also been developed, which sidesteps NIS and uses LDAP 748 directly. 750 Work is underway to develop a freely available (under the GNU General 751 Library Public License) reference implementation of the C library 752 resolution code that supports LDAP using the draft schema. The code 753 will be compatible with the Free Software Foundation's GNU C library 754 and other C libraries which support the Name Service Switch (NSS) or 755 Information Retrieval Service (IRS). 757 The alias lookup functions referred to in section 5.2 are presently 758 available only in the GNU C library, and (albeit with different 759 names) in the C library of one commercial UNIX system vendor. It is 760 anticipated that the mail transport agent (MTA) will typically 761 consult LDAP or NIS directly instead of using the C library; however, 762 support for the suggested library calls is encouraged. 764 The author has made available a freely distributable set of Perl 765 scripts for parsing configuration files such as /etc/passwd and 766 /etc/hosts and generating LDIF data suitable for preparing an LDIF 767 database, as well as a set of Java classes for generating flat files 768 from the DIT. 770 7. Security considerations 772 The entirety of related security considerations are outside the scope 773 of this document. However, it should be noted that making passwords 774 encrypted with a widely understood one way function (such as 775 crypt(3)) available to non-privileged users is potentially dangerous 776 because it exposes them to dictionary and brute-force attacks. It is 777 proposed only for compatibility with existing UNIX system 778 implementations. Sites where security is critical may consider using 779 Kerberos or another authentication service for logins. A variation on 780 this is to authenticate to an LDAP server by binding over an 781 encrypted connection (such as SSL [8]). 783 Alternatively, the encrypted password could be made available only to 784 a subset of privileged DUAs, which would provide 'shadow' password 785 service to client applications. 787 Because the schema represents operating system-level entities, access 788 to these entities should be granted on a discretionary basis. (That 789 said, there is little point in restricting access to data which will 790 be republished without restriction, eg. by a NIS server.) It is 791 particularly important that only administrators can modify entries 792 defined in this schema, with the exception of allowing a principal to 793 change their password (which may be done on behalf of the user by a 794 client bound as a superior principal, such that password restrictions 795 may be enforced). For example, if a user were allowed to change the 796 value of their uidNumber attribute, they could subvert security by 797 equivalencing their account with the root account. 799 A subtree of the DIT which is to be republished by a DUA (such as a 800 NIS gateway) should be within the same administrative domain that the 801 republishing DUA represents. (For example, principals outside an 802 organization, while conceivably part of the DIT, should not be 803 considered with the same degree of authority as those within the 804 organization.) 805 Finally, care should be exercised with integer attributes of a 806 sensitive nature (particularly the uidNumber and gidNumber 807 attributes) which contain zero-length values. It may be wiser to 808 treat such values as corresponding to the "nobody" or "nogroup" user 809 and group, respectively. 811 8. Acknowledgements 813 Thanks to Leif Hedstrom of Netscape Communications Corporation, 814 Rosanna Lee of Sun Microsystems Inc., and Mark Wahl of Critical Angle 815 Inc. for their valuable contributions to the development of this 816 schema. Thanks to Andrew Josey of The Open Group for clarifying the 817 use of the UNIX trademark. 819 UNIX is a registered trademark of The Open Group. 821 9. References 823 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 824 Protocol (Version 3)", INTERNET-DRAFT , June 1997. 827 [2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 828 Protocol: Standard and Pilot Attribute Definitions", INTERNET- 829 DRAFT , June 1997. 831 [3] S. Kille, "X.500 and Domains", RFC 1279, November 1991. 833 [4] H. Lachman, "LDAP-based Routing of SMTP Messages: Approach Used 834 by Netscape", INTERNET-DRAFT , March 1997. 837 [5] T. Howes, "A String Representation of LDAP Search Filters", 838 INTERNET-DRAFT , March 839 1997. See also [10]. 841 [6] P. Mockapetris, "Domain names - concepts and facilities", RFC 842 1034, November 1987. 844 [7] "Information Processing Systems - Open Systems Interconnection - 845 The Directory: Overview of Concepts, Models and Service", 846 ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. 848 [8] A. O. Freier, P. Karlton, P. Kocher, "The SSL Protocol, Version 849 3.0", INTERNET-DRAFT 850 November 1996. 852 [9] S. Kille, M. Wahl, "An Approach for Using Domains in LDAP 853 Distinguished 855 Names", INTERNET-DRAFT , 856 July 1996. 858 [10] S. Kille, "A String Representation of Distinguished Names", RFC 859 1779, March 1995. 861 [11] G. Good, "The LDAP Data Interchange Format (LDIF)", INTERNET- 862 DRAFT , November 1996. 864 [12] Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol 865 Specification Version 2", RFC 1057, June 1988. 867 [13] ISO/IEC 9945-1:1990, Information Technology - Portable Operating 868 Systems Interface (POSIX) - Part 1: Systems Application 869 Programming Interface (API) [C Language] 871 [14] M. T. Rose, "The Little Black Book: Mail Bonding with OSI 872 Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc., 873 1992. 875 [15] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 876 RFC 1884, December 1995. 878 [16] L. Hedstrom, L. Howard, "DHCP Options for LDAP", INTERNET-DRAFT 879 , July 1997. 881 [17] T. Howes, L. Howard, "A Simple Caching Scheme for LDAP and X.500 882 Directories", INTERNET-DRAFT , July 1997. 885 10. Author's Address 887 Luke Howard 888 PO Box 59 889 Central Park Vic 3145 890 Australia 891 Email: lukeh@xedoc.com 893 A. Example entries 895 The examples described in this section are provided to illustrate the 896 schema described in this draft. They are not an authoritative 897 reference. Entries are presented in LDIF notation [11]. 899 The following entry is an example of the posixAccount class: 901 dn: uid=lukeh, dc=aceindustry, dc=com 902 cn: Luke Howard 903 objectClass: top 904 objectClass: person 905 objectClass: posixAccount 906 sn: Howard 907 telephoneNumber: +61 3 9428 0788 908 uid: lukeh 909 userPassword: {crypt}X5/DBrWPOQQaI 910 gecos: Luke Howard 911 loginShell: /bin/csh 912 uidNumber: 10 913 gidNumber: 10 914 homeDirectory: /home/lukeh 916 This corresponds the UNIX system password file entry: 918 lukeh:X5/DBrWPOQQaI:10:10:Luke Howard:/home/lukeh:/bin/sh 920 Note that the userPassword value is parsed into a password suitable 921 for matching with crypt(3). Attributes such as telephoneNumber and sn 922 (which belong to classes other than posixAccount), are not used in 923 determining the corresponding password file entry but may be useful 924 to other LDAP clients. (In most cases, entries of class posixAccount 925 will also inherit from person or organizationalPerson.) 927 The following entry is an example of the ipHost class: 929 dn: dc=yoyo, dc=aceindustry, dc=com 930 dc: yoyo 931 objectClass: top 932 objectClass: ipHost 933 objectClass: domainRelatedObject 934 associatedDomain: yoyo.aceindustry.com 935 associatedDomain: www.aceindustry.com 936 ipHostNumber: 10.0.0.1 937 macAddress: 0:0:92:90:ee:e2 938 bootParameter: bootfile=mach 939 bootParameter: root=fs:/nfsroot/yoyo 940 bootParameter: swap=fs:/nfsswap/yoyo 941 bootParameter: dump=fs:/nfsdump/yoyo 943 This entry represents the host yoyo.aceindustry.com, also known as 944 www.aceindustry.com. Note that the associatedDomain values are used 945 in searching for the entry, but the distinguished name is parsed to 946 determine the host's canonical name. The MAC address, boot image, and 947 two boot parameters are also specified in this entry. The auxilary 948 class domainRelatedObject is not mandatory. (Thus, the NIS maps 949 prefixed by 'hosts', 'ethers', and 'bootparams' could all be derived 950 from similar entries.) 952 An example of the nisNetgroup class: 954 dn: cn=nightfly, dc=aceindustry, dc=com 955 cn: nightfly 956 objectClass: top 957 objectClass: nisNetgroup 958 nisNetgroupTriple: (fagen,peg,dunes.aceindustry.com) 959 nisNetgroupTriple: (becker,-,) 960 memberNisNetgroup: kamakiriad 962 This entry represents the netgroup nightfly, which contains two 963 triples (the user fagen, the host peg, and the domain 964 dunes.aceindustry.com; and, the user becker, no host, and any domain) 965 and one netgroup (kamakiriad). 967 Finally, an example of the nisObject class: 969 dn: nisMapName=quote.byname, dc=dunes, dc=aceindustry, dc=com 970 objectClass: top 971 objectClass: nisObject 972 nisMapName: quote.byname 974 dn: cn=foobar, nisMapName=quote.byname, dc=dunes, dc=aceindustry, dc=com 975 objectClass: top 976 objectClass: nisObject 977 objectClass: cacheObject 978 ttl: 86400 979 cn: foobar 980 nisMapName: quote.byname 981 nisMapEntry: 75.00 983 This entry represents the NIS map quote.byname, and a constitutent 984 entry, with the key of foobar and a value of 75.00. The latter entry 985 has a time-to-live of 24 hours.