1 2 3 4 5 6 7Network Working Group L. Howard 8Request for Comments: 2307 Independent Consultant 9Category: Experimental March 1998 10 11 12 An Approach for Using LDAP as a Network Information Service 13 14Status of this Memo 15 16 This memo defines an Experimental Protocol for the Internet 17 community. It does not specify an Internet standard of any kind. 18 Discussion and suggestions for improvement are requested. 19 Distribution of this memo is unlimited. 20 21Copyright Notice 22 23 Copyright (C) The Internet Society (1998). All Rights Reserved. 24 25Abstract 26 27 This document describes an experimental mechanism for mapping 28 entities related to TCP/IP and the UNIX system into X.500 [X500] 29 entries so that they may be resolved with the Lightweight Directory 30 Access Protocol [RFC2251]. A set of attribute types and object 31 classes are proposed, along with specific guidelines for interpreting 32 them. 33 34 The intention is to assist the deployment of LDAP as an 35 organizational nameservice. No proposed solutions are intended as 36 standards for the Internet. Rather, it is hoped that a general 37 consensus will emerge as to the appropriate solution to such 38 problems, leading eventually to the adoption of standards. The 39 proposed mechanism has already been implemented with some success. 40 411. Background and Motivation 42 43 The UNIX (R) operating system, and its derivatives (specifically, 44 those which support TCP/IP and conform to the X/Open Single UNIX 45 specification [XOPEN]) require a means of looking up entities, by 46 matching them against search criteria or by enumeration. (Other 47 operating systems that support TCP/IP may provide some means of 48 resolving some of these entities. This schema is applicable to those 49 environments also.) 50 51 These entities include users, groups, IP services (which map names to 52 IP ports and protocols, and vice versa), IP protocols (which map 53 names to IP protocol numbers and vice versa), RPCs (which map names 54 to ONC Remote Procedure Call [RFC1057] numbers and vice versa), NIS 55 56 57 58Howard Experimental [Page 1] 59 60RFC 2307 Using LDAP as a Network Information Service March 1998 61 62 63 netgroups, booting information (boot parameters and MAC address 64 mappings), filesystem mounts, IP hosts and networks, and RFC822 mail 65 aliases. 66 67 Resolution requests are made through a set of C functions, provided 68 in the UNIX system's C library. For example, the UNIX system utility 69 "ls", which enumerates the contents of a filesystem directory, uses 70 the C library function getpwuid() in order to map user IDs to login 71 names. Once the request is made, it is resolved using a "nameservice" 72 which is supported by the client library. The nameservice may be, at 73 its simplest, a collection of files in the local filesystem which are 74 opened and searched by the C library. Other common nameservices 75 include the Network Information Service (NIS) and the Domain Name 76 System (DNS). (The latter is typically used for resolving hosts, 77 services and networks.) Both these nameservices have the advantage of 78 being distributed and thus permitting a common set of entities to be 79 shared amongst many clients. 80 81 LDAP is a distributed, hierarchical directory service access protocol 82 which is used to access repositories of users and other network- 83 related entities. Because LDAP is often not tightly integrated with 84 the host operating system, information such as users may need to be 85 kept both in LDAP and in an operating system supported nameservice 86 such as NIS. By using LDAP as the the primary means of resolving 87 these entities, these redundancy issues are minimized and the 88 scalability of LDAP can be exploited. (By comparison, NIS services 89 based on flat files do not have the scalability or extensibility of 90 LDAP or X.500.) 91 92 The object classes and attributes defined below are suitable for 93 representing the aforementioned entities in a form compatible with 94 LDAP and X.500 directory services. 95 962. General Issues 97 982.1. Terminology 99 100 The key words "MUST", "SHOULD", and "MAY" used in this document are 101 to be interpreted as described in [RFC2119]. 102 103 For the purposes of this document, the term "nameservice" refers to a 104 service, such as NIS or flat files, that is used by the operating 105 system to resolve entities within a single, local naming context. 106 Contrast this with a "directory service" such as LDAP, which supports 107 extensible schema and multiple naming contexts. 108 109 110 111 112 113 114Howard Experimental [Page 2] 115 116RFC 2307 Using LDAP as a Network Information Service March 1998 117 118 119 The term "NIS-related entities" broadly refers to entities which are 120 typically resolved using the Network Information Service. (NIS was 121 previously known as YP.) Deploying LDAP for resolving these entities 122 does not imply that NIS be used, as a gateway or otherwise. In 123 particular, the host and network classes are generically applicable, 124 and may be implemented on any system that wishes to use LDAP or X.500 125 for host and network resolution. 126 127 The "DUA" (directory user agent) refers to the LDAP client querying 128 these entities, such as an LDAP to NIS gateway or the C library. The 129 "client" refers to the application which ultimately makes use of the 130 information returned by the resolution. It is irrelevant whether the 131 DUA and the client reside within the same address space. The act of 132 the DUA making this information to the client is termed 133 "republishing". 134 135 To avoid confusion, the term "login name" refers to the user's login 136 name (being the value of the uid attribute) and the term "user ID" 137 refers to he user's integer identification number (being the value of 138 the uidNumber attribute). 139 140 The phrases "resolving an entity" and "resolution of entities" refer 141 respectively to enumerating NIS-related entities of a given type, and 142 matching them against a given search criterion. One or more entities 143 are returned as a result of successful "resolutions" (a "match" 144 operation will only return one entity). 145 146 The use of the term UNIX does not confer upon this schema the 147 endorsement of owners of the UNIX trademark. Where necessary, the 148 term "TCP/IP entity" is used to refer to protocols, services, hosts, 149 and networks, and the term "UNIX entity" to its complement. (The 150 former category does not mandate the host operating system supporting 151 the interfaces required for resolving UNIX entities.) 152 153 The OIDs defined below are derived from iso(1) org(3) dod(6) 154 internet(1) directory(1) nisSchema(1). 155 1562.2. Attributes 157 158 The attributes and classes defined in this document are summarized 159 below. 160 161 The following attributes are defined in this document: 162 163 uidNumber 164 gidNumber 165 gecos 166 homeDirectory 167 168 169 170Howard Experimental [Page 3] 171 172RFC 2307 Using LDAP as a Network Information Service March 1998 173 174 175 loginShell 176 shadowLastChange 177 shadowMin 178 shadowMax 179 shadowWarning 180 shadowInactive 181 shadowExpire 182 shadowFlag 183 memberUid 184 memberNisNetgroup 185 nisNetgroupTriple 186 ipServicePort 187 ipServiceProtocol 188 ipProtocolNumber 189 oncRpcNumber 190 ipHostNumber 191 ipNetworkNumber 192 ipNetmaskNumber 193 macAddress 194 bootParameter 195 bootFile 196 nisMapName 197 nisMapEntry 198 199 Additionally, some of the attributes defined in [RFC2256] are 200 required. 201 2022.3. Object classes 203 204 The following object classes are defined in this document: 205 206 posixAccount 207 shadowAccount 208 posixGroup 209 ipService 210 ipProtocol 211 oncRpc 212 ipHost 213 ipNetwork 214 nisNetgroup 215 nisMap 216 nisObject 217 ieee802Device 218 bootableDevice 219 220 Additionally, some of the classes defined in [RFC2256] are required. 221 222 223 224 225 226Howard Experimental [Page 4] 227 228RFC 2307 Using LDAP as a Network Information Service March 1998 229 230 2312.4. Syntax definitions 232 233 The following syntax definitions [RFC2252] are used by this schema. 234 The nisNetgroupTripleSyntax represents NIS netgroup triples: 235 236 ( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax' 237 DESC 'NIS netgroup triple' ) 238 239 Values in this syntax are represented by the following: 240 241 nisnetgrouptriple = "(" hostname "," username "," domainname ")" 242 hostname = "" / "-" / keystring 243 username = "" / "-" / keystring 244 domainname = "" / "-" / keystring 245 246 X.500 servers may use the following representation of the above 247 syntax: 248 249 nisNetgroupTripleSyntax ::= SEQUENCE { 250 hostname [0] IA5String OPTIONAL, 251 username [1] IA5String OPTIONAL, 252 domainname [2] IA5String OPTIONAL 253 } 254 255 The bootParameterSyntax syntax represents boot parameters: 256 257 ( nisSchema.0.1 NAME 'bootParameterSyntax' 258 DESC 'Boot parameter' ) 259 260 where: 261 262 bootparameter = key "=" server ":" path 263 key = keystring 264 server = keystring 265 path = keystring 266 267 X.500 servers may use the following representation of the above 268 syntax: 269 270 bootParameterSyntax ::= SEQUENCE { 271 key IA5String, 272 server IA5String, 273 path IA5String 274 } 275 276 Values adhering to these syntaxes are encoded as strings by LDAP 277 servers. 278 279 280 281 282Howard Experimental [Page 5] 283 284RFC 2307 Using LDAP as a Network Information Service March 1998 285 286 2873. Attribute definitions 288 289 This section contains attribute definitions to be implemented by DUAs 290 supporting this schema. 291 292 ( nisSchema.1.0 NAME 'uidNumber' 293 DESC 'An integer uniquely identifying a user in an 294 administrative domain' 295 EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) 296 297 ( nisSchema.1.1 NAME 'gidNumber' 298 DESC 'An integer uniquely identifying a group in an 299 administrative domain' 300 EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) 301 302 ( nisSchema.1.2 NAME 'gecos' 303 DESC 'The GECOS field; the common name' 304 EQUALITY caseIgnoreIA5Match 305 SUBSTRINGS caseIgnoreIA5SubstringsMatch 306 SYNTAX 'IA5String' SINGLE-VALUE ) 307 308 ( nisSchema.1.3 NAME 'homeDirectory' 309 DESC 'The absolute path to the home directory' 310 EQUALITY caseExactIA5Match 311 SYNTAX 'IA5String' SINGLE-VALUE ) 312 313 ( nisSchema.1.4 NAME 'loginShell' 314 DESC 'The path to the login shell' 315 EQUALITY caseExactIA5Match 316 SYNTAX 'IA5String' SINGLE-VALUE ) 317 318 ( nisSchema.1.5 NAME 'shadowLastChange' 319 EQUALITY integerMatch 320 SYNTAX 'INTEGER' SINGLE-VALUE ) 321 322 ( nisSchema.1.6 NAME 'shadowMin' 323 EQUALITY integerMatch 324 SYNTAX 'INTEGER' SINGLE-VALUE ) 325 326 ( nisSchema.1.7 NAME 'shadowMax' 327 EQUALITY integerMatch 328 SYNTAX 'INTEGER' SINGLE-VALUE ) 329 330 ( nisSchema.1.8 NAME 'shadowWarning' 331 EQUALITY integerMatch 332 SYNTAX 'INTEGER' SINGLE-VALUE ) 333 334 ( nisSchema.1.9 NAME 'shadowInactive' 335 336 337 338Howard Experimental [Page 6] 339 340RFC 2307 Using LDAP as a Network Information Service March 1998 341 342 343 EQUALITY integerMatch 344 SYNTAX 'INTEGER' SINGLE-VALUE ) 345 346 ( nisSchema.1.10 NAME 'shadowExpire' 347 EQUALITY integerMatch 348 SYNTAX 'INTEGER' SINGLE-VALUE ) 349 350 ( nisSchema.1.11 NAME 'shadowFlag' 351 EQUALITY integerMatch 352 SYNTAX 'INTEGER' SINGLE-VALUE ) 353 354 ( nisSchema.1.12 NAME 'memberUid' 355 EQUALITY caseExactIA5Match 356 SUBSTRINGS caseExactIA5SubstringsMatch 357 SYNTAX 'IA5String' ) 358 359 ( nisSchema.1.13 NAME 'memberNisNetgroup' 360 EQUALITY caseExactIA5Match 361 SUBSTRINGS caseExactIA5SubstringsMatch 362 SYNTAX 'IA5String' ) 363 364 ( nisSchema.1.14 NAME 'nisNetgroupTriple' 365 DESC 'Netgroup triple' 366 SYNTAX 'nisNetgroupTripleSyntax' ) 367 368 ( nisSchema.1.15 NAME 'ipServicePort' 369 EQUALITY integerMatch 370 SYNTAX 'INTEGER' SINGLE-VALUE ) 371 372 ( nisSchema.1.16 NAME 'ipServiceProtocol' 373 SUP name ) 374 375 ( nisSchema.1.17 NAME 'ipProtocolNumber' 376 EQUALITY integerMatch 377 SYNTAX 'INTEGER' SINGLE-VALUE ) 378 379 ( nisSchema.1.18 NAME 'oncRpcNumber' 380 EQUALITY integerMatch 381 SYNTAX 'INTEGER' SINGLE-VALUE ) 382 383 ( nisSchema.1.19 NAME 'ipHostNumber' 384 DESC 'IP address as a dotted decimal, eg. 192.168.1.1, 385 omitting leading zeros' 386 EQUALITY caseIgnoreIA5Match 387 SYNTAX 'IA5String{128}' ) 388 389 ( nisSchema.1.20 NAME 'ipNetworkNumber' 390 DESC 'IP network as a dotted decimal, eg. 192.168, 391 392 393 394Howard Experimental [Page 7] 395 396RFC 2307 Using LDAP as a Network Information Service March 1998 397 398 399 omitting leading zeros' 400 EQUALITY caseIgnoreIA5Match 401 SYNTAX 'IA5String{128}' SINGLE-VALUE ) 402 403 ( nisSchema.1.21 NAME 'ipNetmaskNumber' 404 DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, 405 omitting leading zeros' 406 EQUALITY caseIgnoreIA5Match 407 SYNTAX 'IA5String{128}' SINGLE-VALUE ) 408 409 ( nisSchema.1.22 NAME 'macAddress' 410 DESC 'MAC address in maximal, colon separated hex 411 notation, eg. 00:00:92:90:ee:e2' 412 EQUALITY caseIgnoreIA5Match 413 SYNTAX 'IA5String{128}' ) 414 415 ( nisSchema.1.23 NAME 'bootParameter' 416 DESC 'rpc.bootparamd parameter' 417 SYNTAX 'bootParameterSyntax' ) 418 419 ( nisSchema.1.24 NAME 'bootFile' 420 DESC 'Boot image name' 421 EQUALITY caseExactIA5Match 422 SYNTAX 'IA5String' ) 423 424 ( nisSchema.1.26 NAME 'nisMapName' 425 SUP name ) 426 427 ( nisSchema.1.27 NAME 'nisMapEntry' 428 EQUALITY caseExactIA5Match 429 SUBSTRINGS caseExactIA5SubstringsMatch 430 SYNTAX 'IA5String{1024}' SINGLE-VALUE ) 431 4324. Class definitions 433 434 This section contains class definitions to be implemented by DUAs 435 supporting the schema. 436 437 The rfc822MailGroup object class MAY be used to represent a mail 438 group for the purpose of alias expansion. Several alternative schemes 439 for mail routing and delivery using LDAP directories, which are 440 outside the scope of this document. 441 442 ( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY 443 DESC 'Abstraction of an account with POSIX attributes' 444 MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) 445 MAY ( userPassword $ loginShell $ gecos $ description ) ) 446 447 448 449 450Howard Experimental [Page 8] 451 452RFC 2307 Using LDAP as a Network Information Service March 1998 453 454 455 ( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY 456 DESC 'Additional attributes for shadow passwords' 457 MUST uid 458 MAY ( userPassword $ shadowLastChange $ shadowMin 459 shadowMax $ shadowWarning $ shadowInactive $ 460 shadowExpire $ shadowFlag $ description ) ) 461 462 ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL 463 DESC 'Abstraction of a group of accounts' 464 MUST ( cn $ gidNumber ) 465 MAY ( userPassword $ memberUid $ description ) ) 466 467 ( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL 468 DESC 'Abstraction an Internet Protocol service. 469 Maps an IP port and protocol (such as tcp or udp) 470 to one or more names; the distinguished value of 471 the cn attribute denotes the service's canonical 472 name' 473 MUST ( cn $ ipServicePort $ ipServiceProtocol ) 474 MAY ( description ) ) 475 476 ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL 477 DESC 'Abstraction of an IP protocol. Maps a protocol number 478 to one or more names. The distinguished value of the cn 479 attribute denotes the protocol's canonical name' 480 MUST ( cn $ ipProtocolNumber $ description ) 481 MAY description ) 482 483 ( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL 484 DESC 'Abstraction of an Open Network Computing (ONC) 485 [RFC1057] Remote Procedure Call (RPC) binding. 486 This class maps an ONC RPC number to a name. 487 The distinguished value of the cn attribute denotes 488 the RPC service's canonical name' 489 MUST ( cn $ oncRpcNumber $ description ) 490 MAY description ) 491 492 ( nisSchema.2.6 NAME 'ipHost' SUP top AUXILIARY 493 494 DESC 'Abstraction of a host, an IP device. The distinguished 495 value of the cn attribute denotes the host's canonical 496 name. Device SHOULD be used as a structural class' 497 MUST ( cn $ ipHostNumber ) 498 MAY ( l $ description $ manager ) ) 499 500 ( nisSchema.2.7 NAME 'ipNetwork' SUP top STRUCTURAL 501 DESC 'Abstraction of a network. The distinguished value of 502 the cn attribute denotes the network's canonical name' 503 504 505 506Howard Experimental [Page 9] 507 508RFC 2307 Using LDAP as a Network Information Service March 1998 509 510 511 MUST ( cn $ ipNetworkNumber ) 512 MAY ( ipNetmaskNumber $ l $ description $ manager ) ) 513 514 ( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL 515 DESC 'Abstraction of a netgroup. May refer to other netgroups' 516 MUST cn 517 MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) 518 519 ( nisSchema.2.09 NAME 'nisMap' SUP top STRUCTURAL 520 DESC 'A generic abstraction of a NIS map' 521 MUST nisMapName 522 MAY description ) 523 524 ( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL 525 DESC 'An entry in a NIS map' 526 MUST ( cn $ nisMapEntry $ nisMapName ) 527 MAY description ) 528 529 ( nisSchema.2.11 NAME 'ieee802Device' SUP top AUXILIARY 530 DESC 'A device with a MAC address; device SHOULD be 531 used as a structural class' 532 MAY macAddress ) 533 534 ( nisSchema.2.12 NAME 'bootableDevice' SUP top AUXILIARY 535 DESC 'A device with boot parameters; device SHOULD be 536 used as a structural class' 537 MAY ( bootFile $ bootParameter ) ) 538 5395. Implementation details 540 5415.1. Suggested resolution methods 542 543 The preferred means of directing a client application (one using the 544 shared services of the C library) to use LDAP as its information 545 source for the functions listed in 5.2 is to modify the source code 546 to directly query LDAP. As the source to commercial C libraries and 547 applications is rarely available to the end-user, one could emulate a 548 supported nameservice (such as NIS). (This is also an appropriate 549 opportunity to perform caching of entries across process address 550 spaces.) In the case of NIS, reference implementations are widely 551 available and the RPC interface is well known. 552 553 The means by which the operating system is directed to use LDAP is 554 implementation dependent. For example, some operating systems and C 555 libraries support end-user extensible resolvers using dynamically 556 loadable libraries and a nameservice "switch". The means in which the 557 DUA locates LDAP servers is also implementation dependent. 558 559 560 561 562Howard Experimental [Page 10] 563 564RFC 2307 Using LDAP as a Network Information Service March 1998 565 566 5675.2. Affected library functions 568 569 The following functions are typically found in the C libraries of 570 most UNIX and POSIX compliant systems. An LDAP search filter 571 [RFC2254] which may be used to satisfy the function call is included 572 alongside each function name. Parameters are denoted by %s and %d for 573 string and integer arguments, respectively. Long lines are broken. 574 575 getpwnam() (&(objectClass=posixAccount)(uid=%s)) 576 getpwuid() (&(objectClass=posixAccount) 577 (uidNumber=%d)) 578 getpwent() (objectClass=posixAccount) 579 580 getspnam() (&(objectClass=shadowAccount)(uid=%s)) 581 getspent() (objectClass=shadowAccount) 582 583 getgrnam() (&(objectClass=posixGroup)(cn=%s)) 584 getgrgid() (&(objectClass=posixGroup) 585 (gidNumber=%d)) 586 getgrent() (objectClass=posixGroup) 587 588 getservbyname() (&(objectClass=ipService) 589 (cn=%s)(ipServiceProtocol=%s)) 590 getservbyport() (&(objectClass=ipService) 591 (ipServicePort=%d) 592 (ipServiceProtocol=%s)) 593 getservent() (objectClass=ipService) 594 595 getrpcbyname() (&(objectClass=oncRpc)(cn=%s)) 596 getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d)) 597 getrpcent() (objectClass=oncRpc) 598 599 getprotobyname() (&(objectClass=ipProtocol)(cn=%s)) 600 getprotobynumber() (&(objectClass=ipProtocol) 601 (ipProtocolNumber=%d)) 602 getprotoent() (objectClass=ipProtocol) 603 604 gethostbyname() (&(objectClass=ipHost)(cn=%s)) 605 gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s)) 606 gethostent() (objectClass=ipHost) 607 608 getnetbyname() (&(objectClass=ipNetwork)(cn=%s)) 609 getnetbyaddr() (&(objectClass=ipNetwork) 610 (ipNetworkNumber=%s)) 611 getnetent() (objectClass=ipNetwork) 612 613 setnetgrent() (&(objectClass=nisNetgroup)(cn=%s)) 614 615 616 617 618Howard Experimental [Page 11] 619 620RFC 2307 Using LDAP as a Network Information Service March 1998 621 622 6235.3. Interpreting user and group entries 624 625 User and group resolution is initiated by the functions prefixed by 626 getpw and getgr respectively. The uid attribute contains the user's 627 login name. The cn attribute, in posixGroup entries, contains the 628 group's name. 629 630 The account object class provides a convenient structural class for 631 posixAccount, and SHOULD be used where additional attributes are not 632 required. 633 634 It is suggested that uid and cn are used as the RDN attribute type 635 for posixAccount and posixGroup entries, respectively. 636 637 An account's GECOS field is preferably determined by a value of the 638 gecos attribute. If no gecos attribute exists, the value of the cn 639 attribute MUST be used. (The existence of the gecos attribute allows 640 information embedded in the GECOS field, such as a user's telephone 641 number, to be returned to the client without overloading the cn 642 attribute. It also accommodates directories where the common name 643 does not contain the user's full name.) 644 645 An entry of class posixAccount, posixGroup, or shadowAccount without 646 a userPassword attribute MUST NOT be used for authentication. The 647 client should be returned a non-matchable password such as "x". 648 649 userPassword values MUST be represented by following syntax: 650 651 passwordvalue = schemeprefix encryptedpassword 652 schemeprefix = "{" scheme "}" 653 scheme = "crypt" / "md5" / "sha" / altscheme 654 altscheme = "x-" keystring 655 encryptedpassword = encrypted password 656 657 The encrypted password contains of a plaintext key hashed using the 658 algorithm scheme. 659 660 userPassword values which do not adhere to this syntax MUST NOT be 661 used for authentication. The DUA MUST iterate through the values of 662 the attribute until a value matching the above syntax is found. Only 663 if encryptedpassword is an empty string does the user have no 664 password. DUAs are not required to consider encryption schemes which 665 the client will not recognize; in most cases, it may be sufficient to 666 consider only "crypt". 667 668 Below is an example of a userPassword attribute: 669 670 userPassword: {crypt}X5/DBrWPOQQaI 671 672 673 674Howard Experimental [Page 12] 675 676RFC 2307 Using LDAP as a Network Information Service March 1998 677 678 679 A future standard may specify LDAP v3 attribute descriptions to 680 represent hashed userPasswords, as noted below. This schema MUST NOT 681 be used with LDAP v2 DUAs and DSAs. 682 683 attributetype = attributename sep attributeoption 684 attributename = "userPassword" 685 sep = ";" 686 attributeoption = schemeclass "-" scheme 687 schemeclass = "hash" / altschemeclass 688 scheme = "crypt" / "md5" / "sha" / altscheme 689 altschemeclass = "x-" keystring 690 altscheme = keystring 691 692 693 Below is an example of a userPassword attribute, represented with an 694 LDAP v3 attribute description: 695 696 userPassword;hash-crypt: X5/DBrWPOQQaI 697 698 699 A DUA MAY utilise the attributes in the shadowAccount class to 700 provide shadow password service (getspnam() and getspent()). In such 701 cases, the DUA MUST NOT make use of the userPassword attribute for 702 getpwnam() et al, and MUST return a non-matchable password (such as 703 "x") to the client instead. 704 7055.4. Interpreting hosts and networks 706 707 The ipHostNumber and ipNetworkNumber attributes are defined in 708 preference to dNSRecord (defined in [RFC1279]), in order to simplify 709 the DUA's role in interpreting entries in the directory. A dNSRecord 710 expresses a complete resource record, including time to live and 711 class data, which is extraneous to this schema. 712 713 Additionally, the ipHost and ipNetwork classes permit a host or 714 network (respectively) and all its aliases to be represented by a 715 single entry in the directory. This is not necessarily possible if a 716 DNS resource record is mapped directly to an LDAP entry. 717 Implementations that wish to use LDAP to master DNS zone information 718 are not precluded from doing so, and may simply avoid the ipHost and 719 ipNetwork classes. 720 721 This document redefines, although not exclusively, the ipNetwork 722 class defined in [RFC1279], in order to achieve consistent naming 723 with ipHost. The ipNetworkNumber attribute is also used in the 724 siteContact object class [ROSE]. 725 726 727 728 729 730Howard Experimental [Page 13] 731 732RFC 2307 Using LDAP as a Network Information Service March 1998 733 734 735 The trailing zeros in a network address MUST be omitted. CIDR-style 736 network addresses (eg. 192.168.1/24) MAY be used. 737 738 Hosts with IPv6 addresses MUST be written in their "preferred" form 739 as defined in section 2.2.1 of [RFC1884], such that all components of 740 the address are indicated and leading zeros are omitted. This 741 provides a consistent means of resolving ipHosts by address. 742 7435.5. Interpreting other entities 744 745 In general, a one-to-one mapping between entities and LDAP entries is 746 proposed, in that each entity has exactly one representation in the 747 DIT. In some cases this is not feasible; for example, a service which 748 is represented in more than one protocol domain. Consider the 749 following entry: 750 751 dn: cn=domain, dc=aja, dc=com 752 cn: domain 753 cn: nameserver 754 objectClass: top 755 objectClass: ipService 756 ipServicePort: 53 757 ipServiceProtocol: tcp 758 ipServiceProtocol: udp 759 760 This entry MUST map to the following two (2) services entities: 761 762 domain 53/tcp nameserver 763 domain 53/udp nameserver 764 765 While the above two entities may be represented as separate LDAP 766 entities, with different distinguished names (such as 767 cn=domain+ipServiceProtocol=tcp, ... and 768 cn=domain+ipServiceProtocol=udp, ...) it is convenient to represent 769 them as a single entry. (If a service is represented in multiple 770 protocol domains with different ports, then multiple entries are 771 required; multivalued RDNs may be used to distinguish them.) 772 773 With the exception of userPassword values, which are parsed according 774 to the syntax considered in section 5.2, any empty values (consisting 775 of a zero length string) are returned by the DUA to the client. The 776 DUA MUST reject any entries which do not conform to the schema 777 (missing mandatory attributes). Non-conforming entries SHOULD be 778 ignored while enumerating entries. 779 780 The nisObject object class MAY be used as a generic means of 781 representing NIS entities. Its use is not encouraged; where support 782 for entities not described in this schema is desired, an appropriate 783 784 785 786Howard Experimental [Page 14] 787 788RFC 2307 Using LDAP as a Network Information Service March 1998 789 790 791 schema should be devised. Implementors are strongly advised to 792 support end-user extensible mappings between NIS entities and object 793 classes. (Where the nisObject class is used, the nisMapName attribute 794 may be used as a RDN.) 795 7965.6. Canonicalizing entries with multi-valued naming attributes 797 798 For entities such as hosts, services, networks, protocols, and RPCs, 799 where there may be one or more aliases, the respective entry's 800 relative distinguished name SHOULD be used to determine the canonical 801 name. Any other values for the same attribute are used as aliases. 802 For example, the service described in section 5.5 has the canonical 803 name "domain" and exactly one alias, "nameserver". 804 805 The schema in this document generally only defines one attribute per 806 class which is suitable for distinguishing an entity (excluding any 807 attributes with integer syntax; it is assumed that entries will be 808 distinguished on name). Usually, this is the common name (cn) 809 attribute. This aids the DUA in determining the canonical name of an 810 entity, as it can examine the value of the relative distinguished 811 name. Aliases are thus any values of the distinguishing attribute 812 (such as cn) which do not match the canonical name of the entity. 813 814 In the event that a different attribute is used to distinguish the 815 entry, as may be the case where these object classes are used as 816 auxiliary classes, the entry's canonical name may not be present in 817 the RDN. In this case, the DUA MUST choose one of the non- 818 distinguished values to represent the entity's canonical name. As the 819 directory server guarantees no ordering of attribute values, it may 820 not be possible to distinguish an entry deterministically. This 821 ambiguity SHOULD NOT be resolved by mapping one directory entry into 822 multiple entities. 823 8246. Implementation focus 825 826 A NIS server which uses LDAP instead of local files has been 827 developed which supports the schema defined in this document. 828 829 A reference implementation of the C library resolution code has been 830 written for the Free Software Foundation. It may support other C 831 libraries which support the Name Service Switch (NSS) or the 832 Information Retrieval Service (IRS). 833 834 The author has made available a freely distributable set of scripts 835 which parses local databases such as /etc/passwd and /etc/hosts into 836 a form suitable for loading into an LDAP server. 837 838 839 840 841 842Howard Experimental [Page 15] 843 844RFC 2307 Using LDAP as a Network Information Service March 1998 845 846 8477. Security Considerations 848 849 The entirety of related security considerations are outside the scope 850 of this document. It is noted that making passwords encrypted with a 851 widely understood hash function (such as crypt()) available to non- 852 privileged users is dangerous because it exposes them to dictionary 853 and brute-force attacks. This is proposed only for compatibility 854 with existing UNIX system implementations. Sites where security is 855 critical SHOULD consider using a strong authentication service for 856 user authentication. 857 858 Alternatively, the encrypted password could be made available only to 859 a subset of privileged DUAs, which would provide "shadow" password 860 service to client applications. This may be difficult to enforce. 861 862 Because the schema represents operating system-level entities, access 863 to these entities SHOULD be granted on a discretionary basis. (There 864 is little point in restricting access to data which will be 865 republished without restriction, however.) It is particularly 866 important that only administrators can modify entries defined in this 867 schema, with the exception of allowing a principal to change their 868 password (which may be done on behalf of the user by a client bound 869 as a superior principal, such that password restrictions may be 870 enforced). For example, if a user were allowed to change the value of 871 their uidNumber attribute, they could subvert security by 872 equivalencing their account with the superuser account. 873 874 A subtree of the DIT which is to be republished by a DUA (such as a 875 NIS gateway) SHOULD be within the same administrative domain that the 876 republishing DUA represents. (For example, principals outside an 877 organization, while conceivably part of the DIT, should not be 878 considered with the same degree of authority as those within the 879 organization.) 880 881 Finally, care should be exercised with integer attributes of a 882 sensitive nature (particularly the uidNumber and gidNumber 883 attributes) which contain zero-length values. DUAs MAY treat such 884 values as corresponding to the "nobody" or "nogroup" user and group, 885 respectively. 886 8878. Acknowledgements 888 889 Thanks to Leif Hedstrom of Netscape Communications Corporation, 890 Michael Grant and Rosanna Lee of Sun Microsystems Inc., Ed Reed of 891 Novell Inc., and Mark Wahl of Critical Angle Inc. for their valuable 892 contributions to the development of this schema. Thanks to Andrew 893 Josey of The Open Group for clarifying the use of the UNIX trademark, 894 and to Tim Howes and Peter J. Cherny for their support. 895 896 897 898Howard Experimental [Page 16] 899 900RFC 2307 Using LDAP as a Network Information Service March 1998 901 902 903 UNIX is a registered trademark of The Open Group. 904 9059. References 906 907 [RFC1057] 908 Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol 909 Specification Version 2", RFC 1057, June 1988. 910 911 [RFC1279] 912 Kille, S., "X.500 and Domains", RFC 1279, November 1991. 913 914 [RFC1884] 915 Hinden, R., and S. Deering, "IP Version 6 Addressing 916 Architecture", RFC 1884, December 1995. 917 918 [RFC2119] 919 Bradner, S., "Key Words for use in RFCs to Indicate Requirement 920 Levels", BCP 14, RFC 2119, March 1997. 921 922 [RFC2251] 923 Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access 924 Protocol (v3)", RFC 2251, December 1997. 925 926 [RFC2252] 927 Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight 928 Directory Access Protocol (v3): Attribute Syntax Definitions", 929 RFC 2252, December 1997. 930 931 [RFC2254] 932 Howes, T., "The String Representation of LDAP Search Filters", 933 RFC 2254, December 1997. 934 935 [RFC2256] 936 Wahl, M., "A Summary of the X.500(96) User Schema for use with 937 LDAPv3", RFC 2256, December 1997. 938 939 [ROSE] 940 M. T. Rose, "The Little Black Book: Mail Bonding with OSI 941 Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc., 942 1992. 943 944 [X500] 945 "Information Processing Systems - Open Systems Interconnection - 946 The Directory: Overview of Concepts, Models and Service", 947 ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. 948 949 950 951 952 953 954Howard Experimental [Page 17] 955 956RFC 2307 Using LDAP as a Network Information Service March 1998 957 958 959 [XOPEN] 960 ISO/IEC 9945-1:1990, Information Technology - Portable Operating 961 Systems Interface (POSIX) - Part 1: Systems Application 962 Programming Interface (API) [C Language] 963 96410. Author's Address 965 966 Luke Howard 967 PO Box 59 968 Central Park Vic 3145 969 Australia 970 971 EMail: lukeh@xedoc.com 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010Howard Experimental [Page 18] 1011 1012RFC 2307 Using LDAP as a Network Information Service March 1998 1013 1014 1015A. Example entries 1016 1017 The examples described in this section are provided to illustrate the 1018 schema described in this memo. They are not meant to be exhaustive. 1019 1020 The following entry is an example of the posixAccount class: 1021 1022 dn: uid=lester, dc=aja, dc=com 1023 objectClass: top 1024 objectClass: account 1025 objectClass: posixAccount 1026 uid: lester 1027 cn: Lester the Nightfly 1028 userPassword: {crypt}X5/DBrWPOQQaI 1029 gecos: Lester 1030 loginShell: /bin/csh 1031 uidNumber: 10 1032 gidNumber: 10 1033 homeDirectory: /home/lester 1034 1035 1036 This corresponds the UNIX system password file entry: 1037 1038 lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh 1039 1040 The following entry is an example of the ipHost class: 1041 1042 dn: cn=peg.aja.com, dc=aja, dc=com 1043 objectClass: top 1044 objectClass: device 1045 objectClass: ipHost 1046 objectClass: bootableDevice 1047 objectClass: ieee802Device 1048 cn: peg.aja.com 1049 cn: www.aja.com 1050 ipHostNumber: 10.0.0.1 1051 macAddress: 00:00:92:90:ee:e2 1052 bootFile: mach 1053 bootParameter: root=fs:/nfsroot/peg 1054 bootParameter: swap=fs:/nfsswap/peg 1055 bootParameter: dump=fs:/nfsdump/peg 1056 1057 This entry represents the host canonically peg.aja.com, also known as 1058 www.aja.com. The Ethernet address and four boot parameters are also 1059 specified. 1060 1061 1062 1063 1064 1065 1066Howard Experimental [Page 19] 1067 1068RFC 2307 Using LDAP as a Network Information Service March 1998 1069 1070 1071 An example of the nisNetgroup class: 1072 1073 dn: cn=nightfly, dc=aja, dc=com 1074 objectClass: top 1075 objectClass: nisNetgroup 1076 cn: nightfly 1077 nisNetgroupTriple: (charlemagne,peg,dunes.aja.com) 1078 nisNetgroupTriple: (lester,-,) 1079 memberNisNetgroup: kamakiriad 1080 1081 This entry represents the netgroup nightfly, which contains two 1082 triples (the user charlemagne, the host peg, and the domain 1083 dunes.aja.com; and, the user lester, no host, and any domain) and one 1084 netgroup (kamakiriad). 1085 1086 Finally, an example of the nisObject class: 1087 1088 dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com 1089 objectClass: top 1090 objectClass: nisMap 1091 nisMapName: tracks 1092 1093 dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com 1094 objectClass: top 1095 objectClass: nisObject 1096 cn: Maxine 1097 nisMapName: tracks 1098 nisMapEntry: Nightfly$4 1099 1100 This entry represents the NIS map tracks, and a single map entry. 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122Howard Experimental [Page 20] 1123 1124RFC 2307 Using LDAP as a Network Information Service March 1998 1125 1126 1127Full Copyright Statement 1128 1129 Copyright (C) The Internet Society (1998). All Rights Reserved. 1130 1131 This document and translations of it may be copied and furnished to 1132 others, and derivative works that comment on or otherwise explain it 1133 or assist in its implementation may be prepared, copied, published 1134 and distributed, in whole or in part, without restriction of any 1135 kind, provided that the above copyright notice and this paragraph are 1136 included on all such copies and derivative works. However, this 1137 document itself may not be modified in any way, such as by removing 1138 the copyright notice or references to the Internet Society or other 1139 Internet organizations, except as needed for the purpose of 1140 developing Internet standards in which case the procedures for 1141 copyrights defined in the Internet Standards process must be 1142 followed, or as required to translate it into languages other than 1143 English. 1144 1145 The limited permissions granted above are perpetual and will not be 1146 revoked by the Internet Society or its successors or assigns. 1147 1148 This document and the information contained herein is provided on an 1149 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1150 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1151 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1152 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1153 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178Howard Experimental [Page 21] 1179 1180