idnits 2.17.1 draft-howard-nis-schema-03.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-26) 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 19 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 20 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([LDAPV3], [X500]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 645 has weird spacing: '... 53/tcp names...' == Line 646 has weird spacing: '... 53/udp names...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (6 January 1998) is 9607 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'X500' is mentioned on line 34, but not defined == Missing Reference: 'LDAPV3' is mentioned on line 36, but not defined == Missing Reference: 'ROSE' is mentioned on line 616, but not defined == Missing Reference: 'LDIF' is mentioned on line 839, but not defined == Unused Reference: 'RFC1034' is defined on line 773, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 801, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Application Working Group L. Howard 3 INTERNET-DRAFT Independent Consultant 4 Expires in six months from 6 January 1998 5 Intended Category: Experimental 7 An Approach for Using LDAP as a Network Information Service 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months. Internet-Drafts may be updated, replaced, or made obsolete by 19 other documents at any time. It is not appropriate to use Internet- 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Distribution of this document is unlimited. 31 Abstract 33 This document describes an experimental mechanism for mapping 34 entities related to TCP/IP and the UNIX system into X.500 [X500] 35 entries so that they may be resolved with the Lightweight Directory 36 Access Protocol [LDAPV3]. A set of attribute types and object classes 37 are proposed, along with specific guidelines for interpreting them. 39 The intention is to assist the deployment of LDAP as an 40 organizational nameservice. No proposed solutions are intended as 41 standards for the Internet. Rather, it is hoped that a general 42 consensus will emerge as to the appropriate solution to such 43 problems, leading eventually to the adoption of standards. The 44 proposed mechanism has already been implemented with some success. 46 1. Background and Motivation 48 The UNIX (R) operating system, and its derivatives (specifically, 49 those which support TCP/IP and conform to the X/Open Single UNIX 50 specification [XOPEN]) require a means of looking up entities, by 51 matching them against search criteria or by enumeration. (Other 52 operating systems that support TCP/IP may provide some means of 53 resolving some of these entities. This schema is applicable to those 54 environments also.) 56 These entities include users, groups, IP services (which map names to 57 IP ports and protocols, and vice versa), IP protocols (which map 58 names to IP protocol numbers and vice versa), RPCs (which map names 59 to ONC Remote Procedure Call [RFC1057] numbers and vice versa), NIS 60 netgroups, booting information (boot parameters and MAC address 61 mappings), filesystem mounts, IP hosts and networks, and RFC822 mail 62 aliases. 64 Resolution requests are made through a set of C functions, provided 65 in the UNIX system's C library. For example, the UNIX system utility 66 "ls", which enumerates the contents of a filesystem directory, uses 67 the C library function getpwuid() in order to map user IDs to login 68 names. Once the request is made, it is resolved using a "nameservice" 69 which is supported by the client library. The nameservice may be, at 70 its simplest, a collection of files in the local filesystem which are 71 opened and searched by the C library. Other common nameservices 72 include the Network Information Service (NIS) and the Domain Name 73 System (DNS). (The latter is typically used for resolving hosts, 74 services and networks.) Both these nameservices have the advantage of 75 being distributed and thus permitting a common set of entities to be 76 shared amongst many clients. 78 LDAP is a distributed, hierarchical directory service access protocol 79 which is used to access repositories of users and other network- 80 related entities. Because LDAP is often not tightly integrated with 81 the host operating system, information such as users may need to be 82 kept both in LDAP and in an operating system supported nameservice 83 such as NIS. By using LDAP as the the primary means of resolving 84 these entities, these redundancy issues are minimized and the 85 scalability of LDAP can be exploited. (By comparison, NIS services 86 based on flat files do not have the scalability or extensibility of 87 LDAP or X.500.) 89 The object classes and attributes defined below are suitable for 90 representing the aforementioned entities in a form compatible with 91 LDAP and X.500 directory services. 93 2. General Issues 94 2.1. Terminology 96 The key words "MUST", "SHOULD", and "MAY" used in this document are 97 to be interpreted as described in [RFC2119]. 99 For the purposes of this document, the term "nameservice" refers to a 100 service, such as NIS or flat files, that is used by the operating 101 system to resolve entities within a single, local naming context. 102 Contrast this with a "directory service" such as LDAP, which supports 103 extensible schema and multiple naming contexts. 105 The term "NIS-related entities" broadly refers to entities which are 106 typically resolved using the Network Information Service. (NIS was 107 previously known as YP.) Deploying LDAP for resolving these entities 108 does not imply that NIS be used, as a gateway or otherwise. In 109 particular, the host and network classes are generically applicable, 110 and may be implemented on any system that wishes to use LDAP or X.500 111 for host and network resolution. 113 The "DUA" (directory user agent) refers to the LDAP client querying 114 these entities, such as an LDAP to NIS gateway or the C library. The 115 "client" refers to the application which ultimately makes use of the 116 information returned by the resolution. It is irrelevant whether the 117 DUA and the client reside within the same address space. The act of 118 the DUA making this information to the client is termed 119 "republishing". 121 To avoid confusion, the term "login name" refers to the user's login 122 name (being the value of the uid attribute) and the term "user ID" 123 refers to he user's integer identification number (being the value of 124 the uidNumber attribute). 126 The phrases "resolving an entity" and "resolution of entities" refer 127 respectively to enumerating NIS-related entities of a given type, and 128 matching them against a given search criterion. One or more entities 129 are returned as a result of successful "resolutions" (a "match" 130 operation will only return one entity). 132 The use of the term UNIX does not confer upon this schema the 133 endorsement of owners of the UNIX trademark. Where necessary, the 134 term "TCP/IP entity" is used to refer to protocols, services, hosts, 135 and networks, and the term "UNIX entity" to its complement. (The 136 former category does not mandate the host operating system supporting 137 the interfaces required for resolving UNIX entities.) 139 The OIDs defined below are derived from iso(1) org(3) dod(6) 140 internet(1) directory(1) nisSchema(1). 142 2.2. Attributes 144 The attributes and classes defined in this document are summarized 145 below. 147 The following attributes are defined in this document: 149 uidNumber 150 gidNumber 151 gecos 152 homeDirectory 153 loginShell 154 shadowLastChange 155 shadowMin 156 shadowMax 157 shadowWarning 158 shadowInactive 159 shadowExpire 160 shadowFlag 161 memberUid 162 memberNisNetgroup 163 nisNetgroupTriple 164 ipServicePort 165 ipServiceProtocol 166 ipProtocolNumber 167 oncRpcNumber 168 ipHostNumber 169 ipNetworkNumber 170 ipNetmaskNumber 171 macAddress 172 bootParameter 173 bootFile 174 automountInformation 175 nisMapName 176 nisMapEntry 178 Additionally, some of the attributes defined in [RFC2256] are 179 required. 181 2.3. Object classes 183 The following object classes are defined in this document: 185 posixAccount 186 shadowAccount 187 posixGroup 188 ipService 189 ipProtocol 190 oncRpc 191 ipHost 192 ipNetwork 193 nisNetgroup 194 automount 195 nisObject 197 Additionally, some of the classes defined in [RFC2256] are required. 199 2.4. Syntax definitions 201 The following syntax definitions [RFC2252] are used by this schema. 202 The nisNetgroupTripleSyntax represents NIS netgroup triples: 204 ( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax' 205 DESC 'NIS netgroup triple' ) 207 Values in this syntax are represented by the following: 209 nisnetgrouptriple = "(" hostname "," username "," domainname ")" 210 hostname = "" / "-" / keystring 211 username = "" / "-" / keystring 212 domainname = "" / "-" / keystring 214 The bootParameterSyntax syntax represents boot parameters: 216 ( nisSchema.0.1 NAME 'bootParameterSyntax' 217 DESC 'Boot parameter' ) 219 where: 221 bootparameter = key "=" value 222 key = keystring 223 value = keystring 225 Values adhering to these syntaxes are encoded as strings. 227 3. Attribute definitions 229 This section contains attribute definitions to be implemented by DUAs 230 supporting this schema. 232 ( nisSchema.1.0 NAME 'uidNumber' 233 DESC 'An integer uniquely identifying a user in an 234 administrative domain' 235 EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) 237 ( nisSchema.1.1 NAME 'gidNumber' 238 DESC 'An integer uniquely identifying a group in an 239 administrative domain' 240 EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) 242 ( nisSchema.1.2 NAME 'gecos' 243 DESC 'The GECOS field; the common name' 244 EQUALITY caseIgnoreIA5Match 245 SUBSTRINGS caseIgnoreIA5SubstringsMatch 246 SYNTAX 'IA5String' SINGLE-VALUE ) 248 ( nisSchema.1.3 NAME 'homeDirectory' 249 DESC 'The absolute path to the home directory' 250 EQUALITY caseExactIA5Match 251 SYNTAX 'IA5String' SINGLE-VALUE ) 253 ( nisSchema.1.4 NAME 'loginShell' 254 DESC 'The path to the login shell' 255 EQUALITY caseExactIA5Match 256 SYNTAX 'IA5String' SINGLE-VALUE ) 258 ( nisSchema.1.5 NAME 'shadowLastChange' 259 EQUALITY integerMatch 260 SYNTAX 'INTEGER' SINGLE-VALUE ) 262 ( nisSchema.1.6 NAME 'shadowMin' 263 EQUALITY integerMatch 264 SYNTAX 'INTEGER' SINGLE-VALUE ) 266 ( nisSchema.1.7 NAME 'shadowMax' 267 EQUALITY integerMatch 268 SYNTAX 'INTEGER' SINGLE-VALUE ) 270 ( nisSchema.1.8 NAME 'shadowWarning' 271 EQUALITY integerMatch 272 SYNTAX 'INTEGER' SINGLE-VALUE ) 274 ( nisSchema.1.9 NAME 'shadowInactive' 275 EQUALITY integerMatch 276 SYNTAX 'INTEGER' SINGLE-VALUE ) 278 ( nisSchema.1.10 NAME 'shadowExpire' 279 EQUALITY integerMatch 280 SYNTAX 'INTEGER' SINGLE-VALUE ) 282 ( nisSchema.1.11 NAME 'shadowFlag' 283 EQUALITY integerMatch 284 SYNTAX 'INTEGER' SINGLE-VALUE ) 286 ( nisSchema.1.12 NAME 'memberUid' 287 EQUALITY caseExactIA5Match 288 SUBSTRINGS caseExactIA5SubstringsMatch 289 SYNTAX 'IA5String' ) 291 ( nisSchema.1.13 NAME 'memberNisNetgroup' 292 EQUALITY caseExactIA5Match 293 SUBSTRINGS caseExactIA5SubstringsMatch 294 SYNTAX 'IA5String' ) 296 ( nisSchema.1.14 NAME 'nisNetgroupTriple' 297 DESC 'Netgroup triple' 298 SYNTAX 'nisNetgroupTripleSyntax' ) 300 ( nisSchema.1.15 NAME 'ipServicePort' 301 EQUALITY integerMatch 302 SYNTAX 'INTEGER' SINGLE-VALUE ) 304 ( nisSchema.1.16 NAME 'ipServiceProtocol' 305 EQUALITY caseIgnoreIA5Match 306 SYNTAX 'IA5String' ) 308 ( nisSchema.1.17 NAME 'ipProtocolNumber' 309 EQUALITY integerMatch 310 SYNTAX 'INTEGER' SINGLE-VALUE ) 312 ( nisSchema.1.18 NAME 'oncRpcNumber' 313 EQUALITY integerMatch 314 SYNTAX 'INTEGER' SINGLE-VALUE ) 316 ( nisSchema.1.19 NAME 'ipHostNumber' 317 DESC 'IP address as a dotted decimal, eg. 192.168.1.1, 318 omitting leading zeros.' 319 EQUALITY caseIgnoreIA5Match 320 SYNTAX 'IA5String{128}' ) 322 ( nisSchema.1.20 NAME 'ipNetworkNumber' 323 DESC 'IP network as a dotted decimal, eg. 192.168, 324 omitting leading zeros' 325 EQUALITY caseIgnoreIA5Match 326 SYNTAX 'IA5String{128}' SINGLE-VALUE ) 328 ( nisSchema.1.21 NAME 'ipNetmaskNumber' 329 DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, 330 omitting leading zeros' 331 EQUALITY caseIgnoreIA5Match 332 SYNTAX 'IA5String{128}' SINGLE-VALUE ) 334 ( nisSchema.1.22 NAME 'macAddress' 335 DESC 'MAC address in maximal, colon separated hex 336 notation, eg. 00:00:92:90:ee:e2.' 337 EQUALITY caseIgnoreIA5Match 338 SYNTAX 'IA5String{128}' ) 340 ( nisSchema.1.23 NAME 'bootParameter' 341 DESC 'rpc.bootparamd parameter' 342 SYNTAX 'bootParameterSyntax' ) 344 ( nisSchema.1.24 NAME 'bootFile' 345 DESC 'Boot image name' 346 EQUALITY caseExactIA5Match 347 SYNTAX 'IA5String' ) 349 ( nisSchema.1.25 NAME 'automountInformation' 350 DESC 'An entry in an automount map' 351 EQUALITY caseExactIA5Match 352 SUBSTRINGS caseExactIA5SubstringsMatch 353 SYNTAX 'IA5String' ) 355 ( nisSchema.1.26 NAME 'nisMapName' 356 EQUALITY caseExactIA5Match 357 SUBSTRINGS caseExactIA5SubstringsMatch 358 SYNTAX 'IA5String{1024}' SINGLE-VALUE ) 360 ( nisSchema.1.27 NAME 'nisMapEntry' 361 EQUALITY caseExactIA5Match 362 SUBSTRINGS caseExactIA5SubstringsMatch 363 SYNTAX 'IA5String{1024}' SINGLE-VALUE ) 365 4. Class definitions 367 This section contains class definitions to be implemented by DUAs 368 supporting the schema. 370 The rfc822MailGroup object class MAY be used to represent a mail 371 group for the purpose of alias expansion. Several alternative schemes 372 for mail routing and delivery using LDAP directories, which are 373 outside the scope of this document. 375 ( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY 376 DESC 'Abstraction of an account with POSIX attributes.' 377 MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) 378 MAY ( userPassword $ loginShell $ gecos $ description ) ) 380 ( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY 381 DESC 'Additional attributes for shadow passwords.' 382 MUST uid 383 MAY ( userPassword $ shadowLastChange $ shadowMin 384 shadowMax $ shadowWarning $ shadowInactive $ 385 shadowExpire $ shadowFlag $ description ) ) 387 ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL 388 DESC 'Abstraction of a group of accounts.' 389 MUST ( cn $ gidNumber ) 390 MAY ( userPassword $ memberUid $ description ) ) 392 ( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL 393 DESC 'Abstraction an Internet Protocol service. 394 Maps an IP port and protocol (such as tcp or udp) 395 to one or more names. 396 The distinguished value of the cn attribute denotes 397 the service's canonical name.' 398 MUST ( cn $ ipServicePort $ ipServiceProtocol ) 399 MAY ( description ) ) 401 ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL 402 DESC 'Abstraction of an IP protocol. Maps a protocol number 403 to one or more names. The distinguished value of the cn 404 attribute denotes the protocol's canonical name.' 405 MUST ( cn $ ipProtocolNumber $ description ) 406 MAY description ) 408 ( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL 409 DESC 'Abstraction of an Open Network Computing (ONC) 410 [RFC1057] Remote Procedure Call (RPC) binding. 411 This class maps an ONC RPC number to a name. 412 The distinguished value of the cn attribute denotes 413 the RPC service's canonical name.' 414 MUST ( cn $ oncRpcNumber $ description ) 415 MAY description ) 417 ( nisSchema.2.6 NAME 'ipHost' SUP top STRUCTURAL 418 DESC 'Abstraction of a host. See section 5.4.' 419 MUST ( ipHostNumber $ cn ) 420 MAY ( macAddress $ bootParameter $ bootFile $ l $ 421 description $ manager $ serialNumber ) ) 423 ( nisSchema.2.7 NAME 'ipNetwork' SUP top 424 STRUCTURAL 425 DESC 'Abstraction of a network. See section 5.4.' 426 MUST ( ipNetworkNumber $ cn ) 427 MAY ( ipNetmaskNumber $ l $ description $ manager ) ) 429 ( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL 430 DESC 'Abstraction of a netgroup. May refer to other netgroups.' 431 MUST cn 432 MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) 434 ( nisSchema.2.9 NAME 'automount' SUP top STRUCTURAL 435 DESC 'Abstraction of an automount map; each entry in the map 436 is represented by a value of the automountInformation 437 attribute. The map name is given by the cn attribute. 438 Each value of the automountInformation attribute 439 constitutes a mount entry.' 440 MUST cn 441 MAY ( automountInformation $ description ) ) 443 ( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL 444 DESC 'Abstraction of a generic NIS map or entry.' 445 MUST nisMapName 446 MAY ( cn $ nisMapEntry $ description ) ) 448 5. Implementation details 450 5.1. Suggested resolution methods 452 The preferred means of directing a client application (one using the 453 shared services of the C library) to use LDAP as its information 454 source for the functions listed in 5.2 is to modify the source code 455 to directly query LDAP. As the source to commercial C libraries and 456 applications is rarely available to the end-user, one could emulate a 457 supported nameservice (such as NIS). (This is also an appropriate 458 opportunity to perform caching of entries across process address 459 spaces.) In the case of NIS, reference implementations are widely 460 available and the RPC interface is well known. 462 There exists no standard mechanism, other than NIS, for resolving 463 automount and nisObject entries. The former may be supported by the 464 automounter itself; both classes SHOULD be supported by an LDAP to 465 NIS gateway. Generally, the DUA SHOULD support all the classes 466 defined herein as is practicable. 468 The means by which the operating system is directed to use LDAP is 469 implementation dependent. For example, some operating systems and C 470 libraries support end-user extensible resolvers using dynamically 471 loadable libraries and a nameservice "switch". The means in which the 472 DUA locates LDAP servers is also implementation dependent. 474 5.2. Affected library functions 475 The following functions are typically found in the C libraries of 476 most UNIX and POSIX compliant systems. An LDAP search filter 477 [RFC2254] which may be used to satisfy the function call is included 478 alongside each function name. Parameters are denoted by %s and %d for 479 string and integer arguments, respectively. Long lines are broken. 481 getpwnam() (&(objectClass=posixAccount)(uid=%s)) 482 getpwuid() (&(objectClass=posixAccount) 483 (uidNumber=%d)) 484 getpwent() (objectClass=posixAccount) 486 getspnam() (&(objectClass=shadowAccount)(uid=%s)) 487 getspent() (objectClass=shadowAccount) 489 getgrnam() (&(objectClass=posixGroup)(cn=%s)) 490 getgrgid() (&(objectClass=posixGroup) 491 (gidNumber=%d)) 492 getgrent() (objectClass=posixGroup) 494 getservbyname() (&(objectClass=ipService) 495 (cn=%s)(ipServiceProtocol=%s)) 496 getservbyport() (&(objectClass=ipService) 497 (ipServicePort=%d) 498 (ipServiceProtocol=%s)) 499 getservent() (objectClass=ipService) 501 getrpcbyname() (&(objectClass=oncRpc)(cn=%s)) 502 getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d)) 503 getrpcent() (objectClass=oncRpc) 505 getprotobyname() (&(objectClass=ipProtocol)(cn=%s)) 506 getprotobynumber() (&(objectClass=ipProtocol) 507 (ipProtocolNumber=%d)) 508 getprotoent() (objectClass=ipProtocol) 510 gethostbyname() (&(objectClass=ipHost)(cn=%s)) 511 gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s)) 512 gethostent() (objectClass=ipHost) 514 getnetbyname() (&(objectClass=ipNetwork)(cn=%s)) 515 getnetbyaddr() (&(objectClass=ipNetwork) 516 (ipNetworkNumber=%s)) 517 getnetent() (objectClass=ipNetwork) 519 setnetgrent() (&(objectClass=nisNetgroup)(cn=%s)) 521 getaliasbyname() (&(objectClass=rfc822MailGroup)(cn=%s)) 522 getaliasent() (objectClass=rfc822MailGroup) 524 5.3. Interpreting user and group entries 526 User and group resolution is initiated by the functions prefixed by 527 getpw and getgr respectively. The uid attribute contains the user's 528 login name. The cn attribute, in posixGroup entries, contains the 529 group's name. 531 The account object class provides a convenient structural class for 532 posixAccount, and SHOULD be used where additional attributes are not 533 required. 535 It is suggested that uid and cn are used as the RDN attribute type 536 for posixAccount and posixGroup entries, respectively. 538 An account's GECOS field is preferably determined by a value of the 539 gecos attribute. If no gecos attribute exists, the value of the cn 540 attribute MUST be used. (The existence of the gecos attribute allows 541 information embedded in the GECOS field, such as a user's telephone 542 number, to be returned to the client without overloading the cn 543 attribute. It also accommodates directories where the common name 544 does not contain the user's full name.) 546 An entry of class posixAccount, posixGroup, or shadowAccount without 547 a userPassword attribute MUST NOT be used for authentication. The 548 client should be returned a non-matchable password such as "x". 550 userPassword values MUST be represented by following syntax: 552 passwordvalue = schemeprefix encryptedpassword 553 schemeprefix = "{" scheme "}" 554 scheme = "crypt" / "md5" / "sha" / altscheme 555 altscheme = "x-" keystring 556 encryptedpassword = encrypted password 558 The encrypted password contains of a plaintext key hashed using the 559 algorithm scheme. 561 userPassword values which do not adhere to this syntax MUST NOT be 562 used for authentication. The DUA MUST iterate through the values of 563 the attribute until a value matching the above syntax is found. Only 564 if encryptedpassword is an empty string does the user have no 565 password. DUAs are not required to consider encryption schemes which 566 the client will not recognize; in most cases, it may be sufficient to 567 consider only "crypt". 569 Below is an example of a userPassword attribute: 571 userPassword: {crypt}X5/DBrWPOQQaI 573 A future standard may specify LDAP v3 attribute descriptions to 574 represent hashed userPasswords, as noted below. This schema MUST NOT 575 be used with LDAP v2 DUAs and DSAs. 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 = "x-" keystring 584 altscheme = keystring 586 Below is an example of a userPassword attribute, represented with an 587 LDAP v3 attribute description: 589 userPassword;hash-crypt: X5/DBrWPOQQaI 591 A DUA MAY utilise the attributes in the shadowAccount class to 592 provide shadow password service (getspnam() and getspent()). In such 593 cases, the DUA MUST NOT make use of the userPassword attribute for 594 getpwnam() et al, and MUST return a non-matchable password (such as 595 "x") to the client instead. 597 5.4. Interpreting hosts and networks 599 The ipHostNumber and ipNetworkNumber attributes are defined in 600 preference to dNSRecord (defined in [RFC1279]), in order to simplify 601 the DUA's role in interpreting entries in the directory. A dNSRecord 602 expresses a complete resource record, including time to live and 603 class data, which is extraneous to this schema. 605 Additionally, the ipHost and ipNetwork classes permit a host or 606 network (respectively) and all its aliases to be represented by a 607 single entry in the directory. This is not necessarily possible if a 608 DNS resource record is mapped directly to an LDAP entry. 609 Implementations that wish to use LDAP to master DNS zone information 610 are not precluded from doing so, and may simply avoid the ipHost and 611 ipNetwork classes. 613 This document redefines, although not exclusively, the ipNetwork 614 class defined in [RFC1279], in order to achieve consistent naming 615 with ipHost. The ipNetworkNumber attribute is also used in the 616 siteContact object class [ROSE]. 618 The trailing zeros in a network address MUST be omitted. CIDR-style 619 network addresses (eg. 192.168.1/24) MAY be used. 621 Hosts with IPv6 addresses MUST be written in their "preferred" form 622 as defined in section 2.2.1 of [RFC1884], such that all components of 623 the address are indicated and leading zeros are omitted. This 624 provides a consistent means of resolving ipHosts by address. 626 5.5. Interpreting other entities 628 In general, a one-to-one mapping between entities and LDAP entries is 629 proposed, in that each entity has exactly one representation in the 630 DIT. In some cases this is not feasible; for example, a service which 631 is represented in more than one protocol domain. Consider the 632 following entry: 634 dn: cn=domain, dc=aja, dc=com 635 cn: domain 636 cn: nameserver 637 objectClass: top 638 objectClass: ipService 639 ipServicePort: 53 640 ipServiceProtocol: tcp 641 ipServiceProtocol: udp 643 This entry MUST map to the following two (2) services entities: 645 domain 53/tcp nameserver 646 domain 53/udp nameserver 648 While the above two entities may be represented as separate LDAP 649 entities, with different distinguished names (such as 650 cn=domain+ipServiceProtocol=tcp, ... and 651 cn=domain+ipServiceProtocol=udp, ...) it is convenient to represent 652 them as a single entry. (If a service is represented in multiple 653 protocol domains with different ports, then multiple entries are 654 required; multivalued RDNs may be used to distinguish them.) 656 Entries of class automount inherently represent more than one entity: 657 each value of the automountInformation attribute may be a record in a 658 NIS database. 660 With the exception of userPassword values, which are parsed according 661 to the syntax considered in section 5.2, any empty values (consisting 662 of a zero length string) are returned by the DUA to the client. The 663 DUA MUST reject any entries which do not conform to the schema 664 (missing mandatory attributes). Non-conforming entries SHOULD be 665 ignored while enumerating entries. 667 The nisObject object class MAY be used as a generic means of 668 representing NIS entities. Its use is not encouraged; where support 669 for entities not described in this schema is desired, an appropriate 670 schema should be devised. Implementors are strongly advised to 671 support end-user extensible mappings between NIS entities and object 672 classes. (Where the nisObject class is used, the nisMapName attribute 673 may be used as a RDN.) 675 5.6. Canonicalizing entries with multi-valued naming attributes 677 For entities such as services, protocols, and RPCs, where there may 678 be one or more aliases, the respective entry's relative distinguished 679 name SHOULD be used to determine the canonical name. Any other 680 values for the same attribute are used as aliases. For example, the 681 service described in section 5.5 has the canonical name "domain" and 682 exactly one alias, "nameserver". 684 The schema in this document generally only defines one attribute per 685 class which is suitable for distinguishing an entity (excluding any 686 attributes with integer syntax; it is assumed that entries will be 687 distinguished on name). Usually, this is the common name (cn) 688 attribute. This aids the DUA in determining the canonical name of an 689 entity, as it can examine the value of the relative distinguished 690 name. Aliases are thus any values of the distinguishing attribute 691 (such as cn) which do not match the canonical name of the entity. 693 In the event that a different attribute is used to distinguish the 694 entry, as may be the case where these object classes are used as 695 auxiliary classes, the entry's canonical name may not be present in 696 the RDN. In this case, the DUA MUST choose one of the non- 697 distinguished values to represent the entity's canonical name. As the 698 directory server guarantees no ordering of attribute values, it may 699 not be possible to distinguish an entry deterministically. This 700 ambiguity SHOULD NOT be resolved by mapping one directory entry into 701 multiple entities. 703 6. Implementation focus 705 A NIS server which uses LDAP instead of local files has been 706 developed which supports the schema defined in this document. 708 A reference implementation of the C library resolution code has been 709 written for the Free Software Foundation. It may support other C 710 libraries which support the Name Service Switch (NSS) or the 711 Information Retrieval Service (IRS). 713 The author has made available a freely distributable set of scripts 714 which parses local databases such as /etc/passwd and /etc/hosts and 715 generates LDIF output. 717 7. Security considerations 719 The entirety of related security considerations are outside the scope 720 of this document. It is noted that making passwords encrypted with a 721 widely understood hash function (such as crypt()) available to non- 722 privileged users is dangerous because it exposes them to dictionary 723 and brute-force attacks. This is proposed only for compatibility 724 with existing UNIX system implementations. Sites where security is 725 critical SHOULD consider using a strong authentication service for 726 user authentication. 728 Alternatively, the encrypted password could be made available only to 729 a subset of privileged DUAs, which would provide "shadow" password 730 service to client applications. This may be difficult to enforce. 732 Because the schema represents operating system-level entities, access 733 to these entities SHOULD be granted on a discretionary basis. (There 734 is little point in restricting access to data which will be 735 republished without restriction, however.) It is particularly 736 important that only administrators can modify entries defined in this 737 schema, with the exception of allowing a principal to change their 738 password (which may be done on behalf of the user by a client bound 739 as a superior principal, such that password restrictions may be 740 enforced). For example, if a user were allowed to change the value of 741 their uidNumber attribute, they could subvert security by 742 equivalencing their account with the superuser account. 744 A subtree of the DIT which is to be republished by a DUA (such as a 745 NIS gateway) SHOULD be within the same administrative domain that the 746 republishing DUA represents. (For example, principals outside an 747 organization, while conceivably part of the DIT, should not be 748 considered with the same degree of authority as those within the 749 organization.) 751 Finally, care should be exercised with integer attributes of a 752 sensitive nature (particularly the uidNumber and gidNumber 753 attributes) which contain zero-length values. DUAs MAY treat such 754 values as corresponding to the "nobody" or "nogroup" user and group, 755 respectively. 757 8. Acknowledgements 759 Thanks to Leif Hedstrom of Netscape Communications Corporation, 760 Rosanna Lee of Sun Microsystems Inc., Ed Reed of Novell Inc., and 761 Mark Wahl of Critical Angle Inc. for their valuable contributions to 762 the development of this schema. Thanks to Andrew Josey of The Open 763 Group for clarifying the use of the UNIX trademark, and to Tim Howes 764 and Peter J. Cherny for their support. 766 UNIX is a registered trademark of The Open Group. 768 9. References 770 [LDIF]G. Good, "The LDAP Data Interchange Format (LDIF)", INTERNET- 771 DRAFT , November 1996. 773 [RFC1034] 774 P. Mockapetris, "Domain names - concepts and facilities", RFC 775 1034, November 1987. 777 [RFC1057] 778 Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol 779 Specification Version 2", RFC 1057, June 1988. 781 [RFC1279] 782 S. Kille, "X.500 and Domains", RFC 1279, November 1991. 784 [RFC1884] 785 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 786 RFC 1884, December 1995. 788 [RFC2119] 789 S. Bradner, "Key Words for use in RFCs to Indicate Requirement 790 Levels", RFC 2119, March 1997. 792 [RFC2251] 793 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 794 Protocol (v3)", RFC 2251, December 1997. 796 [RFC2252] 797 M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory 798 Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, 799 December 1997. 801 [RFC2253] 802 M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access 803 Protocol (v3): UTF-8 String Representation of Distinguished 804 Names", RFC 2253, December 1997. 806 [RFC2254] 807 T. Howes, "The String Representation of LDAP Search Filters", 808 RFC 2254, December 1997. 810 [RFC2256] 811 M. Wahl, "A Summary of the X.500(96) User Schema for use with 812 LDAPv3", RFC 2256, December 1997. 814 [ROSE]M. T. Rose, "The Little Black Book: Mail Bonding with OSI 815 Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc., 816 1992. 818 [X500]"Information Processing Systems - Open Systems Interconnection 819 - The Directory: Overview of Concepts, Models and Service", 820 ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. 822 [XOPEN] 823 ISO/IEC 9945-1:1990, Information Technology - Portable Operating 824 Systems Interface (POSIX) - Part 1: Systems Application 825 Programming Interface (API) [C Language] 827 10. Author's Address 829 Luke Howard 830 PO Box 59 831 Central Park Vic 3145 832 Australia 833 Email: lukeh@xedoc.com 835 A. Example entries 837 The examples described in this section are provided to illustrate the 838 schema described in this draft. They are not meant to be exhaustive. 839 Entries are presented in LDIF notation [LDIF]. 841 The following entry is an example of the posixAccount class: 843 dn: uid=lester, dc=aja, dc=com 844 objectClass: top 845 objectClass: account 846 objectClass: posixAccount 847 uid: lester 848 cn: Lester the Nightfly 849 userPassword: {crypt}X5/DBrWPOQQaI 850 gecos: Lester 851 loginShell: /bin/csh 852 uidNumber: 10 853 gidNumber: 10 854 homeDirectory: /home/lester 856 This corresponds the UNIX system password file entry: 858 lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh 860 The following entry is an example of the ipHost class: 862 dn: cn=peg.aja.com, dc=aja, dc=com 863 objectClass: top 864 objectClass: ipHost 865 cn: peg.aja.com 866 cn: www.aja.com 867 ipHostNumber: 10.0.0.1 868 macAddress: 00:00:92:90:ee:e2 869 bootParameter: bootfile=mach 870 bootParameter: root=fs:/nfsroot/peg 871 bootParameter: swap=fs:/nfsswap/peg 872 bootParameter: dump=fs:/nfsdump/peg 874 This entry represents the host canonically peg.aja.com, also known as 875 www.aja.com. The Ethernet address and four boot parameters are also 876 specified. 878 An example of the nisNetgroup class: 880 dn: cn=nightfly, dc=aja, dc=com 881 objectClass: top 882 objectClass: nisNetgroup 883 cn: nightfly 884 nisNetgroupTriple: (charlemagne,peg,dunes.aja.com) 885 nisNetgroupTriple: (lester,-,) 886 memberNisNetgroup: kamakiriad 888 This entry represents the netgroup nightfly, which contains two 889 triples (the user charlemagne, the host peg, and the domain 890 dunes.aja.com; and, the user lester, no host, and any domain) and one 891 netgroup (kamakiriad). 893 Finally, an example of the nisObject class: 895 dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com 896 objectClass: top 897 objectClass: nisObject 898 nisMapName: tracks 900 dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com 901 objectClass: top 902 objectClass: nisObject 903 cn: Maxine 904 nisMapName: tracks 905 nisMapEntry: Nightfly$4 907 This entry represents the NIS map tracks, and a single map entry.