idnits 2.17.1 draft-howard-rfc2307bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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. ** The abstract seems to contain references ([RFC4511], [UNIX]), 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 1 instance 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. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2307, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 808 has weird spacing: '... 53/tcp names...' == Line 809 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 (August 9, 2009) is 5375 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) == Outdated reference: A later version (-11) exists of draft-behera-ldap-password-policy-10 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Howard 3 Internet-Draft PADL Software 4 Obsoletes: 2307 (if approved) H. Chu, Ed. 5 Intended status: Informational Symas Corp. 6 Expires: February 10, 2010 August 9, 2009 8 An Approach for Using LDAP as a Network Information Service 9 draft-howard-rfc2307bis-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 10, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes a mechanism for mapping entities related to 48 TCP/IP and the UNIX system [UNIX] into [X.500] entries so that they 49 may be resolved with the Lightweight Directory Access Protocol 50 [RFC4511]. A set of attribute types and object classes are proposed, 51 along with specific guidelines for interpreting them. The intention 52 is to assist the deployment of LDAP as an organizational nameservice. 53 No proposed solutions are intended as standards for the Internet. 54 Rather, it is hoped that a general consensus will emerge as to the 55 appropriate solution to such problems, leading eventually to the 56 adoption of standards. The proposed mechanism has already been 57 implemented with some success. 59 1. Background and Motivation 61 The UNIX (R) operating system, and its derivatives (specifically, 62 those which support TCP/IP and conform to the X/Open Single UNIX 63 specification [UNIX]) require a means of looking up entities, by 64 matching them against search criteria or by enumeration. (Other 65 operating systems that support TCP/IP may provide some means of 66 resolving some of these entities. This schema is applicable to those 67 environments also.) 69 These entities include users, groups, IP services (which map names to 70 IP ports and protocols, and vice versa), IP protocols (which map 71 names to IP protocol numbers and vice versa), RPCs (which map names 72 to ONC Remote Procedure Call [RFC1057] numbers and vice versa), NIS 73 netgroups, booting information (boot parameters and MAC address 74 mappings), filesystem mounts, IP hosts and networks. 76 Resolution requests are made through a set of C functions, provided 77 in the UNIX system's C library. For example, the UNIX system utility 78 "ls", which enumerates the contents of a filesystem directory, uses 79 the C library function getpwuid() in order to map user IDs to login 80 names. Once the request is made, it is resolved using a 81 "nameservice" which is supported by the client library. The 82 nameservice may be, at its simplest, a collection of files in the 83 local filesystem which are opened and searched by the C library. 84 Other common nameservices include the Network Information Service 85 (NIS) and the Domain Name System (DNS) [RFC1034]. (The latter is 86 typically used for resolving hosts, services and networks.) Both 87 these nameservices have the advantage of being distributed and thus 88 permitting a common set of entities to be shared amongst many 89 clients. 91 LDAP is a distributed, hierarchical directory service access protocol 92 which is used to access repositories of users and other network- 93 related entities. Because LDAP is often not tightly integrated with 94 the host operating system, information such as users may need to be 95 kept both in LDAP and in an operating system supported nameservice 96 such as NIS. By using LDAP as the primary means of resolving these 97 entities, these redundancy issues are minimized and the scalability 98 of LDAP can be exploited. (By comparison, NIS services based on flat 99 files do not have the scalability or extensibility of LDAP or X.500.) 101 The object classes and attributes defined below are suitable for 102 representing the aforementioned entities in a form compatible with 103 LDAP and X.500 directory services. 105 2. General Issues 107 2.1. Terminology 109 The key words "MUST", "SHOULD", and "MAY" used in this document are 110 to be interpreted as described in [RFC2119]. 112 For the purposes of this document, the term "nameservice" refers to a 113 service, such as NIS or flat files, that is used by the operating 114 system to resolve entities within a single, local naming context. 115 Contrast this with a "directory service" such as LDAP, which supports 116 extensible schema and multiple naming contexts. 118 The term "NIS-related entities" broadly refers to entities which are 119 typically resolved using the Network Information Service. (NIS was 120 previously known as YP.) Deploying LDAP for resolving these entities 121 does not imply that NIS be used, as a gateway or otherwise. In 122 particular, the host and network classes are generically applicable, 123 and may be implemented on any system that wishes to use LDAP or X.500 124 for host and network resolution. 126 The "DUA" (directory user agent) refers to the LDAP client querying 127 these entities, such as an LDAP to NIS gateway or the C library. The 128 "client" refers to the application which ultimately makes use of the 129 information returned by the resolution. It is irrelevant whether the 130 DUA and the client reside within the same address space. The act of 131 the DUA making this information to the client is termed 132 "republishing". 134 To avoid confusion, the term "login name" refers to the user's login 135 name (being the value of the uid attribute) and the term "user ID" 136 refers to the user's integer identification number (being the value 137 of the uidNumber attribute). 139 The phrases "resolving an entity" and "resolution of entities" refer 140 respectively to enumerating NIS-related entities of a given type, and 141 matching them against a given search criterion. One or more entities 142 are returned as a result of successful "resolutions" (a "match" 143 operation will only return one entity). 145 The use of the term UNIX does not confer upon this schema the 146 endorsement of owners of the UNIX trademark. Where necessary, the 147 term "TCP/IP entity" is used to refer to protocols, services, hosts, 148 and networks, and the term "UNIX entity" to its complement. (The 149 former category does not mandate the host operating system supporting 150 the interfaces required for resolving UNIX entities.) 152 The OIDs defined below are derived from iso(1) org(3) dod(6) 153 internet(1) directory(1) nisSchema(1) 155 2.2. Schema 157 The attributes and classes defined in this document are summarized 158 below. 160 2.2.1. Attributes 162 The following attributes are defined in this document: 164 uidNumber 165 gidNumber 166 gecos 167 homeDirectory 168 loginShell 169 shadowLastChange 170 shadowMin 171 shadowMax 172 shadowWarning 173 shadowInactive 174 shadowExpire 175 shadowFlag 176 memberUid 177 memberNisNetgroup 178 nisNetgroupTriple 179 ipServicePort 180 ipServiceProtocol 181 ipProtocolNumber 182 oncRpcNumber 183 ipHostNumber 184 ipNetworkNumber 185 ipNetmaskNumber 186 macAddress 187 bootParameter 188 bootFile 189 nisMapName 190 nisMapEntry 191 nisPublicKey 192 nisSecretKey 193 nisDomain 194 automountMapName 195 automountKey 196 automountInformation 198 Additionally, some of the attributes defined in [RFC4519] and 199 [RFC3112] are required. 201 2.2.2. Attribute Option 203 Centralizing a name service in LDAP allows heterogeneous systems to 204 obtain their information from a single place. However in some cases, 205 this information cannot be used uniformly on all of the client 206 systems. These attribute options are defined to allow system- 207 specific values to be used where necessary. The options are defined 208 as the following: 210 host- 211 hostos- 213 where hostname is a string representing the name of a specific 214 machine, and ostype is a string representing a particular operating 215 system. 217 For example, a user named "Babs Jensen" may have a different home 218 directory on different machines. This could be represented as: 220 homeDirectory: /home/babsj 221 homeDirectory;hostos-sunos: /export/home/bjensen 222 homeDirectory;host-babshost: /home/root 224 These attribute options follow sub-typing semantics. If a DUA 225 requests an attribute to be returned in a search operation, and does 226 not specify an option, all subtypes of that attribute are returned. 228 2.2.3. Object Classes 230 The following object classes are defined in this document: 232 posixAccount 233 shadowAccount 234 posixGroup 235 ipService 236 ipProtocol 237 oncRpc 238 ipHost 239 ipNetwork 240 nisNetgroup 241 nisMap 242 nisObject 243 ieee802Device 244 bootableDevice 245 nisKeyObject 246 nisDomainObject 247 automountMap 248 automount 250 Additionally, some of the attributes defined in [RFC4519] are 251 required. 253 3. Attribute Definitions 255 This section contains attribute definitions to be implemented by DUAs 256 supporting this schema: 258 ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' 259 DESC 'An integer uniquely identifying a user in an 260 administrative domain' 261 EQUALITY integerMatch 262 ORDERING integerOrderingMatch 263 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 264 SINGLE-VALUE ) 266 ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' 267 DESC 'An integer uniquely identifying a group in an 268 administrative domain' 269 EQUALITY integerMatch 270 ORDERING integerOrderingMatch 271 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 272 SINGLE-VALUE ) 274 ( 1.3.6.1.1.1.1.2 NAME 'gecos' 275 DESC 'The GECOS field; the common name' 276 EQUALITY caseIgnoreMatch 277 SUBSTRINGS caseIgnoreSubstringsMatch 278 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 279 SINGLE-VALUE ) 281 ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' 282 DESC 'The absolute path to the home directory' 283 EQUALITY caseExactIA5Match 284 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 285 SINGLE-VALUE ) 287 ( 1.3.6.1.1.1.1.4 NAME 'loginShell' 288 DESC 'The path to the login shell' 289 EQUALITY caseExactIA5Match 290 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 291 SINGLE-VALUE ) 293 ( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange' 294 EQUALITY integerMatch 295 ORDERING integerOrderingMatch 296 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 297 SINGLE-VALUE ) 299 ( 1.3.6.1.1.1.1.6 NAME 'shadowMin' 300 EQUALITY integerMatch 301 ORDERING integerOrderingMatch 302 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 303 SINGLE-VALUE ) 305 ( 1.3.6.1.1.1.1.7 NAME 'shadowMax' 306 EQUALITY integerMatch 307 ORDERING integerOrderingMatch 308 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 309 SINGLE-VALUE ) 311 ( 1.3.6.1.1.1.1.8 NAME 'shadowWarning' 312 EQUALITY integerMatch 313 ORDERING integerOrderingMatch 314 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 315 SINGLE-VALUE ) 317 ( 1.3.6.1.1.1.1.9 NAME 'shadowInactive' 318 EQUALITY integerMatch 319 ORDERING integerOrderingMatch 320 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 321 SINGLE-VALUE ) 323 ( 1.3.6.1.1.1.1.10 NAME 'shadowExpire' 324 EQUALITY integerMatch 325 ORDERING integerOrderingMatch 326 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 327 SINGLE-VALUE ) 329 ( 1.3.6.1.1.1.1.11 NAME 'shadowFlag' 330 EQUALITY integerMatch 331 ORDERING integerOrderingMatch 332 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 333 SINGLE-VALUE ) 335 ( 1.3.6.1.1.1.1.12 NAME 'memberUid' 336 EQUALITY caseExactMatch 337 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 339 ( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup' 340 EQUALITY caseExactMatch 341 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 343 ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' 344 DESC 'Netgroup triple' 345 EQUALITY caseIgnoreMatch 346 SUBSTRINGS caseIgnoreSubstringsMatch 347 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 349 ( 1.3.6.1.1.1.1.15 NAME 'ipServicePort' 350 DESC 'Service port number' 351 EQUALITY integerMatch 352 ORDERING integerOrderingMatch 353 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 354 SINGLE-VALUE ) 356 ( 1.3.6.1.1.1.1.16 NAME 'ipServiceProtocol' 357 DESC 'Service protocol name' 358 EQUALITY caseIgnoreMatch 359 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 361 ( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber' 362 DESC 'IP protocol number' 363 EQUALITY integerMatch 364 ORDERING integerOrderingMatch 365 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 366 SINGLE-VALUE ) 368 ( 1.3.6.1.1.1.1.18 NAME 'oncRpcNumber' 369 DESC 'ONC RPC number' 370 EQUALITY integerMatch 371 ORDERING integerOrderingMatch 372 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 373 SINGLE-VALUE ) 375 ( 1.3.6.1.1.1.1.19 NAME 'ipHostNumber' 376 DESC 'IPv4 addresses as a dotted decimal omitting leading 377 zeros or IPv6 addresses as defined in RFC2373' 378 EQUALITY caseIgnoreIA5Match 379 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 381 ( 1.3.6.1.1.1.1.20 NAME 'ipNetworkNumber' 382 DESC 'IP network omitting leading zeros, eg. 192.168' 383 EQUALITY caseIgnoreIA5Match 384 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 385 SINGLE-VALUE ) 387 ( 1.3.6.1.1.1.1.21 NAME 'ipNetmaskNumber' 388 DESC 'IP netmask omitting leading zeros, eg. 255.255.255.0' 389 EQUALITY caseIgnoreIA5Match 390 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 391 SINGLE-VALUE ) 393 ( 1.3.6.1.1.1.1.22 NAME 'macAddress' 394 DESC 'MAC address in maximal, colon separated hex 395 notation, eg. 00:00:92:90:ee:e2' 396 EQUALITY caseIgnoreIA5Match 397 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 399 ( 1.3.6.1.1.1.1.23 NAME 'bootParameter' 400 DESC 'rpc.bootparamd parameter' 401 EQUALITY caseExactIA5Match 402 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 404 ( 1.3.6.1.1.1.1.24 NAME 'bootFile' 405 DESC 'Boot image name' 406 EQUALITY caseExactIA5Match 407 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 409 ( 1.3.6.1.1.1.1.26 NAME 'nisMapName' 410 DESC 'Name of a generic NIS map' 411 EQUALITY caseIgnoreMatch 412 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} ) 414 ( 1.3.6.1.1.1.1.27 NAME 'nisMapEntry' 415 DESC 'A generic NIS entry' 416 EQUALITY caseExactMatch 417 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 418 SINGLE-VALUE ) 420 ( 1.3.6.1.1.1.1.28 NAME 'nisPublicKey' 421 DESC 'NIS public key' 422 EQUALITY octetStringMatch 423 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 424 SINGLE-VALUE ) 426 ( 1.3.6.1.1.1.1.29 NAME 'nisSecretKey' 427 DESC 'NIS secret key' 428 EQUALITY octetStringMatch 429 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 430 SINGLE-VALUE ) 432 ( 1.3.6.1.1.1.1.30 NAME 'nisDomain' 433 DESC 'NIS domain' 434 EQUALITY caseIgnoreIA5Match 435 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) 437 ( 1.3.6.1.1.1.1.31 NAME 'automountMapName' 438 DESC 'automount Map Name' 439 EQUALITY caseExactMatch 440 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 441 SINGLE-VALUE ) 443 ( 1.3.6.1.1.1.1.32 NAME 'automountKey' 444 DESC 'Automount Key value' 445 EQUALITY caseExactMatch 446 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 447 SINGLE-VALUE ) 449 ( 1.3.6.1.1.1.1.33 NAME 'automountInformation' 450 DESC 'Automount information' 451 EQUALITY caseExactMatch 452 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 453 SINGLE-VALUE ) 455 4. Class Definitions 457 This section contains class definitions to be implemented by DUAs 458 supporting the schema. 460 Various schema for mail routing and delivery using LDAP directories 461 have been proposed, and as such this document does not consider 462 schema for representing mail aliases or distribution lists. 464 ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY 465 DESC 'Abstraction of an account with POSIX attributes' 466 MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) 467 MAY ( authPassword $ userPassword $ loginShell $ gecos $ 468 description ) ) 470 ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' SUP top AUXILIARY 471 DESC 'Additional attributes for shadow passwords' 472 MUST uid 473 MAY ( authPassword $ userPassword $ description $ 474 shadowLastChange $ shadowMin $ shadowMax $ 475 shadowWarning $ shadowInactive $ 476 shadowExpire $ shadowFlag ) ) 478 ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top AUXILIARY 479 DESC 'Abstraction of a group of accounts' 480 MUST gidNumber 481 MAY ( authPassword $ userPassword $ memberUid $ 482 description ) ) 484 ( 1.3.6.1.1.1.2.3 NAME 'ipService' SUP top STRUCTURAL 485 DESC 'Abstraction an Internet Protocol service. 486 Maps an IP port and protocol (such as tcp or udp) 487 to one or more names; the distinguished value of 488 the cn attribute denotes the service's canonical 489 name' 490 MUST ( cn $ ipServicePort $ ipServiceProtocol ) 491 MAY description ) 493 ( 1.3.6.1.1.1.2.4 NAME 'ipProtocol' SUP top STRUCTURAL 494 DESC 'Abstraction of an IP protocol. Maps a protocol number 495 to one or more names. The distinguished value of the cn 496 attribute denotes the protocol canonical name' 497 MUST ( cn $ ipProtocolNumber ) 498 MAY description ) 500 ( 1.3.6.1.1.1.2.5 NAME 'oncRpc' SUP top STRUCTURAL 501 DESC 'Abstraction of an Open Network Computing (ONC) 502 [RFC1057] Remote Procedure Call (RPC) binding. 503 This class maps an ONC RPC number to a name. 504 The distinguished value of the cn attribute denotes 505 the RPC service canonical name' 506 MUST ( cn $ oncRpcNumber ) 507 MAY description ) 509 ( 1.3.6.1.1.1.2.6 NAME 'ipHost' SUP top AUXILIARY 510 DESC 'Abstraction of a host, an IP device. The distinguished 511 value of the cn attribute denotes the host's canonical 512 name. Device SHOULD be used as a structural class' 513 MUST ( cn $ ipHostNumber ) 514 MAY ( authPassword $ userPassword $ l $ description $ 515 manager ) ) 517 ( 1.3.6.1.1.1.2.7 NAME 'ipNetwork' SUP top STRUCTURAL 518 DESC 'Abstraction of a network. The distinguished value of 519 the cn attribute denotes the network canonical name' 520 MUST ipNetworkNumber 521 MAY ( cn $ ipNetmaskNumber $ l $ description $ manager ) ) 523 ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL 524 DESC 'Abstraction of a netgroup. May refer to other 525 netgroups' 526 MUST cn 527 MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) 529 ( 1.3.6.1.1.1.2.9 NAME 'nisMap' SUP top STRUCTURAL 530 DESC 'A generic abstraction of a NIS map' 531 MUST nisMapName 532 MAY description ) 534 ( 1.3.6.1.1.1.2.10 NAME 'nisObject' SUP top STRUCTURAL 535 DESC 'An entry in a NIS map' 536 MUST ( cn $ nisMapEntry $ nisMapName ) 538 ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' SUP top AUXILIARY 539 DESC 'A device with a MAC address; device SHOULD be 540 used as a structural class' 541 MAY macAddress ) 543 ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice' SUP top AUXILIARY 544 DESC 'A device with boot parameters; device SHOULD be 545 used as a structural class' 546 MAY ( bootFile $ bootParameter ) ) 548 ( 1.3.6.1.1.1.2.14 NAME 'nisKeyObject' SUP top AUXILIARY 549 DESC 'An object with a public and secret key' 550 MUST ( cn $ nisPublicKey $ nisSecretKey ) 551 MAY ( uidNumber $ description ) ) 553 ( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top AUXILIARY 554 DESC 'Associates a NIS domain with a naming context' 555 MUST nisDomain ) 557 ( 1.3.6.1.1.1.2.16 NAME 'automountMap' SUP top STRUCTURAL 558 MUST ( automountMapName ) 559 MAY description ) 561 ( 1.3.6.1.1.1.2.17 NAME 'automount' SUP top STRUCTURAL 562 DESC 'Automount information' 563 MUST ( automountKey $ automountInformation ) 564 MAY description ) 566 ( 1.3.6.1.1.1.2.18 NAME 'groupOfMembers' SUP top STRUCTURAL 567 DESC 'A group with members (DNs)' 568 MUST cn 569 MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ 570 description $ member ) ) 572 5. Implementation Details 574 5.1. Suggested Resolution Methods 576 The preferred means of directing a client application (one using the 577 shared services of the C library) to use LDAP as its information 578 source for the functions listed in Appendix B is to modify the source 579 code to directly query LDAP. As the source to commercial C libraries 580 and applications is rarely available to the end-user, one could 581 emulate a supported nameservice (such as NIS). (This is also an 582 appropriate opportunity to perform caching of entries across process 583 address spaces.) In the case of NIS, reference implementations are 584 widely available and the RPC interface is well known. 586 The means by which the operating system is directed to use LDAP is 587 implementation dependent. For example, some operating systems and C 588 libraries support end-user extensible resolvers using dynamically 589 loadable libraries and a nameservice "switch" (NSS). The means in 590 which the DUA locates LDAP servers is also implementation dependent. 592 5.2. Interpreting User and Group Entries 594 User and group resolution is initiated by the functions prefixed by 595 getpw and getgr respectively. The uid attribute contains the user's 596 login name. The cn attribute, in posixGroup entries, contains the 597 group's name. This document preserves the use of the uid attribute 598 even though, being a naming attribute, its syntax is case 599 insensitive. This may cause a problem with existing deployments 600 where there exist login names differing only in case. If DUAs 601 support attribute mapping, a different attribute MAY be used to 602 represent users' login names. 604 The account object class provides a convenient structural class for 605 posixAccount, and SHOULD be used where additional attributes are not 606 required. Likewise, the groupOfMembers object class SHOULD be used 607 for groups. (The groupOfUniqueNames object class is deprecated and 608 SHOULD NOT be used.) 610 It is suggested that uid and cn are used as the naming attribute for 611 posixAccount and posixGroup entries, respectively. Group members may 612 either be login names (values of memberUid) or distinguished names 613 (values of member). In the latter case, the distinguished name must 614 be mapped to one or more login names by examining the name's RDN or, 615 if it is not distinguished by uid, performing a base search on the DN 616 with a filter of "(objectclass=*)". DUAs MAY wish to cache DN to 617 login name mappings. The DUA MAY traverse nested groups. 619 An account's GECOS field is preferably determined by a value of the 620 gecos attribute. If no gecos attribute exists, the value of the cn 621 attribute MUST be used. (The existence of the gecos attribute allows 622 information embedded in the GECOS field, such as a user's telephone 623 number, to be returned to the client without overloading the cn 624 attribute. It also accommodates directories where the common name 625 does not contain the user's full name.) 627 5.2.1. Using Attribute Options 629 Some posixAccount attributes may be accompanied by options 630 (Section 2.2.2) identifying particular hosts or operating system 631 types. The attribute with a hostos option matching the operating 632 system of the DUA SHOULD be used in preference to an attribute 633 without any associated options. The attribute with a host option 634 matching the hostname of the DUA SHOULD be used in preference to any 635 other attribute. 637 5.2.2. Authentication Considerations 639 5.2.2.1. Using Password Values 641 When authenticating using a NIS to LDAP gateway or using NSS, a 642 lookup is performed to retrieve the password attribute and the value 643 is used in the DUA to authenticate a user. This approach to 644 authentication is deprecated, as it requires that read access to the 645 password attribute be granted across a network. 647 An entry of class posixAccount, posixGroup, or shadowAccount without 648 an authPassword or userPassword attribute MUST NOT be used for 649 authentication. In this case the client SHOULD be returned a non- 650 matchable password such as "x". 652 If userPassword is used, its values MUST be represented by the 653 following syntax: 655 passwordvalue = schemeprefix hashedpasswd 656 schemeprefix = "{" scheme "}" 657 scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme 658 altscheme = "x-" keystring 659 hashedpasswd = hashed password 661 The hashed password contains a plaintext key hashed using the 662 algorithm scheme. If the schema is "sha", the hashed password is the 663 base64 encoding of the SHA-1 digest of the plaintext password. 665 userPassword values which do not adhere to this syntax MUST NOT be 666 used for authentication. The DUA MUST iterate through the values of 667 the attribute until a value matching the above syntax is found. Only 668 if hashedpassword is an empty string does the user have no password. 669 DUAs are not required to consider hashing schemes which the client 670 will not recognize; in most cases, it may be sufficient to consider 671 only "crypt". 673 DUA MAY use the authPassword attribute instead of userPassword, 674 defined in [RFC3112]. The DUA MUST iterate the values of the 675 authPassword attribute until a value whose scheme is CRYPT is found. 676 The DUA MAY iterate through the values of the userPassword attribute, 677 using the syntax defined here, until a value whose scheme is CRYPT is 678 found. If no conforming value is found, the client MUST be returned 679 a non-matchable password such as "x". Authentication using schemes 680 other than CRYPT is, although advisable, beyond the scope of this 681 document 683 Below is an example of an authPassword attribute: 685 authPassword: CRYPT$X5/DBrWPOQQaI 687 Below is an example of a (deprecated) userPassword attribute: 689 userPassword: {CRYPT}X5/DBrWPOQQaI 691 A DUA MAY utilize the attributes in the shadowAccount class to 692 provide shadow password service (getspnam() and getspent()). In such 693 cases, the DUA MUST NOT make use of the userPassword attribute for 694 getpwnam() et al, and MUST return a non-matchable password (such as 695 "x") to the client instead. 697 5.2.2.2. Using LDAP Bind 699 The preferred method for authenticating users with LDAP is to perform 700 an LDAP Bind operation with the user's name and password. In this 701 case the method the DSA uses to store and verify the password is 702 completely internal to the DSA and not of any concern to the DUA. 704 Likewise, using the shadowAccount attributes requires the DUA to 705 handle password policy enforcement. However the policies expressed 706 in the shadowAccount are limited in scope, and not uniformly 707 applicable to all the systems that will be using LDAP. 709 The preferred method is to leave password policy enforcement to the 710 DSA, so that it will be uniformly enforced across all of the various 711 systems that rely on the directory. This enforcement occurs 712 implicitly when authenticating using LDAP Bind if the DSA supports 713 the LDAP password policy [I-D.behera-ldap-password-policy] 714 mechanisms. 716 The means in which authentication in the DUA is configured is 717 implementation dependent. Typically it is accomplished using [PAM]. 718 Further details of authentication are beyond the scope of this 719 document. 721 5.2.3. Naming Considerations 723 On UNIX systems, users and groups reside in separate name spaces and 724 it is common for the same name to be used by both a user and a group. 725 Since they are in separate name spaces there is no ambiguity and no 726 conflict. However, when integrating a name service into LDAP the 727 directory may be used with other systems besides UNIX and its 728 derivatives. In particular, the Microsoft Windows operating system 729 may also use LDAP for its own name service. In Windows, users and 730 groups reside in a single name space and so one cannot use the same 731 name for both a user and a group. 733 Conflicts in naming conventions may arise in other deployments as 734 well, and should be carefully taken into account when migrating from 735 other naming services into LDAP. 737 5.3. Interpreting Hosts and Networks 739 The ipHostNumber and ipNetworkNumber attributes are defined in 740 preference to dNSRecord (defined in [RFC1279]), in order to simplify 741 the DUA's role in interpreting entries in the directory. A dNSRecord 742 expresses a complete resource record, including time to live and 743 class data, which is extraneous to this schema. 745 Additionally, the ipHost and ipNetwork classes permit a host or 746 network (respectively) and all its aliases to be represented by a 747 single entry in the directory. This is not necessarily possible if a 748 DNS resource record is mapped directly to an LDAP entry. 749 Implementations that wish to use LDAP to master DNS zone information 750 are not precluded from doing so, and may simply avoid the ipHost and 751 ipNetwork classes. 753 This document redefines, although not exclusively, the ipNetwork 754 class defined in [RFC1279], in order to achieve consistent naming 755 with ipHost. The ipNetworkNumber attribute is also used in the 756 siteContact object class [ROSE]. 758 The authPassword and userPassword attributes are included in ipHost 759 such that hosts MAY be treated as authentication principals. The 760 treatment of these attributes and inherent caveats considered in 761 Section 5.2 apply here also. 763 The trailing zeros in a network address MUST be omitted. CIDR-style 764 network addresses (eg. 192.168.1/24) MAY be used. Leading zeros MUST 765 be removed from all components of an IPv6 address string as defined 766 by [RFC2373], section 2.2, item 1. The IPv6 address string MUST be 767 further normalized by following the "::" syntax as defined in 768 [RFC2373], section 2.2, item 2. In addition, "::" MUST be used to 769 replace the longest string of zero bits. If there are two or more 770 longest strings of zero bits, then the first string MUST be replaced. 771 In addition, the syntax defined by [RFC2373], section 2.2, item 3 772 MUST NOT be used. IPv4 addresses MUST be represented by the IPv4 773 dotted decimal string syntax. 775 For example the following address: 777 1080:0000:0:0:08:800:200C:417A 778 FF01:0:0:0:0:0:01 779 0:0:0:0:0:0:0:0001 780 0:0:0:0:0:0:0:0 782 MUST be normalized as: 784 1080::8:800:200C:417A 785 FF01::101 786 0::1 787 :: 789 5.4. Interpreting Other Entities 791 In general, a one-to-one mapping between entities and LDAP entries is 792 proposed, in that each entity has exactly one representation in the 793 DIT. In some cases this is not feasible; for example, a service 794 which is represented in more than one protocol domain. Consider the 795 following entry: 797 dn: cn=domain,ou=services,dc=aja,dc=com 798 objectClass: top 799 objectClass: ipService 800 cn: domain 801 cn: nameserver 802 ipServicePort: 53 803 ipServiceProtocol: tcp 804 ipServiceProtocol: udp 806 This entry MUST map to the following two (2) services entities: 808 domain 53/tcp nameserver 809 domain 53/udp nameserver 811 While the above two entities may be represented as separate LDAP 812 entities, with different distinguished names (such as cn=domain+ 813 ipServiceProtocol=tcp, ... and cn=domain+ipServiceProtocol=udp, ...) 814 it is convenient to represent them as a single entry. If a service 815 is represented in multiple protocol domains with different ports, 816 then multiple entries are required; multi-valued RDNs MAY be used to 817 distinguish them.) 819 With the exception of authPassword and userPassword values, empty 820 values (consisting of a zero length string) are returned by the DUA 821 to the client. The DUA MUST reject any entries which do not conform 822 to the schema (missing mandatory attributes). Non-conforming entries 823 SHOULD be ignored while enumerating entries. 825 The nisDomainObject object class is provided to associate a NIS 826 domain with a naming context. A DUA would retrieve the NIS domain 827 name from a configuration file and enumerate the naming contexts 828 served by an LDAP server, searching each naming context for 829 (nisDomain=%s). The first matching entry that is found MAY be used 830 as a search base for configuration profile information or for entries 831 themselves. For example, the following example shows an association 832 between the NIS domain "nis.aja.com" and the naming context 833 "dc=aja,dc=com": 835 dn: dc=aja,dc=com 836 objectClass: top 837 objectClass: domain 838 objectClass: nisDomainObject 839 dc: aja 840 nisDomain: nis.aja.com 842 The nisObject object class MAY be used as a generic means of 843 representing NIS entities. Its use is not encouraged; where support 844 for entities not described in this schema is desired, an appropriate 845 schema should be devised. Implementers are strongly advised to 846 support end-user extensible mappings between NIS entities and object 847 classes. (Where the nisObject class is used, the nisMapName 848 attribute MAY be used as a RDN.) The nisObject class might be used 849 to represent automount information. 851 5.5. Canonicalizing entries with multi-valued naming attributes 853 For entities such as hosts, services, networks, protocols, and RPCs, 854 where there may be one or more aliases, the respective entry's 855 relative distinguished name SHOULD be used to determine the canonical 856 name. Any other values for the same attribute are used as aliases. 857 For example, the service described in Section 5.4 has the canonical 858 name "domain" and exactly one alias, "nameserver". 860 The schema in this document generally only defines one attribute per 861 class which is suitable for distinguishing an entity (excluding any 862 attributes with integer syntax; it is assumed that entries will be 863 distinguished on name). Usually, this is the common name (cn) 864 attribute. This aids the DUA in determining the canonical name of an 865 entity, as it can examine the value of the relative distinguished 866 name. Aliases are thus any values of the distinguishing attribute 867 (such as cn) which do not match the canonical name of the entity. 869 In the event that a different attribute is used to distinguish the 870 entry, as may be the case where these object classes are used as 871 auxiliary classes, the entry's canonical name may not be present in 872 the RDN. In this case, the DUA MUST choose one of the non- 873 distinguished values to represent the entity's canonical name. As 874 the directory server guarantees no ordering of attribute values, it 875 may not be possible to distinguish an entry deterministically. This 876 ambiguity SHOULD NOT be resolved by mapping one directory entry into 877 multiple entities. 879 6. Implementation Focus 881 Gateways between NIS and LDAP have been developed by PADL Software 882 and Sun Microsystems. They both support this schema. 884 An open source implementation of the C library resolution code has 885 been written and is available from PADL Software. It supports C 886 libraries on GNU, BSD, AIX, and Solaris operating systems. PADL have 887 also made available a set of scripts for migrating flat files into a 888 form suitable for loading into an LDAP server. Another open source 889 implementation of the C library code is available from the OpenLDAP 890 Project. 892 7. Security Considerations 894 The entirety of related security considerations are outside the scope 895 of this document. It is noted that making passwords encrypted with a 896 widely understood hash function (such as crypt()) available to non- 897 privileged users is dangerous because it exposes them to dictionary 898 and brute-force attacks. This is proposed only for compatibility 899 with existing UNIX system implementations. Sites where security is 900 critical SHOULD consider using a strong authentication service for 901 user authentication. 903 Alternatively, the encrypted password could be made available only to 904 a subset of privileged DUAs, which would provide "shadow" password 905 service to client applications. This may be difficult to enforce. 907 Because the schema represents operating system-level entities, access 908 to these entities SHOULD be granted on a discretionary basis. (There 909 is little point in restricting access to data which will be 910 republished without restriction, however.) It is particularly 911 important that only administrators can modify entries defined in this 912 schema, with the exception of allowing a principal to change their 913 password (which MAY be done on behalf of the user by a client bound 914 as a superior principal, such that password restrictions MAY be 915 enforced). For example, if a user were allowed to change the value 916 of their uidNumber attribute, they could subvert security by 917 equivalencing their account with the superuser account. 919 A subtree of the DIT which is to be republished by a DUA (such as a 920 NIS gateway) SHOULD be within the same administrative domain that the 921 republishing DUA represents. (For example, principals outside an 922 organization, while conceivably part of the DIT, should not be 923 considered with the same degree of authority as those within the 924 organization.) 926 Finally, care should be exercised with integer attributes of a 927 sensitive nature (particularly the uidNumber and gidNumber 928 attributes) which contain zero-length values. DUAs MAY treat such 929 values as corresponding to the "nobody" or "nogroup" user and group, 930 respectively. 932 8. Acknowledgements 934 Thanks to Bob Joslin of the Hewlett Packard Company, and to all those 935 that helped with this document's predecessor, RFC 2307. 937 UNIX is a registered trademark of The Open Group. 939 9. References 941 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 942 STD 13, RFC 1034, November 1987. 944 [RFC1057] Sun Microsystems, Inc., "RPC: Remote Procedure Call 945 Protocol specification: Version 2", RFC 1057, June 1988. 947 [RFC1279] Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, 948 November 1991. 950 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 951 Architecture", RFC 2373, July 1998. 953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 954 Requirement Levels", BCP 14, RFC 2119, March 1997. 956 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 957 (LDAP): The Protocol", RFC 4511, June 2006. 959 [RFC4515] Smith, M. and T. Howes, "Lightweight Directory Access 960 Protocol (LDAP): String Representation of Search Filters", 961 RFC 4515, June 2006. 963 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 964 (LDAP): Schema for User Applications", RFC 4519, 965 June 2006. 967 [RFC3112] Zeilenga, K., "LDAP Authentication Password Schema", 968 RFC 3112, May 2001. 970 [I-D.behera-ldap-password-policy] 971 Sermersheim, J., Poitou, L., and H. Chu, "Password Policy 972 for LDAP Directories", 973 draft-behera-ldap-password-policy-10 (work in progress), 974 August 2009. 976 [ROSE] Rose, M., "The Little Black Book: Mail Bonding with OSI 977 Directory Services", ISBN 0-13-683210-5, 2001. 979 [X.500] ISO/IEC JTC 1/SC21, "Information Processing Systems - Open 980 Systems Interconnection - The Directory: Overview of 981 Concepts, Models and Service", 1988. 983 [UNIX] Institute of Electrical and Electronics Engineers and The 984 Open Group, "IEEE Std 1003.1, 2004 Edition, Single UNIX 985 Specification Version 3", IEEE Standard 1003.1, 2004. 987 [PAM] Samar, V. and R. Schemers, "Unified Login with Pluggable 988 Authentication Modules (PAM)", OSF RFC 86.0, October 1995. 990 Appendix A. Example Entries 992 The examples described in this section are provided to illustrate the 993 schema described in this draft. They are not meant to be exhaustive. 995 The following entry is an example of the posixAccount class: 997 dn: uid=lester,ou=people,dc=aja,dc=com 998 objectClass: top 999 objectClass: account 1000 objectClass: posixAccount 1001 uid: lester 1002 cn: Lester the Nightfly 1003 gecos: Lester 1004 uidNumber: 10 1005 gidNumber: 10 1006 loginShell: /bin/csh 1007 userPassword: {crypt}$X5/DBrWPOQQaI 1008 homeDirectory: /home/lester 1010 This corresponds to the UNIX system password file entry: 1012 lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh 1014 The following entry is an example of the ipHost class: 1016 dn: cn=josie.aja.com,ou=hosts,dc=aja,dc=com 1017 objectClass: top 1018 objectClass: device 1019 objectClass: ipHost 1020 objectClass: bootableDevice 1021 objectClass: ieee802Device 1022 cn: josie.aja.com 1023 cn: www.aja.com 1024 ipHostNumber: 10.0.0.1 1025 macAddress: 00:00:92:90:ee:e2 1026 bootFile: mach 1027 bootParameter: root=dan.aja.com:/nfsroot/peg 1028 bootParameter: swap=dan.aja.com:/nfsswap/peg 1029 bootParameter: dump=dan.aja.com:/nfsdump/peg 1031 This entry represents the host canonically josie.aja.com, also known 1032 as www.aja.com. The Ethernet address and four boot parameters are 1033 also specified. 1035 An example of the nisNetgroup class: 1037 dn: cn=nightfly,ou=netgroup,dc=aja,dc=com 1038 objectClass: top 1039 objectClass: nisNetgroup 1040 cn: nightfly 1041 nisNetgroupTriple: (charlemagne,peg,dunes.aja.com) 1042 nisNetgroupTriple: (lester,-,) 1043 memberNisNetgroup: kamakiriad 1045 This entry represents the netgroup nightfly, which contains two 1046 triples (the user charlemagne, the host peg, and the domain 1047 dunes.aja.com; and, the user lester, no host, and any domain) and one 1048 netgroup (kamakiriad). 1050 Finally, an example of the nisObject class: 1052 dn: nisMapName=tracks,dc=dunes,dc=aja,dc=com 1053 objectClass: top 1054 objectClass: nisMap 1055 nisMapName: tracks 1057 dn: cn=Maxine,nisMapName=tracks,dc=dunes,dc=aja,dc=com 1058 objectClass: top 1059 objectClass: nisObject 1060 cn: Maxine 1061 nisMapName: tracks 1062 nisMapEntry: Nightfly$4 1064 This represents the NIS map tracks, and a single map entry. 1066 Appendix B. Affected Library Functions 1068 The following functions are typically found in the C libraries of 1069 most UNIX and POSIX compliant systems [UNIX]. An LDAP search filter 1070 string [RFC4515] which may be used to satisfy the function call is 1071 included alongside each function name. Parameters are denoted by %s 1072 and %d for string and integer arguments, respectively. Long lines 1073 are broken: 1075 getpwnam() (&(objectClass=posixAccount)(uid=%s)) 1076 getpwuid() (&(objectClass=posixAccount)(uidNumber=%d)) 1077 getpwent() (objectClass=posixAccount) 1078 getspnam() (&(objectClass=shadowAccount)(uid=%s)) 1079 getspent() (objectClass=shadowAccount) 1081 getgrnam() (&(objectClass=posixGroup)(cn=%s)) 1082 getgrgid() (&(objectClass=posixGroup)(gidNumber=%d)) 1083 getgrent() (objectClass=posixGroup) 1085 getservbyname() (&(objectClass=ipService)(cn=%s) 1086 (ipServiceProtocol=%s)) 1087 getservbyport() (&(objectClass=ipService)(ipServicePort=%d) 1088 (ipServiceProtocol=%s)) 1089 getservent() (objectClass=ipService) 1091 getrpcbyname() (&(objectClass=oncRpc)(cn=%s)) 1092 getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d)) 1093 getrpcent() (objectClass=oncRpc) 1095 getprotobyname() (&(objectClass=ipProtocol)(cn=%s)) 1096 getprotobynumber() (&(objectClass=ipProtocol) 1097 (ipProtocolNumber=%d)) 1098 getprotoent() (objectClass=ipProtocol) 1100 gethostbyname() (&(objectClass=ipHost)(cn=%s)) 1101 gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s)) 1102 gethostent() (objectClass=ipHost) 1104 getnetbyname() (&(objectClass=ipNetwork)(cn=%s)) 1105 getnetbyaddr() (&(objectClass=ipNetwork)(ipNetworkNumber=%s)) 1106 getnetent() (objectClass=ipNetwork) 1108 setnetgrent() (&(objectClass=nisNetgroup)(cn=%s)) 1109 getpublickey() (&(objectClass=nisKeyObject)(...)) 1111 Appendix C. Suggested DIT structure 1113 The cn attribute is typically used to name entities. The 1114 ipHostNumber, ipNetworkNumber, and ipServiceProtocol attributes are 1115 also naming attributes, such that multi-valued RDNs may be used to 1116 distinguish between, for example, different interfaces of a 1117 multihomed host. 1119 The following DIT structure MAY be used for deploying this schema. 1120 It is not required that DC-naming be used, but it is encouraged: 1122 Naming context ObjectClass 1123 ============================================================ 1124 ou=people,dc=... posixAccount 1125 shadowAcount 1126 ou=group,dc=... posixGroup 1127 ou=services,dc=... ipService 1128 ou=protocols,dc=... ipProtocol 1129 ou=rpc,dc=... oncRpc 1130 ou=hosts,dc=... ipHost 1131 ou=ethers,dc=... ieee802Device 1132 bootableDevice 1133 ou=networks,dc=... ipNetwork 1134 ou=netgroup,dc=... nisNetgroup 1135 nisMapName=...,dc=... nisObject 1136 automountMapName=...,dc=... automountMap 1138 Authors' Addresses 1140 Luke Howard 1141 PADL Software Pty. Ltd. 1142 PO Box 59 1143 Central Park, Vic 3145 1144 AU 1146 Email: lukeh@padl.com 1148 Howard Chu (editor) 1149 Symas Corp. 1150 18740 Oxnard Street, Suite 313A 1151 Tarzana, California 91356 1152 US 1154 Phone: +1 818 757-7087 1155 Email: hyc@symas.com