idnits 2.17.1 draft-howard-nis-schema-02.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 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 649 has weird spacing: '... 53/tcp names...' == Line 650 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 (1 January 1998) is 9605 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 620, but not defined == Missing Reference: 'LDIF' is mentioned on line 850, but not defined == Unused Reference: 'RFC2251' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 812, 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 (~~), 13 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 1 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] and 179 [LDAPDOMAINS] are 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] and 198 [LDAPDOMAINS] are required. 200 2.4. Syntax definitions 202 The following syntax definitions [RFC2252] are used by this schema. 203 The nisNetgroupTripleSyntax represents NIS netgroup triples: 205 ( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax' 206 DESC 'NIS netgroup triple' ) 208 Values in this syntax are represented by the following: 210 nisnetgrouptriple = "(" hostname "," username "," domainname ")" 211 hostname = "" / "-" / keystring 212 username = "" / "-" / keystring 213 domainname = "" / "-" / keystring 215 The bootParameterSyntax syntax represents boot parameters: 217 ( nisSchema.0.1 NAME 'bootParameterSyntax' 218 DESC 'Boot parameter' ) 220 where: 222 bootparameter = key "=" value 223 key = keystring 224 value = keystring 226 Values adhering to these syntaxes are encoded as strings. 228 3. Attribute definitions 230 This section contains attribute definitions to be implemented by DUAs 231 supporting this schema. 233 ( nisSchema.1.0 NAME 'uidNumber' 234 DESC 'An integer uniquely identifying a user in an 235 administrative domain' 236 EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) 238 ( nisSchema.1.1 NAME 'gidNumber' 239 DESC 'An integer uniquely identifying a group in an 240 administrative domain' 241 EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) 243 ( nisSchema.1.2 NAME 'gecos' 244 DESC 'The GECOS field; the common name' 245 EQUALITY caseIgnoreIA5Match 246 SUBSTRINGS caseIgnoreIA5SubstringsMatch 247 SYNTAX 'IA5String' SINGLE-VALUE ) 249 ( nisSchema.1.3 NAME 'homeDirectory' 250 DESC 'The absolute path to the home directory' 251 EQUALITY caseExactIA5Match 252 SYNTAX 'IA5String' SINGLE-VALUE ) 254 ( nisSchema.1.4 NAME 'loginShell' 255 DESC 'The path to the login shell' 256 EQUALITY caseExactIA5Match 257 SYNTAX 'IA5String' SINGLE-VALUE ) 259 ( nisSchema.1.5 NAME 'shadowLastChange' 260 EQUALITY integerMatch 261 SYNTAX 'INTEGER' SINGLE-VALUE ) 263 ( nisSchema.1.6 NAME 'shadowMin' 264 EQUALITY integerMatch 265 SYNTAX 'INTEGER' SINGLE-VALUE ) 267 ( nisSchema.1.7 NAME 'shadowMax' 268 EQUALITY integerMatch 269 SYNTAX 'INTEGER' SINGLE-VALUE ) 271 ( nisSchema.1.8 NAME 'shadowWarning' 272 EQUALITY integerMatch 273 SYNTAX 'INTEGER' SINGLE-VALUE ) 275 ( nisSchema.1.9 NAME 'shadowInactive' 276 EQUALITY integerMatch 277 SYNTAX 'INTEGER' SINGLE-VALUE ) 279 ( nisSchema.1.10 NAME 'shadowExpire' 280 EQUALITY integerMatch 281 SYNTAX 'INTEGER' SINGLE-VALUE ) 283 ( nisSchema.1.11 NAME 'shadowFlag' 284 EQUALITY integerMatch 285 SYNTAX 'INTEGER' SINGLE-VALUE ) 287 ( nisSchema.1.12 NAME 'memberUid' 288 EQUALITY caseExactIA5Match 289 SUBSTRINGS caseExactIA5SubstringsMatch 290 SYNTAX 'IA5String' ) 292 ( nisSchema.1.13 NAME 'memberNisNetgroup' 293 EQUALITY caseExactIA5Match 294 SUBSTRINGS caseExactIA5SubstringsMatch 295 SYNTAX 'IA5String' ) 297 ( nisSchema.1.14 NAME 'nisNetgroupTriple' 298 DESC 'Netgroup triple' 299 SYNTAX 'nisNetgroupTripleSyntax' ) 301 ( nisSchema.1.15 NAME 'ipServicePort' 302 EQUALITY integerMatch 303 SYNTAX 'INTEGER' SINGLE-VALUE ) 305 ( nisSchema.1.16 NAME 'ipServiceProtocol' 306 EQUALITY caseIgnoreIA5Match 307 SYNTAX 'IA5String' ) 309 ( nisSchema.1.17 NAME 'ipProtocolNumber' 310 EQUALITY integerMatch 311 SYNTAX 'INTEGER' SINGLE-VALUE ) 313 ( nisSchema.1.18 NAME 'oncRpcNumber' 314 EQUALITY integerMatch 315 SYNTAX 'INTEGER' SINGLE-VALUE ) 317 ( nisSchema.1.19 NAME 'ipHostNumber' 318 DESC 'IP address as a dotted decimal, eg. 192.168.1.1, 319 omitting leading zeros.' 320 EQUALITY caseIgnoreIA5Match 321 SYNTAX 'IA5String{128}' ) 323 ( nisSchema.1.20 NAME 'ipNetworkNumber' 324 DESC 'IP network as a dotted decimal, eg. 192.168, 325 omitting leading zeros' 326 EQUALITY caseIgnoreIA5Match 327 SYNTAX 'IA5String{128}' SINGLE-VALUE ) 329 ( nisSchema.1.21 NAME 'ipNetmaskNumber' 330 DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, 331 omitting leading zeros' 332 EQUALITY caseIgnoreIA5Match 333 SYNTAX 'IA5String{128}' SINGLE-VALUE ) 335 ( nisSchema.1.22 NAME 'macAddress' 336 DESC 'MAC address in maximal, colon separated hex 337 notation, eg. 00:00:92:90:ee:e2.' 338 EQUALITY caseIgnoreIA5Match 339 SYNTAX 'IA5String{128}' ) 341 ( nisSchema.1.23 NAME 'bootParameter' 342 DESC 'rpc.bootparamd parameter' 343 SYNTAX 'bootParameterSyntax' ) 345 ( nisSchema.1.24 NAME 'bootFile' 346 DESC 'Boot image name' 347 EQUALITY caseExactIA5Match 348 SYNTAX 'IA5String' ) 350 ( nisSchema.1.25 NAME 'automountInformation' 351 DESC 'An entry in an automount map' 352 EQUALITY caseExactIA5Match 353 SUBSTRINGS caseExactIA5SubstringsMatch 354 SYNTAX 'IA5String' ) 356 ( nisSchema.1.26 NAME 'nisMapName' 357 EQUALITY caseExactIA5Match 358 SUBSTRINGS caseExactIA5SubstringsMatch 359 SYNTAX 'IA5String{1024}' SINGLE-VALUE ) 361 ( nisSchema.1.27 NAME 'nisMapEntry' 362 EQUALITY caseExactIA5Match 363 SUBSTRINGS caseExactIA5SubstringsMatch 364 SYNTAX 'IA5String{1024}' SINGLE-VALUE ) 366 4. Class definitions 368 This section contains class definitions to be implemented by DUAs 369 supporting the schema. 371 The rfc822MailGroup object class MAY be used to represent a mail 372 group for the purpose of alias expansion. Several alternative schemes 373 for mail routing and delivery using LDAP directories, which are 374 outside the scope of this document. 376 ( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY 377 DESC 'Abstraction of an account with POSIX attributes.' 378 MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) 379 MAY ( userPassword $ loginShell $ gecos $ description ) ) 381 ( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY 382 DESC 'Additional attributes for shadow passwords.' 383 MUST uid 384 MAY ( userPassword $ shadowLastChange $ shadowMin 385 shadowMax $ shadowWarning $ shadowInactive $ 386 shadowExpire $ shadowFlag $ description ) ) 388 ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL 389 DESC 'Abstraction of a group of accounts.' 390 MUST ( cn $ gidNumber ) 391 MAY ( userPassword $ memberUid $ description ) ) 393 ( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL 394 DESC 'Abstraction an Internet Protocol service. 395 Maps an IP port and protocol (such as tcp or udp) 396 to one or more names. 397 The distinguished value of the cn attribute denotes 398 the service's canonical name.' 399 MUST ( cn $ ipServicePort $ ipServiceProtocol ) 400 MAY ( description ) ) 402 ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL 403 DESC 'Abstraction of an IP protocol. Maps a protocol number 404 to one or more names. The distinguished value of the cn 405 attribute denotes the protocol's canonical name.' 406 MUST ( cn $ ipProtocolNumber $ description ) 407 MAY description ) 409 ( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL 410 DESC 'Abstraction of an Open Network Computing (ONC) 411 [RFC1057] Remote Procedure Call (RPC) binding. 412 This class maps an ONC RPC number to a name. 413 The distinguished value of the cn attribute denotes 414 the RPC service's canonical name.' 415 MUST ( cn $ oncRpcNumber $ description ) 416 MAY description ) 418 ( nisSchema.2.6 NAME 'ipHost' SUP top STRUCTURAL 419 DESC 'Abstraction of a host. See section 5.4.' 420 MUST ( ipHostNumber $ dc ) 421 MAY ( macAddress $ bootParameter $ bootFile $ l $ 422 description $ manager $ serialNumber ) ) 424 ( nisSchema.2.7 NAME 'ipNetwork' SUP top 425 STRUCTURAL 426 DESC 'Abstraction of a network. See section 5.4.' 427 MUST ( ipNetworkNumber $ dc ) 428 MAY ( ipNetmaskNumber $ l $ description $ manager ) ) 430 ( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL 431 DESC 'Abstraction of a netgroup. May refer to other netgroups.' 432 MUST cn 433 MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) 435 ( nisSchema.2.9 NAME 'automount' SUP top STRUCTURAL 436 DESC 'Abstraction of an automount map; each entry in the map 437 is represented by a value of the automountInformation 438 attribute. The map name is given by the cn attribute. 439 Each value of the automountInformation attribute 440 constitutes a mount entry.' 441 MUST cn 442 MAY ( automountInformation $ description ) ) 444 ( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL 445 DESC 'Abstraction of a generic NIS map or entry.' 446 MUST nisMapName 447 MAY ( cn $ nisMapEntry $ description ) ) 449 5. Implementation details 451 5.1. Suggested resolution methods 453 The preferred means of directing a client application (one using the 454 shared services of the C library) to use LDAP as its information 455 source for the functions listed in 5.2 is to modify the source code 456 to directly query LDAP. As the source to commercial C libraries and 457 applications is rarely available to the end-user, one could emulate a 458 supported nameservice (such as NIS). (This is also an appropriate 459 opportunity to perform caching of entries across process address 460 spaces.) In the case of NIS, reference implementations are widely 461 available and the RPC interface is well known. 463 There exists no standard mechanism, other than NIS, for resolving 464 automount and nisObject entries. The former may be supported by the 465 automounter itself; both classes SHOULD be supported by an LDAP to 466 NIS gateway. Generally, the DUA SHOULD support all the classes 467 defined herein as is practicable. 469 The means by which the operating system is directed to use LDAP is 470 implementation dependent. For example, some operating systems and C 471 libraries support end-user extensible resolvers using dynamically 472 loadable libraries and a nameservice "switch". The means in which the 473 DUA locates LDAP servers is also implementation dependent. 475 5.2. Affected library functions 476 The following functions are typically found in the C libraries of 477 most UNIX and POSIX compliant systems. An LDAP search filter 478 [RFC2254] which may be used to satisfy the function call is included 479 alongside each function name. Parameters are denoted by %s and %d for 480 string and integer arguments, respectively. Long lines are broken. 482 getpwnam() (&(objectClass=posixAccount)(uid=%s)) 483 getpwuid() (&(objectClass=posixAccount) 484 (uidNumber=%d)) 485 getpwent() (objectClass=posixAccount) 487 getspnam() (&(objectClass=shadowAccount)(uid=%s)) 488 getspent() (objectClass=shadowAccount) 490 getgrnam() (&(objectClass=posixGroup)(cn=%s)) 491 getgrgid() (&(objectClass=posixGroup) 492 (gidNumber=%d)) 493 getgrent() (objectClass=posixGroup) 495 getservbyname() (&(objectClass=ipService) 496 (cn=%s)(ipServiceProtocol=%s)) 497 getservbyport() (&(objectClass=ipService) 498 (ipServicePort=%d) 499 (ipServiceProtocol=%s)) 500 getservent() (objectClass=ipService) 502 getrpcbyname() (&(objectClass=oncRpc)(cn=%s)) 503 getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d)) 504 getrpcent() (objectClass=oncRpc) 506 getprotobyname() (&(objectClass=ipProtocol)(cn=%s)) 507 getprotobynumber() (&(objectClass=ipProtocol) 508 (ipProtocolNumber=%d)) 509 getprotoent() (objectClass=ipProtocol) 511 gethostbyname() (&(objectClass=ipHost)(dc=%s)) 512 gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s)) 513 gethostent() (objectClass=ipHost) 515 getnetbyname() (&(objectClass=ipNetwork)(dc=%s)) 516 getnetbyaddr() (&(objectClass=ipNetwork) 517 (ipNetworkNumber=%s)) 518 getnetent() (objectClass=ipNetwork) 520 setnetgrent() (&(objectClass=nisNetgroup)(cn=%s)) 522 getaliasbyname() (&(objectClass=rfc822MailGroup)(cn=%s)) 523 getaliasent() (objectClass=rfc822MailGroup) 525 5.3. Interpreting user and group entries 527 User and group resolution is initiated by the functions prefixed by 528 getpw and getgr respectively. The uid attribute contains the user's 529 login name. The cn attribute, in posixGroup entries, contains the 530 group's name. 532 The account object class provides a convenient structural class for 533 posixAccount, and SHOULD be used where additional attributes are not 534 required. 536 It is suggested that uid and cn are used as the RDN attribute type 537 for posixAccount and posixGroup entries, respectively. 539 An account's GECOS field is preferably determined by a value of the 540 gecos attribute. If no gecos attribute exists, the value of the cn 541 attribute MUST be used. (The existence of the gecos attribute allows 542 information embedded in the GECOS field, such as a user's telephone 543 number, to be returned to the client without overloading the cn 544 attribute. It also accommodates directories where the common name 545 does not contain the user's full name.) 547 An entry of class posixAccount, posixGroup, or shadowAccount without 548 a userPassword attribute MUST NOT be used for authentication. The 549 client should be returned a non-matchable password such as "x". 551 userPassword values MUST be represented by following syntax: 553 passwordvalue = schemeprefix encryptedpassword 554 schemeprefix = "{" scheme "}" 555 scheme = "crypt" / "md5" / "sha" / altscheme 556 altscheme = "x-" keystring 557 encryptedpassword = encrypted password 559 The encrypted password contains of a plaintext key hashed using the 560 algorithm scheme. 562 userPassword values which do not adhere to this syntax MUST NOT be 563 used for authentication. The DUA MUST iterate through the values of 564 the attribute until a value matching the above syntax is found. Only 565 if encryptedpassword is an empty string does the user have no 566 password. DUAs are not required to consider encryption schemes which 567 the client will not recognize; in most cases, it may be sufficient to 568 consider only "crypt". 570 Below is an example of a userPassword attribute: 572 userPassword: {crypt}X5/DBrWPOQQaI 574 A future standard may specify LDAP v3 attribute descriptions to 575 represent hashed userPasswords, as noted below. This schema MUST NOT 576 be used with LDAP v2 DUAs and DSAs. 578 attributetype = attributename sep attributeoption 579 attributename = "userPassword" 580 sep = ";" 581 attributeoption = schemeclass "-" scheme 582 schemeclass = "hash" / altschemeclass 583 scheme = "crypt" / "md5" / "sha" / altscheme 584 altschemeclass = "x-" keystring 585 altscheme = keystring 587 Below is an example of a userPassword attribute, represented with an 588 LDAP v3 attribute description: 590 userPassword;hash-crypt: X5/DBrWPOQQaI 592 A DUA MAY utilise the attributes in the shadowAccount class to 593 provide shadow password service (getspnam() and getspent()). In such 594 cases, the DUA MUST NOT make use of the userPassword attribute for 595 getpwnam() et al, and MUST return a non-matchable password (such as 596 "x") to the client instead. 598 5.4. Interpreting hosts and networks 600 The means for representing DNS [RFC1034] domains in LDAP 601 distinguished names described in [RFC1279] and [LDAPDOMAINS] are 602 incorporated into this schema. However, the ipHostNumber and 603 ipNetworkNumber attributes are defined in preference to dNSRecord, in 604 order to simplify the DUA's role in interpreting entries in the 605 directory. A dNSRecord expresses a complete resource record, 606 including time to live and class data, which is extraneous to this 607 schema. 609 Additionally, the ipHost and ipNetwork classes permit a host or 610 network (respectively) and all its aliases to be represented by a 611 single entry in the directory. This is not necessarily possible if a 612 DNS resource record is mapped directly to an LDAP entry. 613 Implementations that wish to use LDAP to master DNS zone information 614 are not precluded from doing so, and may simply avoid the ipHost and 615 ipNetwork classes. 617 This document redefines, although not exclusively, the ipNetwork 618 class defined in [RFC1279], in order to achieve consistent naming 619 with ipHost. The ipNetworkNumber attribute is also used in the 620 siteContact object class [ROSE]. 622 The trailing zeros in a network address MUST be omitted. CIDR-style 623 network addresses (eg. 192.168.1/24) MAY be used. 625 Hosts with IPv6 addresses MUST be written in their "preferred" form 626 as defined in section 2.2.1 of [RFC1884], such that all components of 627 the address are indicated and leading zeros are omitted. This 628 provides a consistent means of resolving ipHosts by address. 630 5.5. Interpreting other entities 632 In general, a one-to-one mapping between entities and LDAP entries is 633 proposed, in that each entity has exactly one representation in the 634 DIT. In some cases this is not feasible; for example, a service which 635 is represented in more than one protocol domain. Consider the 636 following entry: 638 dn: cn=domain, dc=aja, dc=com 639 cn: domain 640 cn: nameserver 641 objectClass: top 642 objectClass: ipService 643 ipServicePort: 53 644 ipServiceProtocol: tcp 645 ipServiceProtocol: udp 647 This entry MUST map to the following two (2) services entities: 649 domain 53/tcp nameserver 650 domain 53/udp nameserver 652 While the above two entities may be represented as separate LDAP 653 entities, with different distinguished names (such as 654 cn=domain+ipServiceProtocol=tcp, ... and 655 cn=domain+ipServiceProtocol=udp, ...) it is convenient to represent 656 them as a single entry. (If a service is represented in multiple 657 protocol domains with different ports, then multiple entries are 658 required; multivalued RDNs may be used to distinguish them.) 660 Entries of class automount inherently represent more than one entity: 661 each value of the automountInformation attribute may be a record in a 662 NIS database. 664 With the exception of userPassword values, which are parsed according 665 to the syntax considered in section 5.2, any empty values (consisting 666 of a zero length string) are returned by the DUA to the client. The 667 DUA MUST reject any entries which do not conform to the schema 668 (missing mandatory attributes). Non-conforming entries SHOULD be 669 ignored while enumerating entries. 671 The nisObject object class MAY be used as a generic means of 672 representing NIS entities. Its use is not encouraged; where support 673 for entities not described in this schema is desired, an appropriate 674 schema should be devised. Implementors are strongly advised to 675 support end-user extensible mappings between NIS entities and object 676 classes. (Where the nisObject class is used, the nisMapName attribute 677 may be used as a RDN.) 679 5.6. Canonicalizing entries with multi-valued naming attributes 681 For entities such as services, protocols, and RPCs, where there may 682 be one or more aliases, the respective entry's relative distinguished 683 name SHOULD be used to determine the canonical name. Any other 684 values for the same attribute are used as aliases. For example, the 685 service described in section 5.5 has the canonical name "domain" and 686 exactly one alias, "nameserver". 688 The schema in this document generally only defines one attribute per 689 class which is suitable for distinguishing an entity (excluding any 690 attributes with integer syntax; it is assumed that entries will be 691 distinguished on name). Usually, this is the common name (cn) 692 attribute, or the domainComponent (dc) attribute for hosts and 693 networks. This aids the DUA in determining the canonical name of an 694 entity, as it can examine the value of the relative distinguished 695 name. Aliases are thus any values of the distinguishing attribute 696 (such as cn) which do not match the canonical name of the entity. 698 In the event that a different attribute is used to distinguish the 699 entry, as may be the case where these object classes are used as 700 auxiliary classes, the entry's canonical name may not be present in 701 the RDN. In this case, the DUA MUST choose one of the non- 702 distinguished values to represent the entity's canonical name. As the 703 directory server guarantees no ordering of attribute values, it may 704 not be possible to distinguish an entry deterministically. This 705 ambiguity SHOULD NOT be resolved by mapping one directory entry into 706 multiple entities. 708 6. Implementation focus 710 A NIS server which uses LDAP instead of local files has been 711 developed which supports the schema defined in this document. 713 A reference implementation of the C library resolution code has been 714 written for the Free Software Foundation. It may support other C 715 libraries which support the Name Service Switch (NSS) or the 716 Information Retrieval Service (IRS). 718 The author has made available a freely distributable set of scripts 719 which parses local databases such as /etc/passwd and /etc/hosts and 720 generates LDIF output. 722 7. Security considerations 724 The entirety of related security considerations are outside the scope 725 of this document. It is noted that making passwords encrypted with a 726 widely understood hash function (such as crypt()) available to non- 727 privileged users is dangerous because it exposes them to dictionary 728 and brute-force attacks. This is proposed only for compatibility 729 with existing UNIX system implementations. Sites where security is 730 critical SHOULD consider using a strong authentication service for 731 user authentication. 733 Alternatively, the encrypted password could be made available only to 734 a subset of privileged DUAs, which would provide "shadow" password 735 service to client applications. This may be difficult to enforce. 737 Because the schema represents operating system-level entities, access 738 to these entities SHOULD be granted on a discretionary basis. (There 739 is little point in restricting access to data which will be 740 republished without restriction, however.) It is particularly 741 important that only administrators can modify entries defined in this 742 schema, with the exception of allowing a principal to change their 743 password (which may be done on behalf of the user by a client bound 744 as a superior principal, such that password restrictions may be 745 enforced). For example, if a user were allowed to change the value of 746 their uidNumber attribute, they could subvert security by 747 equivalencing their account with the superuser account. 749 A subtree of the DIT which is to be republished by a DUA (such as a 750 NIS gateway) SHOULD be within the same administrative domain that the 751 republishing DUA represents. (For example, principals outside an 752 organization, while conceivably part of the DIT, should not be 753 considered with the same degree of authority as those within the 754 organization.) 756 Finally, care should be exercised with integer attributes of a 757 sensitive nature (particularly the uidNumber and gidNumber 758 attributes) which contain zero-length values. DUAs MAY treat such 759 values as corresponding to the "nobody" or "nogroup" user and group, 760 respectively. 762 8. Acknowledgements 764 Thanks to Leif Hedstrom of Netscape Communications Corporation, 765 Rosanna Lee of Sun Microsystems Inc., Ed Reed of Novell Inc., and 766 Mark Wahl of Critical Angle Inc. for their valuable contributions to 767 the development of this schema. Thanks to Andrew Josey of The Open 768 Group for clarifying the use of the UNIX trademark, and to Tim Howes 769 and Peter J. Cherny for their support. 771 UNIX is a registered trademark of The Open Group. 773 9. References 775 [LDIF]G. Good, "The LDAP Data Interchange Format (LDIF)", INTERNET- 776 DRAFT , November 1996. 778 [LDAPDOMAINS] 779 S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, "An 780 Approach for Using Domains in LDAP Distinguished Names", 781 INTERNET-DRAFT , September 782 1997. 784 [RFC1034] 785 P. Mockapetris, "Domain names - concepts and facilities", RFC 786 1034, November 1987. 788 [RFC1057] 789 Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol 790 Specification Version 2", RFC 1057, June 1988. 792 [RFC1279] 793 S. Kille, "X.500 and Domains", RFC 1279, November 1991. 795 [RFC1884] 796 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 797 RFC 1884, December 1995. 799 [RFC2119] 800 S. Bradner, "Key Words for use in RFCs to Indicate Requirement 801 Levels", RFC 2119, March 1997. 803 [RFC2251] 804 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 805 Protocol (v3)", RFC 2251, December 1997. 807 [RFC2252] 808 M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory 809 Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, 810 December 1997. 812 [RFC2253] 813 M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access 814 Protocol (v3): UTF-8 String Representation of Distinguished 815 Names", RFC 2253, December 1997. 817 [RFC2254] 818 T. Howes, "The String Representation of LDAP Search Filters", 819 RFC 2254, December 1997. 821 [RFC2256] 822 M. Wahl, "A Summary of the X.500(96) User Schema for use with 823 LDAPv3", RFC 2256, December 1997. 825 [ROSE]M. T. Rose, "The Little Black Book: Mail Bonding with OSI 826 Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc., 827 1992. 829 [X500]"Information Processing Systems - Open Systems Interconnection 830 - The Directory: Overview of Concepts, Models and Service", 831 ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. 833 [XOPEN] 834 ISO/IEC 9945-1:1990, Information Technology - Portable Operating 835 Systems Interface (POSIX) - Part 1: Systems Application 836 Programming Interface (API) [C Language] 838 10. Author's Address 840 Luke Howard 841 PO Box 59 842 Central Park Vic 3145 843 Australia 844 Email: lukeh@xedoc.com 846 A. Example entries 848 The examples described in this section are provided to illustrate the 849 schema described in this draft. They are not meant to be exhaustive. 850 Entries are presented in LDIF notation [LDIF]. 852 The following entry is an example of the posixAccount class: 854 dn: uid=lester, dc=aja, dc=com 855 objectClass: top 856 objectClass: account 857 objectClass: posixAccount 858 uid: lester 859 cn: Lester the Nightfly 860 userPassword: {crypt}X5/DBrWPOQQaI 861 gecos: Lester 862 loginShell: /bin/csh 863 uidNumber: 10 864 gidNumber: 10 865 homeDirectory: /home/lester 867 This corresponds the UNIX system password file entry: 869 lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh 871 The following entry is an example of the ipHost class: 873 dn: dc=peg, dc=aja, dc=com 874 objectClass: top 875 objectClass: ipHost 876 dc: peg 877 dc: www 878 ipHostNumber: 10.0.0.1 879 macAddress: 00:00:92:90:ee:e2 880 bootParameter: bootfile=mach 881 bootParameter: root=fs:/nfsroot/peg 882 bootParameter: swap=fs:/nfsswap/peg 883 bootParameter: dump=fs:/nfsdump/peg 885 This entry represents the host canonically peg, also known as www. 886 The Ethernet address and four boot parameters are also specified. 888 An example of the nisNetgroup class: 890 dn: cn=nightfly, dc=aja, dc=com 891 objectClass: top 892 objectClass: nisNetgroup 893 cn: nightfly 894 nisNetgroupTriple: (charlemagne,peg,dunes.aja.com) 895 nisNetgroupTriple: (lester,-,) 896 memberNisNetgroup: kamakiriad 898 This entry represents the netgroup nightfly, which contains two 899 triples (the user charlemagne, the host peg, and the domain 900 dunes.aja.com; and, the user lester, no host, and any domain) and one 901 netgroup (kamakiriad). 903 Finally, an example of the nisObject class: 905 dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com 906 objectClass: top 907 objectClass: nisObject 908 nisMapName: tracks 910 dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com 911 objectClass: top 912 objectClass: nisObject 913 cn: Maxine 914 nisMapName: tracks 915 nisMapEntry: Nightfly$4 917 This entry represents the NIS map tracks, and a single map entry.