idnits 2.17.1 draft-howard-nis-schema-01.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-16) 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-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 373: '... MUST ( cn $ uid $ uidNumber ...' RFC 2119 keyword, line 374: '... MAY ( userPassword $ loginSh...' RFC 2119 keyword, line 378: '... MUST uid...' RFC 2119 keyword, line 379: '... MAY ( userPassword $ shadowL...' RFC 2119 keyword, line 385: '... MUST ( cn $ gidNumber )...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 672 has weird spacing: '... 53/tcp names...' == Line 673 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 (17 November 1997) is 9647 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: 'ROSE' is mentioned on line 620, but not defined == Missing Reference: 'LDIF' is mentioned on line 872, but not defined ** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 2052 (Obsoleted by RFC 2782) Summary: 14 errors (**), 0 flaws (~~), 10 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 17 November 1997 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 For the purposes of this document, the term 'nameservice' refers to a 97 service, such as NIS or flat files, that is used by the operating 98 system to resolve entities within a single, local naming context. 99 Contrast this with a 'directory service' such as LDAP, which supports 100 extensible schema and multiple naming contexts. 102 The term 'NIS-related entities' broadly refers to entities which are 103 typically resolved using the Network Information Service. (NIS was 104 previously known as YP.) Deploying LDAP for resolving these entities 105 does not imply that NIS be used, as a gateway or otherwise. In 106 particular, the host and network classes are generically applicable, 107 and may be implemented on any system that wishes to use LDAP or X.500 108 for host and network resolution. 110 The 'DUA' (directory user agent) refers to the LDAP client querying 111 these entities, such as an LDAP to NIS gateway or the C library. The 112 'client' refers to the application which ultimately makes use of the 113 information returned by the resolution. It is irrelevant whether the 114 DUA and the client reside within the same address space. The act of 115 the DUA making this information to the client is termed 116 'republishing'. 118 To avoid confusion, the term 'login name' refers to the user's login 119 name (being the value of the uid attribute) and the term 'user ID' 120 refers to he user's integer identification number (being the value of 121 the uidNumber attribute). 123 The phrases 'resolving an entity' and 'resolution of entities' refer 124 respectively to enumerating NIS-related entities of a given type, and 125 matching them against a given search criterion. One or more entities 126 are returned as a result of successful 'resolutions' (a 'match' 127 operation will only return one entity). 129 The use of the term UNIX does not confer upon this schema the 130 endorsement of owners of the UNIX trademark. Where necessary, the 131 term 'TCP/IP entity' is used to refer to protocols, services, hosts, 132 and networks, and the term 'UNIX entity' to its complement. (The 133 former category does not mandate the host operating system supporting 134 the interfaces required for resolving UNIX entities.) 136 The OIDs defined below are derived from iso(1) org(3) dod(6) 137 internet(1) directory(1) nisSchema(1). 139 2.2. Attributes 141 The attributes and classes defined in this document are summarized 142 below. 144 The following attributes are defined in this document: 146 uidNumber 147 gidNumber 148 gecos 149 homeDirectory 150 loginShell 151 shadowLastChange 152 shadowMin 153 shadowMax 154 shadowWarning 155 shadowInactive 156 shadowExpire 157 shadowFlag 158 memberUid 159 memberNisNetgroup 160 nisNetgroupTriple 161 ipServicePort 162 ipServiceProtocol 163 ipProtocolNumber 164 oncRpcNumber 165 ipHostNumber 166 ipNetworkNumber 167 ipNetmaskNumber 168 macAddress 169 bootParameter 170 bootFile 171 automountInformation 172 nisMapName 173 nisMapEntry 175 Additionally, some of the attributes defined in [LDAPATTRS] and 176 [LDAPDOMAINS] are required. 178 2.3. Object classes 180 The following object classes are defined in this document: 182 posixAccount 183 shadowAccount 184 posixGroup 185 ipService 186 ipProtocol 187 oncRpc 188 ipHost 189 ipNetwork 190 nisNetgroup 191 automount 192 nisObject 194 Additionally, some of the classes defined in [LDAPATTRS] and 195 [LDAPDOMAINS] are required. 197 2.4. Syntax definitions 199 The following syntax definitions [LDAPATTRS] are used by this schema. 200 The nisNetgroupTripleSyntax encodes NIS netgroup triples: 202 ( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax' 203 DESC 'NIS netgroup triple' ) 205 Values in this syntax are represented by the following: 207 nisnetgrouptriple = "(" hostname "," username "," domainname ")" 208 hostname = "" / "-" / keystring 209 username = "" / "-" / keystring 210 domainname = "" / "-" / keystring 212 The bootParameterSyntax syntax encodes boot parameters: 214 ( nisSchema.0.1 NAME 'bootParameterSyntax' 215 DESC 'Boot parameter' ) 217 where: 219 bootparameter = key "=" value 220 key = keystring 221 value = keystring 223 Values adhering to these syntaxes are encoded as strings. 225 3. Attribute definitions 227 This section contains attribute definitions which must be implemented 228 by DUAs supporting the schema. 230 ( nisSchema.1.0 NAME 'uidNumber' 231 DESC 'An integer uniquely identifying a user in an 232 administrative domain' 233 EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) 235 ( nisSchema.1.1 NAME 'gidNumber' 236 DESC 'An integer uniquely identifying a group in an 237 administrative domain' 239 EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) 241 ( nisSchema.1.2 NAME 'gecos' 242 DESC 'The GECOS field; the user's common name' 243 EQUALITY caseIgnoreIA5Match 244 SUBSTRINGS caseIgnoreIA5SubstringsMatch 245 SYNTAX 'IA5String' SINGLE-VALUE ) 247 ( nisSchema.1.3 NAME 'homeDirectory' 248 DESC 'The absolute path of the user's home directory' 249 EQUALITY caseExactIA5Match 250 SYNTAX 'IA5String' SINGLE-VALUE ) 252 ( nisSchema.1.4 NAME 'loginShell' 253 DESC 'The absolute path of the user's shell' 254 EQUALITY caseExactIA5Match 255 SYNTAX 'IA5String' SINGLE-VALUE ) 257 ( nisSchema.1.5 NAME 'shadowLastChange' 258 EQUALITY integerMatch 259 SYNTAX 'INTEGER' SINGLE-VALUE ) 261 ( nisSchema.1.6 NAME 'shadowMin' 262 EQUALITY integerMatch 263 SYNTAX 'INTEGER' SINGLE-VALUE ) 265 ( nisSchema.1.7 NAME 'shadowMax' 266 EQUALITY integerMatch 267 SYNTAX 'INTEGER' SINGLE-VALUE ) 269 ( nisSchema.1.8 NAME 'shadowWarning' 270 EQUALITY integerMatch 271 SYNTAX 'INTEGER' SINGLE-VALUE ) 273 ( nisSchema.1.9 NAME 'shadowInactive' 274 EQUALITY integerMatch 275 SYNTAX 'INTEGER' SINGLE-VALUE ) 277 ( nisSchema.1.10 NAME 'shadowExpire' 278 EQUALITY integerMatch 279 SYNTAX 'INTEGER' SINGLE-VALUE ) 281 ( nisSchema.1.11 NAME 'shadowFlag' 282 EQUALITY integerMatch 283 SYNTAX 'INTEGER' SINGLE-VALUE ) 285 ( nisSchema.1.12 NAME 'memberUid' 286 EQUALITY caseExactIA5Match 287 SUBSTRINGS caseExactIA5SubstringsMatch 288 SYNTAX 'IA5String' ) 290 ( nisSchema.1.13 NAME 'memberNisNetgroup' 291 EQUALITY caseExactIA5Match 292 SUBSTRINGS caseExactIA5SubstringsMatch 293 SYNTAX 'IA5String' ) 295 ( nisSchema.1.14 NAME 'nisNetgroupTriple' 296 DESC 'Netgroup triple' 297 SYNTAX 'nisNetgroupTripleSyntax' ) 299 ( nisSchema.1.15 NAME 'ipServicePort' 300 EQUALITY integerMatch 301 SYNTAX 'INTEGER' SINGLE-VALUE ) 303 ( nisSchema.1.16 NAME 'ipServiceProtocol' 304 EQUALITY caseIgnoreIA5Match 305 SYNTAX 'IA5String' ) 307 ( nisSchema.1.17 NAME 'ipProtocolNumber' 308 EQUALITY integerMatch 309 SYNTAX 'INTEGER' SINGLE-VALUE 311 ( nisSchema.1.18 NAME 'oncRpcNumber' 312 EQUALITY integerMatch 313 SYNTAX 'INTEGER' SINGLE-VALUE ) 315 ( nisSchema.1.19 NAME 'ipHostNumber' 316 DESC 'IP address as a dotted decimal, eg. 192.168.1.1' 317 EQUALITY caseIgnoreIA5Match 318 SYNTAX 'IA5String{128}' ) 320 ( nisSchema.1.20 NAME 'ipNetworkNumber' 321 DESC 'IP network as a dotted decimal, eg. 192.168' 322 EQUALITY caseIgnoreIA5Match 323 SYNTAX 'IA5String{128}' ) 325 ( nisSchema.1.21 NAME 'ipNetmaskNumber' 326 DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0' 327 EQUALITY caseIgnoreIA5Match 328 SYNTAX 'IA5String{128}' ) 330 ( nisSchema.1.22 NAME 'macAddress' 331 DESC 'MAC address in colon-separated hex notation, for 332 example 0:0:92:90:ee:e2' 333 EQUALITY caseIgnoreIA5Match 334 SYNTAX 'IA5String{128}' ) 336 ( nisSchema.1.23 NAME 'bootParameter' 337 DESC 'rpc.bootparamd parameter' 338 SYNTAX 'bootParameterSyntax' ) 340 ( nisSchema.1.24 NAME 'bootFile' 341 DESC 'Boot image name' 342 EQUALITY caseExactIA5Match 343 SYNTAX 'IA5String' ) 345 ( nisSchema.1.25 NAME 'automountInformation' 346 DESC 'An entry in an automount map' 347 EQUALITY caseExactIA5Match 348 SUBSTRINGS caseExactIA5SubstringsMatch 349 SYNTAX 'IA5String' ) 351 ( nisSchema.1.26 NAME 'nisMapName' 352 EQUALITY caseExactIA5Match 353 SUBSTRINGS caseExactIA5SubstringsMatch 354 SYNTAX 'IA5String{1024}' SINGLE-VALUE ) 356 ( nisSchema.1.27 NAME 'nisMapEntry' 357 EQUALITY caseExactIA5Match 358 SUBSTRINGS caseExactIA5SubstringsMatch 359 SYNTAX 'IA5String{1024}' SINGLE-VALUE ) 361 4. Class definitions 363 This section contains class definitions which must be implemented by 364 DUAs supporting the schema. 366 The rfc822MailGroup object class may used to represent a mail group 367 for the purpose of alias expansion. Several alternative schemes for 368 mail routing and delivery using LDAP directories, which are outside 369 the scope of this document. 371 ( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY 372 DESC 'Abstraction of an account with POSIX attributes.' 373 MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) 374 MAY ( userPassword $ loginShell $ gecos $ description ) ) 376 ( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY 377 DESC 'Additional attributes for shadow passwords.' 378 MUST uid 379 MAY ( userPassword $ shadowLastChange $ shadowMin 380 shadowMax $ shadowWarning $ shadowInactive $ 381 shadowExpire $ shadowFlag $ description ) ) 383 ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL 384 DESC 'Abstraction of a group of accounts.' 385 MUST ( cn $ gidNumber ) 386 MAY ( userPassword $ memberUid $ description ) ) 388 ( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL 389 DESC 'Abstraction an Internet Protocol service. 390 Maps an IP port and protocol (such as tcp or udp) 391 to one or more names. 392 The distinguished value of the cn attribute denotes 393 the service's canonical name.' 394 MUST ( cn $ ipServicePort $ ipServiceProtocol ) 395 MAY ( description ) ) 397 ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL 398 DESC 'Abstraction of an IP protocol. Maps a protocol number 399 to one or more names. The distinguished value of the cn 400 attribute denotes the protocol's canonical name.' 401 MUST ( cn $ ipProtocolNumber $ description ) 402 MAY description ) 404 ( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL 405 DESC 'Abstraction of an Open Network Computing (ONC) 406 [RFC1057] Remote Procedure Call (RPC) binding. 407 This class maps an ONC RPC number to a name. 408 The distinguished value of the cn attribute denotes 409 the RPC service's canonical name.' 410 MUST ( cn $ oncRpcNumber $ description ) 411 MAY description ) 413 ( nisSchema.2.6 NAME 'ipHost' SUP top STRUCTURAL 414 DESC 'Abstraction of a host. See section 5.4.' 415 MUST ( ipHostNumber $ associatedDomain ) 416 MAY ( macAddress $ bootParameter $ bootFile $ dc $ 417 l $ description $ manager $ serialNumber ) ) 419 ( nisSchema.2.7 NAME 'ipNetwork' SUP top 420 STRUCTURAL 421 DESC 'Abstraction of a network. See section 5.4.' 422 MUST ( ipNetworkNumber $ associatedDomain ) 423 MAY ( ipNetmaskNumber $ l $ description $ manager $ dc ) ) 425 ( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL 426 DESC 'Abstraction of a netgroup. May refer to other netgroups.' 427 MUST cn 428 MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) 430 ( nisSchema.2.9 NAME 'automount' SUP top STRUCTURAL 431 DESC 'Abstraction of an automount map; each entry in the map 432 is represented by a value of the automountInformation 433 attribute. The map name is given by the cn attribute. 434 Each value of the automountInformation attribute 435 constitutes a mount entry.' 436 MUST cn 437 MAY ( automountInformation $ description ) ) 439 ( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL 440 DESC 'Abstraction of a generic NIS map or entry.' 441 MUST nisMapName 442 MAY ( cn $ nisMapEntry $ description ) ) 444 5. Implementation details 446 5.1. Suggested resolution methods 448 The preferred means of directing a client application (one using the 449 shared services of the C library) to use LDAP as its information 450 source for the functions listed in 5.2 is to modify the source code 451 to directly query LDAP. As the source to commercial C libraries and 452 applications is rarely available to the end-user, one could emulate a 453 supported nameservice (such as NIS). (This is also an appropriate 454 opportunity to perform caching of entries across process address 455 spaces.) In the case of NIS, reference implementations are widely 456 available and the RPC interface is well known. 458 There exists no standard mechanism, other than NIS, for resolving 459 automount and nisObject entries. The former may be supported by the 460 automounter itself; both classes should be supported by an LDAP to 461 NIS gateway. DUAs implementing this schema are not required to 462 support all the classes defined herein. 464 The means by which the operating system is directed to use LDAP is 465 implementation dependent. For example, some operating systems and C 466 libraries support end-user extensible resolvers using dynamically 467 loadable libraries and a nameservice "switch". The means in which the 468 DUA locates LDAP servers is also implementation dependent. It is 469 anticipated that DNS SRV records [RFC2052] may be used for this. 471 5.2. Affected library functions 473 The following functions are typically found in the C libraries of 474 most UNIX and POSIX compliant systems. An LDAP search filter 475 [LDAPFILT] which may be used to satisfy the function call is included 476 alongside each function name. Parameters are denoted by %s and %d for 477 string and integer arguments, respectively. Long lines are broken. 479 getpwnam() (&(objectClass=posixAccount)(uid=%s)) 480 getpwuid() (&(objectClass=posixAccount) 481 (uidNumber=%d)) 482 getpwent() (objectClass=posixAccount) 484 getspnam() (&(objectClass=shadowAccount)(uid=%s)) 485 getspent() (objectclass=shadowAccount) 487 getgrnam() (&(objectClass=posixGroup)(cn=%s)) 488 getgrgid() (&(objectClass=posixGroup) 489 (gidNumber=%d)) 490 getgrent() (objectClass=posixGroup) 492 getservbyname() (&(objectClass=ipService) 493 (cn=%s)(ipServiceProtocol=%s)) 494 getservbyport() (&(objectClass=ipService) 495 (ipServicePort=%d) 496 (ipServiceProtocol=%s)) 497 getservent() (objectClass=ipService) 499 getrpcbyname() (&(objectClass=oncRpc)(cn=%s)) 500 getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d)) 501 getrpcent() (objectClass=oncRpc) 503 getprotobyname() (&(objectClass=ipProtocol)(cn=%s)) 504 getprotobynumber() (&(objectClass=ipProtocol) 505 (ipProtocolNumber=%d)) 506 getprotoent() (objectClass=ipProtocol) 508 gethostbyname() (&(objectClass=ipHost) 509 (associatedDomain=%s)) 510 gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s)) 511 gethostent() (objectClass=ipHost) 513 getnetbyname() (&(objectClass=ipNetwork) 514 (associatedDomain=%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 be denied the opportunity to 548 authenticate. The client should be returned a non-matchable password 549 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 the above syntax must not 563 be used for authentication. The DUA must iterate through the values 564 of the attribute until a value matching the above syntax is found. 565 Only 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 use LDAP v3 attribute descriptions to represent 575 hashed userPasswords, as noted below. This schema should not be used 576 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 The associatedDomain attribute must contain the host or network's 626 canonical, qualified domain name, and any other names by which the 627 host or network is known. This should include the host's or network's 628 non qualified name. When interrogated the directory for ipHosts, the 629 associatedDomain attribute must be used in the search filter. 631 The use of the dc attribute to distinguish hosts is recommended, but 632 not required. If used, it must contain the host's non-qualified name. 633 It has no role in interrogation. 635 If an entry of class ipHost or ipNetwork belongs to a naming context 636 containing relative distinguished names (RDNs) [LDAPDN] of attribute 637 type dc (domainComponent), the distinguished name (DN) may be used to 638 select which value of associatedDomain is the canonical host name. 639 Such a DN is mapped to a domain name by concatenating each RDN value 640 with a period ('.'). For example, an entry of class ipHost with a DN 641 of dc=foo, dc=bar, dc=edu or dc=foo, dc=bar, dc=edu, o=Internet may 642 select the domain foo.bar.edu from the values of associatedDomain. 643 The mapping must terminate at the first relative distinguished name 644 which is not a domainComponent. This mapping must not be applied if 645 the entry's RDN type is not dc. Instead, associatedDomain alone must 646 determine the hostname. 648 Hosts with IPv6 addresses should be written in their "preferred" form 649 as defined in section 2.2.1 of [RFC1884], such that all components of 650 the address are indicated and leading zeros are omitted. This 651 provides a consistent means of resolving ipHosts by address. 653 5.5. Interpreting other entities 655 In general, a one-to-one mapping between entities and LDAP entries is 656 proposed, in that each entity has exactly one representation in the 657 DIT. In some cases this is not feasible; for example, a service which 658 is represented in more than one protocol domain. Consider the 659 following entry: 661 dn: cn=domain, dc=aja, dc=com 662 cn: domain 663 cn: nameserver 664 objectClass: top 665 objectClass: ipService 666 ipServicePort: 53 667 ipServiceProtocol: tcp 668 ipServiceProtocol: udp 670 This entry maps to the following two (2) services entities: 672 domain 53/tcp nameserver 673 domain 53/udp nameserver 675 While the above two entities may be represented as separate LDAP 676 entities, with different distinguished names (such as 677 cn=domain+ipServiceProtocol=tcp, ... and 678 cn=domain+ipServiceProtocol=udp, ...) it is convenient to represent 679 them as a single entry. (If a service is represented in multiple 680 protocol domains with different ports, then multiple entries are 681 required; multivalued RDNs may be used to distinguish them.) 683 Entries of class automount inherently represent more than one entity: 684 each value of the automountInformation attribute may be a record in a 685 NIS database. 687 With the exception of userPassword values, which must be parsed 688 according to the syntax considered in section 5.2, any empty values 689 (consisting of a zero length string) are returned by the DUA to the 690 client. The DUA must reject any entries which do not conform to the 691 schema (missing mandatory attributes). Non-conforming entries should 692 be ignored while enumerating entries. 694 The nisObject object class may be used 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. (Where the nisObject class is used, the nisMapName attribute 700 may be used as a RDN.) 702 5.6. Canonicalizing entries with multi-valued naming attributes 704 For entities such as services, protocols, and RPCs, where there may 705 be one or more aliases, the respective entry's relative distinguished 706 name should be used to form the canonical name. Any other values for 707 the same attribute are used as aliases. For example, the service 708 described in section 5.5 has the canonical name 'domain' and exactly 709 one alias, 'nameserver'. 711 The schema in this document generally only defines one attribute per 712 class which is suitable for distinguishing an entity (excluding any 713 attributes with integer syntax; it is assumed that entries will be 714 distinguished on name). Usually, this is the common name (cn) 715 attribute. (For users, either the cn or uid attributes may be used 716 to canonicalize an entry. For hosts and networks, the distinguished 717 name may be considered per section 5.4.) name is considered, as per 718 section 5.4.) This aids the DUA in determining the canonical name of 719 an entity, as it can examine the value of the relative distinguished 720 name. Aliases are thus any values of the distinguishing attribute 721 (such as cn) which do not match the canonical name of the entity. 723 In the event that a different attribute is used to distinguish the 724 entry, as may be the case where these object classes are used as 725 auxiliary classes, the entry's canonical name may not be present in 726 the RDN. In this case, the DUA must choose one of the non- 727 distinguished values to represent the entity's canonical name. As the 728 directory server guarantees no ordering of attribute values, it may 729 not be possible to distinguish an entry deterministically. This 730 ambiguity should not be resolved by mapping one directory entry into 731 multiple entities. 733 6. Implementation focus 735 A NIS server which uses LDAP instead of local files has been 736 developed which supports the schema defined in this document. 738 A reference implementation of the C library resolution code has been 739 written for the Free Software Foundation. It may support other C 740 libraries which support the Name Service Switch (NSS) or the 741 Information Retrieval Service (IRS). 743 The author has made available a freely distributable set of scripts 744 which parses local databases such as /etc/passwd and /etc/hosts and 745 generates LDIF output. 747 7. Security considerations 749 The entirety of related security considerations are outside the scope 750 of this document. It should be noted that making passwords encrypted 751 with a widely understood hash function (such as crypt()) available to 752 non-privileged users is dangerous because it exposes them to 753 dictionary and brute-force attacks. It is proposed only for 754 compatibility with existing UNIX system implementations. Sites where 755 security is critical should consider using a strong authentication 756 service for user authentication. 758 Alternatively, the encrypted password could be made available only to 759 a subset of privileged DUAs, which would provide 'shadow' password 760 service to client applications. This may be difficult to enforce. 762 Because the schema represents operating system-level entities, access 763 to these entities should be granted on a discretionary basis. (There 764 is little point in restricting access to data which will be 765 republished without restriction, however.) It is particularly 766 important that only administrators can modify entries defined in this 767 schema, with the exception of allowing a principal to change their 768 password (which may be done on behalf of the user by a client bound 769 as a superior principal, such that password restrictions may be 770 enforced). For example, if a user were allowed to change the value of 771 their uidNumber attribute, they could subvert security by 772 equivalencing their account with the superuser account. 774 A subtree of the DIT which is to be republished by a DUA (such as a 775 NIS gateway) should be within the same administrative domain that the 776 republishing DUA represents. (For example, principals outside an 777 organization, while conceivably part of the DIT, should not be 778 considered with the same degree of authority as those within the 779 organization.) 781 Finally, care should be exercised with integer attributes of a 782 sensitive nature (particularly the uidNumber and gidNumber 783 attributes) which contain zero-length values. It may be wiser to 784 treat such values as corresponding to the "nobody" or "nogroup" user 785 and group, respectively. 787 8. Acknowledgements 789 Thanks to Leif Hedstrom of Netscape Communications Corporation, 790 Rosanna Lee of Sun Microsystems Inc., and Mark Wahl of Critical Angle 791 Inc. for their valuable contributions to the development of this 792 schema. Thanks to Andrew Josey of The Open Group for clarifying the 793 use of the UNIX trademark. 795 UNIX is a registered trademark of The Open Group. 797 9. References 799 [LDIF]G. Good, "The LDAP Data Interchange Format (LDIF)", INTERNET- 800 DRAFT , November 1996. 802 [LDAPATTRS] 803 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 804 Protocol: Standard and Pilot Attribute Definitions", INTERNET- 805 DRAFT , June 1997. 807 [LDAPFILT] 808 T. Howes, "A String Representation of LDAP Search Filters", 809 INTERNET-DRAFT , May 1997. 811 [LDAPDN] 812 M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access 813 Protocol (v3): UTF-8 String Representation of Distinguished 814 Names", INTERNET-DRAFT , 815 November 1997. 817 [LDAPDOMAINS] 818 S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, "An 819 Approach for Using Domains in LDAP Distinguished Names", 820 INTERNET-DRAFT , September 821 1997. 823 [LDAPV3] 824 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 825 Protocol (Version 3)", INTERNET-DRAFT , June 1997. 828 [RFC1034] 829 P. Mockapetris, "Domain names - concepts and facilities", RFC 830 1034, November 1987. 832 [RFC1057] 833 Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol 834 Specification Version 2", RFC 1057, June 1988. 836 [RFC1279] 837 S. Kille, "X.500 and Domains", RFC 1279, November 1991. 839 [RFC1884] 840 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 841 RFC 1884, December 1995. 843 [RFC2052] 844 A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location 845 of services (DNS SRV)", RFC 2052, October 1996. 847 [ROSE]M. T. Rose, "The Little Black Book: Mail Bonding with OSI 848 Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc., 849 1992. 851 [X500]"Information Processing Systems - Open Systems Interconnection 852 - The Directory: Overview of Concepts, Models and Service", 853 ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. 855 [XOPEN] 856 ISO/IEC 9945-1:1990, Information Technology - Portable Operating 857 Systems Interface (POSIX) - Part 1: Systems Application 858 Programming Interface (API) [C Language] 860 10. Author's Address 862 Luke Howard 863 PO Box 59 864 Central Park Vic 3145 865 Australia 866 Email: lukeh@xedoc.com 868 A. Example entries 870 The examples described in this section are provided to illustrate the 871 schema described in this draft. They are not meant to be exhaustive. 872 Entries are presented in LDIF notation [LDIF]. 874 The following entry is an example of the posixAccount class: 876 dn: uid=lester, dc=aja, dc=com 877 objectClass: top 878 objectClass: account 879 objectClass: posixAccount 880 uid: lester 881 cn: Lester the Nightfly 882 userPassword: {crypt}X5/DBrWPOQQaI 883 gecos: Lester 884 loginShell: /bin/csh 885 uidNumber: 10 886 gidNumber: 10 887 homeDirectory: /home/lester 889 This corresponds the UNIX system password file entry: 891 lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh 893 The following entry is an example of the ipHost class: 895 dn: dc=peg, dc=aja, dc=com 896 objectClass: top 897 objectClass: ipHost 898 dc: peg 899 associatedDomain: peg 900 associatedDomain: peg.aja.com 901 associatedDomain: www.aja.com 902 ipHostNumber: 10.0.0.1 903 macAddress: 0:0:92:90:ee:e2 904 bootParameter: bootfile=mach 905 bootParameter: root=fs:/nfsroot/peg 906 bootParameter: swap=fs:/nfsswap/peg 907 bootParameter: dump=fs:/nfsdump/peg 909 This entry represents the host canonically peg.aja.com, also known as 910 www.aja.com and peg. Note while associatedDomain values are used to 911 search for the entry, the distinguished name may be parsed to 912 determine the host's canonical name. The Ethernet address and four 913 boot parameters are also specified. 915 An example of the nisNetgroup class: 917 dn: cn=nightfly, dc=aja, dc=com 918 objectClass: top 919 objectClass: nisNetgroup 920 cn: nightfly 921 nisNetgroupTriple: (charlemagne,peg,dunes.aja.com) 922 nisNetgroupTriple: (lester,-,) 923 memberNisNetgroup: kamakiriad 925 This entry represents the netgroup nightfly, which contains two 926 triples (the user charlemagne, the host peg, and the domain 927 dunes.aja.com; and, the user lester, no host, and any domain) and one 928 netgroup (kamakiriad). 930 Finally, an example of the nisObject class: 932 dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com 933 objectClass: top 934 objectClass: nisObject 935 nisMapName: tracks 937 dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com 938 objectClass: top 939 objectClass: nisObject 940 cn: Maxine 941 nisMapName: tracks 942 nisMapEntry: Nightfly$4 944 This entry represents the NIS map tracks, and a single map entry.