git.sur5r.net Git - openldap/blob - doc/drafts/draft-howard-rfc2307bis-xx.xml

   1 <?xml version="1.0"?>
   2 <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
   3         <!ENTITY rfc1034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
   4         <!ENTITY rfc1057 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1057.xml'>
   5         <!ENTITY rfc1279 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1279.xml'>
   6         <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
   7         <!ENTITY rfc2195 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2195.xml'>
   8         <!ENTITY rfc2373 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2373.xml'>
   9         <!ENTITY rfc4422 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml'>
  10         <!ENTITY rfc4511 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4511.xml'>
  11         <!ENTITY rfc4513 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4513.xml'>
  12         <!ENTITY rfc4515 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4515.xml'>
  13         <!ENTITY rfc4517 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4517.xml'>
  14         <!ENTITY rfc4519 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4519.xml'>
  15         <!ENTITY rfc2831 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2831.xml'>
  16         <!ENTITY rfc3062 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3062.xml'>
  17         <!ENTITY rfc3112 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3112.xml'>
  18         <!ENTITY rfc3383 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3383.xml'>
  19         <!ENTITY rfc3672 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3672.xml'>
  20         <!ENTITY ppolicy PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.behera-ldap-password-policy.xml'>
  21 ]>
  22 <?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
  23 <?rfc symrefs="yes" ?>
  24 <rfc
  25   obsoletes="2307"
  26   ipr="trust200902"
  27   category="info"
  28   docName="draft-howard-rfc2307bis-02">
  29   <front>
  30     <title abbrev="LDAP NameService Schema">
  31       An Approach for Using LDAP as a Network Information Service
  32     </title>
  33     <author initials="L." surname="Howard" fullname="Luke Howard">
  34       <organization abbrev="PADL Software">
  35         PADL Software Pty. Ltd.
  36       </organization>
  37       <address>
  38         <postal>
  39           <street>PO Box 59</street>
  40           <city>Central Park</city>
  41           <region>Vic</region>
  42           <code>3145</code>
  43           <country>AU</country>
  44         </postal>
  45         <email>lukeh@padl.com</email>
  46       </address>
  47     </author>
  48         <author initials="H." fullname="Howard Chu" surname="Chu" role="editor">
  49                 <organization>Symas Corp.</organization>
  50                 <address>
  51                         <postal>
  52                                 <street>18740 Oxnard Street, Suite 313A</street>
  53                                 <city>Tarzana</city>
  54                                 <region>California</region>
  55                                 <code>91356</code>
  56                                 <country>US</country>
  57                         </postal>
  58                         <phone>+1 818 757-7087</phone>
  59                         <email>hyc@symas.com</email>
  60                 </address>
  61         </author>
  62     <date month="August" year="2009"/>
  63     <abstract>
  64       <t>This document describes a mechanism for mapping
  65       entities related to <xref target="UNIX">TCP/IP and the UNIX
  66       system </xref> into <xref target="X.500"/> entries so
  67       that they may be resolved with the <xref target="RFC4511">
  68       Lightweight Directory Access Protocol</xref>. A set of attribute types
  69       and object classes are proposed, along with specific guidelines for
  70       interpreting them.  The intention is to assist the deployment of
  71       LDAP as an organizational nameservice. No proposed solutions are
  72       intended as standards for the Internet. Rather, it is hoped that a
  73       general consensus will emerge as to the appropriate solution to such
  74       problems, leading eventually to the adoption of standards. The
  75       proposed mechanism has already been implemented with some success.
  76 </t>
  77     </abstract>
  78   </front>
  79
  80   <middle>
  81     <section anchor="background" title="Background and Motivation">
  82       <t>The UNIX (R) operating system, and its derivatives (specifically,
  83       those which support TCP/IP and conform to the <xref target="UNIX">
  84       X/Open Single UNIX specification</xref>) require a means of looking up
  85       entities, by matching them against search criteria or by enumeration.
  86       (Other operating systems that support TCP/IP may provide some means of
  87       resolving some of these entities. This schema is applicable to those
  88       environments also.)</t>
  89       <t>These entities include users, groups, IP services (which map names
  90       to IP ports and protocols, and vice versa), IP protocols (which map
  91       names to IP protocol numbers and vice versa), RPCs (which map names
  92       to <xref target="RFC1057">ONC Remote Procedure Call</xref>
  93       numbers and vice versa), NIS netgroups, booting information (boot
  94       parameters and MAC address mappings), filesystem mounts, IP hosts
  95       and networks.</t>
  96       <t>Resolution requests are made through a set of C functions, provided
  97       in the UNIX system's C library. For example, the UNIX system utility
  98       "ls", which enumerates the contents of a filesystem directory,
  99       uses the C library function getpwuid() in order to map user IDs to
 100       login names. Once the request is made, it is resolved using a
 101       "nameservice" which is supported by the client library. The
 102       nameservice may be, at its simplest, a collection of files in the
 103       local filesystem which are opened and searched by the C library. Other
 104       common nameservices include the Network Information Service (NIS)
 105       and the <xref target="RFC1034">Domain Name System (DNS)</xref>. (The latter is typically used for
 106       resolving hosts, services and networks.) Both these nameservices
 107       have the advantage of being distributed and thus permitting a common
 108       set of entities to be shared amongst many clients.</t>
 109       <t>LDAP is a distributed, hierarchical directory service access
 110       protocol which is used to access repositories of users and other
 111       network-related entities. Because LDAP is often not tightly integrated
 112       with the host operating system, information such as users may need
 113       to be kept both in LDAP and in an operating system supported
 114       nameservice such as NIS. By using LDAP as the primary means of
 115       resolving these entities, these redundancy issues are minimized and
 116       the scalability of LDAP can be exploited. (By comparison, NIS services
 117       based on flat files do not have the scalability or extensibility of
 118       LDAP or X.500.)</t>
 119       <t>The object classes and attributes defined below are suitable for
 120       representing the aforementioned entities in a form compatible with
 121       LDAP and X.500 directory services.</t>
 122     </section>
 123     <section anchor="general" title="General Issues">
 124       <section anchor="genera.terms" title="Terminology">
 125         <t>The key words "MUST", "SHOULD", and "MAY" used in this document
 126         are to be interpreted as described in
 127         <xref target="RFC2119"/>.</t>
 128         <t>For the purposes of this document, the term "nameservice" refers
 129         to a service, such as NIS or flat files, that is used by the
 130         operating system to resolve entities within a single, local naming
 131         context. Contrast this with a "directory service" such as LDAP, which
 132         supports extensible schema and multiple naming contexts.</t>
 133         <t>The term "NIS-related entities" broadly refers to entities which
 134         are typically resolved using the Network Information Service. (NIS
 135         was previously known as YP.) Deploying LDAP for resolving these
 136         entities does not imply that NIS be used, as a gateway or otherwise.
 137         In particular, the host and network classes are generically
 138         applicable, and may be implemented on any system that wishes to use
 139         LDAP or X.500 for host and network resolution.</t>
 140         <t>The "DUA" (directory user agent) refers to the LDAP client
 141         querying these entities, such as an LDAP to NIS gateway or the C
 142         library. The "client" refers to the application which ultimately
 143         makes use of the information returned by the resolution. It
 144         is irrelevant whether the DUA and the client reside within the same
 145         address space. The act of the DUA making this information to the
 146         client is termed "republishing".</t>
 147         <t>To avoid confusion, the term "login name" refers to the user's
 148         login name (being the value of the uid attribute) and the term
 149         "user ID" refers to the user's integer identification number (being
 150         the value of the uidNumber attribute).</t>
 151         <t>The phrases "resolving an entity" and "resolution of entities"
 152         refer respectively to enumerating NIS-related entities of a given
 153         type, and matching them against a given search criterion. One or
 154         more entities are returned as a result of successful "resolutions"
 155         (a "match" operation will only return one entity).</t>
 156         <t>The use of the term UNIX does not confer upon this schema the
 157         endorsement of owners of the UNIX trademark. Where necessary, the
 158         term "TCP/IP entity" is used to refer to protocols, services,
 159         hosts, and networks, and the term "UNIX entity" to its complement.
 160         (The former category does not mandate the host operating system
 161         supporting the interfaces required for resolving UNIX entities.)</t>
 162         <t>The OIDs defined below are derived from iso(1) org(3) dod(6)
 163         internet(1) directory(1) nisSchema(1)</t>
 164       </section>
 165           <section title="Schema">
 166         <t>The attributes and classes defined in this document are summarized
 167         below.</t>
 168       <section anchor="general.attrs" title="Attributes">
 169         <t>The following attributes are defined in this document:
 170           <list style="empty">
 171             <t>
 172               uidNumber<vspace blankLines="0"/>
 173               gidNumber<vspace blankLines="0"/>
 174               gecos<vspace blankLines="0"/>
 175               homeDirectory<vspace blankLines="0"/>
 176               loginShell<vspace blankLines="0"/>
 177               shadowLastChange<vspace blankLines="0"/>
 178               shadowMin<vspace blankLines="0"/>
 179               shadowMax<vspace blankLines="0"/>
 180               shadowWarning<vspace blankLines="0"/>
 181               shadowInactive<vspace blankLines="0"/>
 182               shadowExpire<vspace blankLines="0"/>
 183               shadowFlag<vspace blankLines="0"/>
 184               memberUid<vspace blankLines="0"/>
 185               memberNisNetgroup<vspace blankLines="0"/>
 186               nisNetgroupTriple<vspace blankLines="0"/>
 187               ipServicePort<vspace blankLines="0"/>
 188               ipServiceProtocol<vspace blankLines="0"/>
 189               ipProtocolNumber<vspace blankLines="0"/>
 190               oncRpcNumber<vspace blankLines="0"/>
 191               ipHostNumber<vspace blankLines="0"/>
 192               ipNetworkNumber<vspace blankLines="0"/>
 193               ipNetmaskNumber<vspace blankLines="0"/>
 194               macAddress<vspace blankLines="0"/>
 195               bootParameter<vspace blankLines="0"/>
 196               bootFile<vspace blankLines="0"/>
 197               nisMapName<vspace blankLines="0"/>
 198               nisMapEntry<vspace blankLines="0"/>
 199               nisPublicKey<vspace blankLines="0"/>
 200               nisSecretKey<vspace blankLines="0"/>
 201               nisDomain<vspace blankLines="0"/>
 202               automountMapName<vspace blankLines="0"/>
 203               automountKey<vspace blankLines="0"/>
 204               automountInformation<vspace blankLines="0"/>
 205             </t>
 206           </list>
 207           Additionally, some of the attributes defined in
 208           <xref target="RFC4519"/> and
 209           <xref target="RFC3112"/> are required.
 210         </t>
 211       </section>
 212           <section anchor="attroptions" title="Attribute Option">
 213             <t>Centralizing a name service in LDAP allows heterogeneous
 214                 systems to obtain their information from a single place. However
 215                 in some cases, this information cannot be used uniformly on all
 216                 of the client systems. These attribute options are defined to allow
 217                 system-specific values to be used where necessary. The options
 218                 are defined as the following:
 219                 <list style="empty">
 220                 <t>host-&lt;hostname><vspace blankLines="0"/>
 221                 hostos-&lt;ostype></t>
 222                 </list>
 223                 where hostname is a string representing the name of a specific
 224                 machine, and ostype is a string representing a particular
 225                 operating system.</t>
 226                 <t>For example, a user named "Babs Jensen" may have a different
 227                 home directory on different machines. This could be represented as:
 228                 <list style="empty">
 229                 <t>
 230                 homeDirectory: /home/babsj<vspace blankLines="0"/>
 231                 homeDirectory;hostos-sunos: /export/home/bjensen<vspace blankLines="0"/>
 232                 homeDirectory;host-babshost: /home/root
 233                 </t>
 234                 </list></t>
 235                 <t>These attribute options follow sub-typing semantics. If a DUA
 236                 requests an attribute to be returned in a search operation, and
 237                 does not specify an option, all subtypes of that attribute are
 238                 returned.</t>
 239         </section>
 240       <section anchor="general.classes" title="Object Classes">
 241         <t>The following object classes are defined in this document:
 242           <list style="empty">
 243             <t>
 244               posixAccount<vspace blankLines="0"/>
 245               shadowAccount<vspace blankLines="0"/>
 246               posixGroup<vspace blankLines="0"/>
 247               ipService<vspace blankLines="0"/>
 248               ipProtocol<vspace blankLines="0"/>
 249               oncRpc<vspace blankLines="0"/>
 250               ipHost<vspace blankLines="0"/>
 251               ipNetwork<vspace blankLines="0"/>
 252               nisNetgroup<vspace blankLines="0"/>
 253               nisMap<vspace blankLines="0"/>
 254               nisObject<vspace blankLines="0"/>
 255               ieee802Device<vspace blankLines="0"/>
 256               bootableDevice<vspace blankLines="0"/>
 257               nisKeyObject<vspace blankLines="0"/>
 258               nisDomainObject<vspace blankLines="0"/>
 259               automountMap<vspace blankLines="0"/>
 260               automount<vspace blankLines="0"/>
 261             </t>
 262           </list>
 263           Additionally, some of the attributes defined in
 264           <xref target="RFC4519"/> are required.
 265         </t>
 266       </section>
 267          </section>
 268     </section>
 269     <section anchor="attrdefs" title="Attribute Definitions">
 270       <t>This section contains attribute definitions to be implemented
 271       by DUAs supporting this schema:
 272       <figure title="">
 273         <artwork>
 274   ( 1.3.6.1.1.1.1.0 NAME 'uidNumber'
 275       DESC 'An integer uniquely identifying a user in an
 276             administrative domain'
 277       EQUALITY integerMatch
 278       ORDERING integerOrderingMatch
 279       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 280       SINGLE-VALUE )
 281         </artwork>
 282       </figure>
 283       <figure>
 284         <artwork>
 285   ( 1.3.6.1.1.1.1.1 NAME 'gidNumber'
 286       DESC 'An integer uniquely identifying a group in an
 287             administrative domain'
 288       EQUALITY integerMatch
 289       ORDERING integerOrderingMatch
 290       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 291       SINGLE-VALUE )
 292         </artwork>
 293       </figure>
 294       <figure>
 295         <artwork>
 296   ( 1.3.6.1.1.1.1.2 NAME 'gecos'
 297       DESC 'The GECOS field; the common name'
 298       EQUALITY caseIgnoreMatch
 299       SUBSTRINGS caseIgnoreSubstringsMatch
 300       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 301       SINGLE-VALUE )
 302         </artwork>
 303       </figure>
 304       <figure>
 305         <artwork>
 306   ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory'
 307       DESC 'The absolute path to the home directory'
 308       EQUALITY caseExactIA5Match
 309       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 310       SINGLE-VALUE )
 311         </artwork>
 312       </figure>
 313       <figure>
 314         <artwork>
 315   ( 1.3.6.1.1.1.1.4 NAME 'loginShell'
 316       DESC 'The path to the login shell'
 317       EQUALITY caseExactIA5Match
 318       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 319       SINGLE-VALUE )
 320         </artwork>
 321       </figure>
 322       <figure>
 323         <artwork>
 324   ( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange'
 325       EQUALITY integerMatch
 326       ORDERING integerOrderingMatch
 327       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 328       SINGLE-VALUE )
 329         </artwork>
 330       </figure>
 331       <figure>
 332         <artwork>
 333   ( 1.3.6.1.1.1.1.6 NAME 'shadowMin'
 334       EQUALITY integerMatch
 335       ORDERING integerOrderingMatch
 336       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 337       SINGLE-VALUE )
 338         </artwork>
 339       </figure>
 340       <figure>
 341         <artwork>
 342   ( 1.3.6.1.1.1.1.7 NAME 'shadowMax'
 343       EQUALITY integerMatch
 344       ORDERING integerOrderingMatch
 345       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 346       SINGLE-VALUE )
 347         </artwork>
 348       </figure>
 349       <figure>
 350         <artwork>
 351   ( 1.3.6.1.1.1.1.8 NAME 'shadowWarning'
 352       EQUALITY integerMatch
 353       ORDERING integerOrderingMatch
 354       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 355       SINGLE-VALUE )
 356         </artwork>
 357       </figure>
 358       <figure>
 359         <artwork>
 360   ( 1.3.6.1.1.1.1.9 NAME 'shadowInactive'
 361       EQUALITY integerMatch
 362       ORDERING integerOrderingMatch
 363       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 364       SINGLE-VALUE )
 365         </artwork>
 366       </figure>
 367       <figure>
 368         <artwork>
 369   ( 1.3.6.1.1.1.1.10 NAME 'shadowExpire'
 370       EQUALITY integerMatch
 371       ORDERING integerOrderingMatch
 372       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 373       SINGLE-VALUE )
 374         </artwork>
 375       </figure>
 376       <figure>
 377         <artwork>
 378   ( 1.3.6.1.1.1.1.11 NAME 'shadowFlag'
 379       EQUALITY integerMatch
 380       ORDERING integerOrderingMatch
 381       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 382       SINGLE-VALUE )
 383         </artwork>
 384       </figure>
 385       <figure>
 386         <artwork>
 387   ( 1.3.6.1.1.1.1.12 NAME 'memberUid'
 388       EQUALITY caseExactMatch
 389       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
 390         </artwork>
 391       </figure>
 392       <figure>
 393         <artwork>
 394   ( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup'
 395       EQUALITY caseExactMatch
 396       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
 397         </artwork>
 398       </figure>
 399       <figure>
 400         <artwork>
 401   ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
 402       DESC 'Netgroup triple'
 403       EQUALITY caseIgnoreMatch
 404       SUBSTRINGS caseIgnoreSubstringsMatch
 405       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
 406         </artwork>
 407       </figure>
 408       <figure>
 409         <artwork>
 410   ( 1.3.6.1.1.1.1.15 NAME 'ipServicePort'
 411       DESC 'Service port number'
 412       EQUALITY integerMatch
 413       ORDERING integerOrderingMatch
 414       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 415       SINGLE-VALUE )
 416         </artwork>
 417       </figure>
 418       <figure>
 419         <artwork>
 420   ( 1.3.6.1.1.1.1.16 NAME 'ipServiceProtocol'
 421       DESC 'Service protocol name'
 422       EQUALITY caseIgnoreMatch
 423       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
 424         </artwork>
 425       </figure>
 426       <figure>
 427         <artwork>
 428   ( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber'
 429       DESC 'IP protocol number'
 430       EQUALITY integerMatch
 431       ORDERING integerOrderingMatch
 432       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 433       SINGLE-VALUE )
 434         </artwork>
 435       </figure>
 436       <figure>
 437         <artwork>
 438   ( 1.3.6.1.1.1.1.18 NAME 'oncRpcNumber'
 439       DESC 'ONC RPC number'
 440       EQUALITY integerMatch
 441       ORDERING integerOrderingMatch
 442       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
 443       SINGLE-VALUE )
 444         </artwork>
 445       </figure>
 446       <figure>
 447         <artwork>
 448   ( 1.3.6.1.1.1.1.19 NAME 'ipHostNumber'
 449       DESC 'IPv4 addresses as a dotted decimal omitting leading
 450             zeros or IPv6 addresses as defined in RFC2373'
 451       EQUALITY caseIgnoreIA5Match
 452       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
 453         </artwork>
 454       </figure>
 455       <figure>
 456         <artwork>
 457   ( 1.3.6.1.1.1.1.20 NAME 'ipNetworkNumber'
 458       DESC 'IP network omitting leading zeros, eg. 192.168'
 459       EQUALITY caseIgnoreIA5Match
 460       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 461       SINGLE-VALUE )
 462         </artwork>
 463       </figure>
 464       <figure>
 465         <artwork>
 466   ( 1.3.6.1.1.1.1.21 NAME 'ipNetmaskNumber'
 467       DESC 'IP netmask omitting leading zeros, eg. 255.255.255.0'
 468       EQUALITY caseIgnoreIA5Match
 469       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 470       SINGLE-VALUE )
 471         </artwork>
 472       </figure>
 473       <figure>
 474         <artwork>
 475   ( 1.3.6.1.1.1.1.22 NAME 'macAddress'
 476       DESC 'MAC address in maximal, colon separated hex
 477             notation, eg. 00:00:92:90:ee:e2'
 478       EQUALITY caseIgnoreIA5Match
 479       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
 480         </artwork>
 481       </figure>
 482       <figure>
 483         <artwork>
 484   ( 1.3.6.1.1.1.1.23 NAME 'bootParameter'
 485       DESC 'rpc.bootparamd parameter'
 486       EQUALITY caseExactIA5Match
 487       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
 488         </artwork>
 489       </figure>
 490       <figure>
 491         <artwork>
 492   ( 1.3.6.1.1.1.1.24 NAME 'bootFile'
 493       DESC 'Boot image name'
 494       EQUALITY caseExactIA5Match
 495       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
 496         </artwork>
 497       </figure>
 498       <figure>
 499         <artwork>
 500   ( 1.3.6.1.1.1.1.26 NAME 'nisMapName'
 501       DESC 'Name of a generic NIS map'
 502       EQUALITY caseIgnoreMatch
 503       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} )
 504         </artwork>
 505       </figure>
 506       <figure>
 507         <artwork>
 508   ( 1.3.6.1.1.1.1.27 NAME 'nisMapEntry'
 509       DESC 'A generic NIS entry'
 510       EQUALITY caseExactMatch
 511       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
 512       SINGLE-VALUE )
 513         </artwork>
 514       </figure>
 515       <figure>
 516         <artwork>
 517   ( 1.3.6.1.1.1.1.28 NAME 'nisPublicKey'
 518       DESC 'NIS public key'
 519       EQUALITY octetStringMatch
 520       SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
 521       SINGLE-VALUE )
 522         </artwork>
 523       </figure>
 524       <figure>
 525         <artwork>
 526   ( 1.3.6.1.1.1.1.29 NAME 'nisSecretKey'
 527       DESC 'NIS secret key'
 528       EQUALITY octetStringMatch
 529       SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
 530       SINGLE-VALUE )
 531         </artwork>
 532       </figure>
 533       <figure>
 534         <artwork>
 535   ( 1.3.6.1.1.1.1.30 NAME 'nisDomain'
 536       DESC 'NIS domain'
 537       EQUALITY caseIgnoreIA5Match
 538       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
 539         </artwork>
 540       </figure>
 541       <figure>
 542         <artwork>
 543   ( 1.3.6.1.1.1.1.31 NAME 'automountMapName'
 544       DESC 'automount Map Name'
 545       EQUALITY caseExactMatch
 546       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 547       SINGLE-VALUE )
 548         </artwork>
 549       </figure>
 550       <figure>
 551         <artwork>
 552   ( 1.3.6.1.1.1.1.32 NAME 'automountKey'
 553       DESC 'Automount Key value'
 554       EQUALITY caseExactMatch
 555       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 556       SINGLE-VALUE )
 557         </artwork>
 558       </figure>
 559       <figure>
 560         <artwork>
 561   ( 1.3.6.1.1.1.1.33 NAME 'automountInformation'
 562       DESC 'Automount information'
 563       EQUALITY caseExactMatch
 564       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 565       SINGLE-VALUE )
 566         </artwork>
 567       </figure></t>
 568     </section>
 569     <section anchor="classdefs" title="Class Definitions">
 570       <t>This section contains class definitions to be implemented by DUAs
 571       supporting the schema.</t>
 572       <t>Various schema for mail routing and delivery using LDAP directories
 573       have been proposed, and as such this document does not consider
 574       schema for representing mail aliases or distribution lists.
 575       <figure>
 576         <artwork>
 577   ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
 578       DESC 'Abstraction of an account with POSIX attributes'
 579       MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
 580       MAY ( authPassword $ userPassword $ loginShell $ gecos $
 581             description ) )
 582         </artwork>
 583       </figure>
 584       <figure>
 585         <artwork>
 586   ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' SUP top AUXILIARY
 587       DESC 'Additional attributes for shadow passwords'
 588       MUST uid
 589       MAY ( authPassword $ userPassword $ description $
 590             shadowLastChange $ shadowMin $ shadowMax $
 591             shadowWarning $ shadowInactive $
 592             shadowExpire $ shadowFlag ) )
 593         </artwork>
 594       </figure>
 595       <figure>
 596         <artwork>
 597   ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top AUXILIARY
 598       DESC 'Abstraction of a group of accounts'
 599       MUST gidNumber
 600       MAY ( authPassword $ userPassword $ memberUid $
 601             description ) )
 602         </artwork>
 603       </figure>
 604       <figure>
 605         <artwork>
 606   ( 1.3.6.1.1.1.2.3 NAME 'ipService' SUP top STRUCTURAL
 607       DESC 'Abstraction an Internet Protocol service.
 608             Maps an IP port and protocol (such as tcp or udp)
 609             to one or more names; the distinguished value of
 610             the cn attribute denotes the service's canonical
 611             name'
 612       MUST ( cn $ ipServicePort $ ipServiceProtocol )
 613       MAY description )
 614         </artwork>
 615       </figure>
 616       <figure>
 617         <artwork>
 618   ( 1.3.6.1.1.1.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
 619       DESC 'Abstraction of an IP protocol. Maps a protocol number
 620             to one or more names. The distinguished value of the cn
 621             attribute denotes the protocol canonical name'
 622       MUST ( cn $ ipProtocolNumber )
 623       MAY description )
 624         </artwork>
 625       </figure>
 626       <figure>
 627         <artwork>
 628   ( 1.3.6.1.1.1.2.5 NAME 'oncRpc' SUP top STRUCTURAL
 629       DESC 'Abstraction of an Open Network Computing (ONC)
 630            [RFC1057] Remote Procedure Call (RPC) binding.
 631            This class maps an ONC RPC number to a name.
 632            The distinguished value of the cn attribute denotes
 633            the RPC service canonical name'
 634       MUST ( cn $ oncRpcNumber )
 635       MAY description )
 636         </artwork>
 637       </figure>
 638       <figure>
 639         <artwork>
 640   ( 1.3.6.1.1.1.2.6 NAME 'ipHost' SUP top AUXILIARY
 641       DESC 'Abstraction of a host, an IP device. The distinguished
 642             value of the cn attribute denotes the host's canonical
 643          name. Device SHOULD be used as a structural class'
 644       MUST ( cn $ ipHostNumber )
 645       MAY ( authPassword $ userPassword $ l $ description $
 646             manager ) )
 647         </artwork>
 648       </figure>
 649       <figure>
 650         <artwork>
 651   ( 1.3.6.1.1.1.2.7 NAME 'ipNetwork' SUP top STRUCTURAL
 652       DESC 'Abstraction of a network. The distinguished value of
 653             the cn attribute denotes the network canonical name'
 654       MUST ipNetworkNumber
 655       MAY ( cn $ ipNetmaskNumber $ l $ description $ manager ) )
 656         </artwork>
 657       </figure>
 658       <figure>
 659         <artwork>
 660   ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
 661       DESC 'Abstraction of a netgroup. May refer to other
 662             netgroups'
 663       MUST cn
 664       MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )
 665         </artwork>
 666       </figure>
 667       <figure>
 668         <artwork>
 669   ( 1.3.6.1.1.1.2.9 NAME 'nisMap' SUP top STRUCTURAL
 670       DESC 'A generic abstraction of a NIS map'
 671       MUST nisMapName
 672       MAY description )
 673         </artwork>
 674       </figure>
 675       <figure>
 676         <artwork>
 677   ( 1.3.6.1.1.1.2.10 NAME 'nisObject' SUP top STRUCTURAL
 678       DESC 'An entry in a NIS map'
 679       MUST ( cn $ nisMapEntry $ nisMapName )
 680         </artwork>
 681       </figure>
 682       <figure>
 683         <artwork>
 684   ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' SUP top AUXILIARY
 685       DESC 'A device with a MAC address; device SHOULD be
 686             used as a structural class'
 687       MAY macAddress )
 688         </artwork>
 689       </figure>
 690       <figure>
 691         <artwork>
 692   ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice' SUP top AUXILIARY
 693       DESC 'A device with boot parameters; device SHOULD be
 694             used as a structural class'
 695       MAY ( bootFile $ bootParameter ) )
 696         </artwork>
 697       </figure>
 698       <figure>
 699         <artwork>
 700   ( 1.3.6.1.1.1.2.14 NAME 'nisKeyObject' SUP top AUXILIARY
 701       DESC 'An object with a public and secret key'
 702       MUST ( cn $ nisPublicKey $ nisSecretKey )
 703       MAY ( uidNumber $ description ) )
 704         </artwork>
 705       </figure>
 706       <figure>
 707         <artwork>
 708   ( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top AUXILIARY
 709       DESC 'Associates a NIS domain with a naming context'
 710       MUST nisDomain )
 711         </artwork>
 712       </figure>
 713       <figure>
 714         <artwork>
 715   ( 1.3.6.1.1.1.2.16 NAME 'automountMap' SUP top STRUCTURAL
 716       MUST ( automountMapName )
 717       MAY description )
 718         </artwork>
 719       </figure>
 720       <figure>
 721         <artwork>
 722   ( 1.3.6.1.1.1.2.17 NAME 'automount' SUP top STRUCTURAL
 723       DESC 'Automount information'
 724       MUST ( automountKey $ automountInformation )
 725       MAY description )
 726         </artwork>
 727       </figure>
 728       <figure>
 729         <artwork>
 730   ( 1.3.6.1.1.1.2.18 NAME 'groupOfMembers' SUP top STRUCTURAL
 731       DESC 'A group with members (DNs)'
 732       MUST cn
 733       MAY ( businessCategory $ seeAlso $ owner $ ou $ o $
 734             description $ member ) )
 735         </artwork>
 736       </figure></t>
 737     </section>
 738     <section anchor="impl" title="Implementation Details">
 739       <section anchor="impl.res_methods"
 740         title="Suggested Resolution Methods">
 741         <t>The preferred means of directing a client application (one using
 742         the shared services of the C library) to use LDAP as its information
 743         source for the functions listed in <xref target="appendixb"/> is to modify the
 744         source code to directly query LDAP. As the source to commercial C
 745         libraries and applications is rarely available to the end-user, one
 746         could emulate a supported nameservice (such as NIS). (This is also
 747         an appropriate opportunity to perform caching of entries across
 748         process address spaces.) In the case of NIS, reference
 749         implementations are widely available and the RPC interface is well
 750         known.</t>
 751         <t>The means by which the operating system is directed to use LDAP
 752         is implementation dependent. For example, some operating systems
 753         and C libraries support end-user extensible resolvers using
 754         dynamically loadable libraries and a nameservice "switch" (NSS).
 755                 The means in which the DUA locates LDAP servers is also
 756                 implementation dependent.</t>
 757       </section>
 758       <section anchor="impl.interp_user_group"
 759         title="Interpreting User and Group Entries">
 760         <t>User and group resolution is initiated by the functions prefixed
 761         by getpw and getgr respectively. The uid attribute contains the
 762         user's login name. The cn attribute, in posixGroup entries, contains
 763         the group's name.  This document preserves the use of the uid
 764         attribute even though, being a naming attribute, its syntax is case
 765         insensitive. This may cause a problem with existing deployments where
 766         there exist login names differing only in case. If DUAs support
 767         attribute mapping, a different attribute MAY be used to represent
 768         users' login names.</t>
 769         <t>The account object class provides a convenient structural class
 770         for posixAccount, and SHOULD be used where additional attributes
 771         are not required. Likewise, the groupOfMembers object class
 772                 SHOULD be used for groups. (The groupOfUniqueNames object class
 773                 is deprecated and SHOULD NOT be used.)</t>
 774         <t>It is suggested that uid and cn are used as the naming attribute
 775         for posixAccount and posixGroup entries, respectively. Group members
 776         may either be login names (values of memberUid) or distinguished
 777         names (values of member). In the latter case, the distinguished
 778         name must be mapped to one or more login names by examining the
 779         name's RDN or, if it is not distinguished by uid, performing a base
 780         search on the DN with a filter of "(objectclass=*)". DUAs MAY wish
 781         to cache DN to login name mappings. The DUA MAY traverse nested
 782         groups.</t>
 783         <t>An account's GECOS field is preferably determined by a value of
 784         the gecos attribute. If no gecos attribute exists, the value of the
 785         cn attribute MUST be used. (The existence of the gecos attribute
 786         allows information embedded in the GECOS field, such as a user's
 787         telephone number, to be returned to the client without overloading
 788         the cn attribute. It also accommodates directories where the common
 789         name does not contain the user's full name.)</t>
 790
 791                 <section title="Using Attribute Options">
 792                 <t>Some posixAccount attributes may be accompanied by <xref target="attroptions">options</xref>
 793                 identifying particular hosts or operating system types. The
 794                 attribute with a hostos option matching the operating system of
 795                 the DUA SHOULD be used in preference to an attribute without
 796                 any associated options. The attribute with a host option matching
 797                 the hostname of the DUA SHOULD be used in preference to any
 798                 other attribute.</t>
 799                 </section>
 800                 <section title="Authentication Considerations">
 801                 <section title="Using Password Values">
 802                 <t>When authenticating using a NIS to LDAP gateway or using NSS,
 803                 a lookup is performed to retrieve the password attribute and
 804                 the value is used in the DUA to authenticate a user. This
 805                 approach to authentication is deprecated, as it requires that
 806                 read access to the password attribute be granted across a
 807                 network.</t>
 808         <t>An entry of class posixAccount, posixGroup, or shadowAccount
 809         without an authPassword or userPassword attribute MUST NOT be used
 810         for authentication.  In this case the client SHOULD be returned a
 811         non-matchable password such as "x".</t>
 812         <t>If userPassword is used, its values MUST be represented by
 813         the following syntax:
 814         <figure>
 815           <artwork>
 816     passwordvalue   = schemeprefix hashedpasswd
 817     schemeprefix    = "{" scheme "}"
 818     scheme          = "crypt" / "md5" / "sha" / "ssha" / altscheme
 819     altscheme       = "x-" keystring
 820     hashedpasswd    = hashed password
 821           </artwork>
 822         </figure></t>
 823         <t>The hashed password contains a plaintext key hashed using
 824         the algorithm scheme.  If the schema is "sha", the hashed
 825         password is the base64 encoding of the SHA-1 digest of the plaintext
 826         password.</t>
 827         <t>userPassword values which do not adhere to this syntax MUST NOT be
 828         used for authentication. The DUA MUST iterate through the values of
 829         the attribute until a value matching the above syntax is found.
 830         Only if hashedpassword is an empty string does the user have no
 831         password.  DUAs are not required to consider hashing schemes
 832         which the client will not recognize; in most cases, it may be
 833         sufficient to consider only "crypt".</t>
 834         <t>DUA MAY use the authPassword attribute instead of userPassword,
 835         defined in <xref target="RFC3112"/>.  The DUA MUST iterate the values of the
 836         authPassword attribute until a value whose scheme is CRYPT is found.
 837         The DUA MAY iterate through the values of the userPassword
 838         attribute, using the syntax defined here, until a value
 839         whose scheme is CRYPT is found. If no conforming value is found,
 840         the client MUST be returned a non-matchable password such as "x".
 841         Authentication using schemes other than CRYPT is, although advisable,
 842         beyond the scope of this document</t>
 843         <t>Below is an example of an authPassword attribute:
 844         <figure>
 845           <artwork>
 846     authPassword: CRYPT$X5/DBrWPOQQaI
 847           </artwork>
 848         </figure></t>
 849         <t>Below is an example of a (deprecated) userPassword attribute:
 850         <figure>
 851           <artwork>
 852     userPassword: {CRYPT}X5/DBrWPOQQaI
 853           </artwork>
 854         </figure></t>
 855         <t>A DUA MAY utilize the attributes in the shadowAccount class to
 856         provide shadow password service (getspnam() and getspent()). In such
 857         cases, the DUA MUST NOT make use of the userPassword attribute for
 858         getpwnam() et al, and MUST return a non-matchable password (such as
 859         "x") to the client instead.</t>
 860                 </section>
 861                 <section title="Using LDAP Bind">
 862                 <t>The preferred method for authenticating users with LDAP is to
 863                 perform an LDAP Bind operation with the user's name and password.
 864                 In this case the method the DSA uses to store and verify the password
 865                 is completely internal to the DSA and not of any concern to the DUA.</t>
 866                 <t>Likewise, using the shadowAccount attributes requires the DUA to
 867                 handle password policy enforcement. However the policies expressed
 868                 in the shadowAccount are limited in scope, and not uniformly
 869                 applicable to all the systems that will be using LDAP.</t>
 870                 <t>The preferred method is to leave password policy enforcement
 871                 to the DSA, so that it will be uniformly enforced across all of
 872                 the various systems that rely on the directory. This enforcement
 873                 occurs implicitly when authenticating using LDAP Bind if the
 874                 DSA supports the
 875                 <xref target="I-D.behera-ldap-password-policy">LDAP password
 876                 policy</xref> mechanisms.</t>
 877                 <t>The means in which authentication in the DUA is configured
 878                 is implementation dependent. Typically it is accomplished using
 879                 <xref target="PAM"/>. Further details of authentication are
 880                 beyond the scope of this document.</t>
 881                 </section>
 882            </section>
 883            <section title="Naming Considerations">
 884            <t>On UNIX systems, users and groups reside in separate name spaces
 885            and it is common for the same name to be used by both a user and a
 886            group. Since they are in separate name spaces there is no ambiguity
 887            and no conflict. However, when integrating a name service into LDAP
 888            the directory may be used with other systems besides UNIX and its
 889            derivatives. In particular, the Microsoft Windows operating system
 890            may also use LDAP for its own name service. In Windows, users and
 891            groups reside in a single name space and so one cannot use the same
 892            name for both a user and a group.</t>
 893            <t>Conflicts in naming conventions may arise in other deployments
 894            as well, and should be carefully taken into account when migrating
 895            from other naming services into LDAP.</t>
 896            </section>
 897       </section>
 898       <section anchor="impl.interp_host_net"
 899         title="Interpreting Hosts and Networks">
 900         <t>The ipHostNumber and ipNetworkNumber attributes are defined in
 901         preference to dNSRecord (defined in <xref target="RFC1279"/>), in order to simplify
 902         the DUA's role in interpreting entries in the directory. A dNSRecord
 903         expresses a complete resource record, including time to live and
 904         class data, which is extraneous to this schema.</t>
 905         <t>Additionally, the ipHost and ipNetwork classes permit a host or
 906         network (respectively) and all its aliases to be represented by a
 907         single entry in the directory. This is not necessarily possible if
 908         a DNS resource record is mapped directly to an LDAP entry.
 909         Implementations that wish to use LDAP to master DNS zone information
 910         are not precluded from doing so, and may simply avoid the ipHost and
 911         ipNetwork classes.</t>
 912         <t>This document redefines, although not exclusively, the ipNetwork
 913         class defined in <xref target="RFC1279"/>, in
 914         order to achieve consistent naming with ipHost. The ipNetworkNumber
 915         attribute is also used in the <xref target="ROSE">siteContact
 916         object class</xref>.</t>
 917         <t>The authPassword and userPassword attributes are included in
 918         ipHost such that hosts MAY be treated as authentication principals.
 919         The treatment of these attributes and inherent caveats considered in
 920         <xref target="impl.interp_user_group"></xref> apply here also.</t>
 921         <t>The trailing zeros in a network address MUST be omitted.
 922         CIDR-style network addresses (eg. 192.168.1/24) MAY be used. Leading
 923         zeros MUST be removed from all components of an IPv6 address string
 924         as defined by <xref target="RFC2373"/>, section 2.2,
 925         item 1.  The IPv6 address string MUST be further normalized
 926         by following the "::" syntax as defined in
 927         <xref target="RFC2373"/>, section 2.2, item 2.
 928         In addition, "::" MUST be used to replace the longest string of zero
 929         bits.  If there are two or more longest strings of zero bits, then
 930         the first string MUST be replaced. In addition, the syntax defined
 931         by <xref target="RFC2373"/>, section 2.2, item 3
 932         MUST NOT be used.  IPv4 addresses MUST be represented by the IPv4
 933         dotted decimal string syntax.</t>
 934         <t>For example the following address:
 935         <figure>
 936           <artwork>
 937     1080:0000:0:0:08:800:200C:417A
 938     FF01:0:0:0:0:0:01
 939     0:0:0:0:0:0:0:0001
 940     0:0:0:0:0:0:0:0
 941           </artwork>
 942         </figure>
 943         MUST be normalized as:
 944         <figure>
 945           <artwork>
 946     1080::8:800:200C:417A
 947     FF01::101
 948     0::1
 949     ::
 950           </artwork>
 951         </figure></t>
 952       </section>
 953       <section anchor="impl.interp_other"
 954         title="Interpreting Other Entities">
 955         <t>In general, a one-to-one mapping between entities and LDAP entries
 956         is proposed, in that each entity has exactly one representation in
 957         the DIT. In some cases this is not feasible; for example, a service
 958         which is represented in more than one protocol domain. Consider the
 959         following entry:
 960         <figure>
 961           <artwork>
 962     dn: cn=domain,ou=services,dc=aja,dc=com
 963     objectClass: top
 964     objectClass: ipService
 965     cn: domain
 966     cn: nameserver
 967     ipServicePort: 53
 968     ipServiceProtocol: tcp
 969     ipServiceProtocol: udp
 970           </artwork>
 971         </figure>
 972         This entry MUST map to the following two (2) services entities:
 973         <figure>
 974           <artwork>
 975     domain  53/tcp  nameserver
 976     domain  53/udp  nameserver
 977           </artwork>
 978         </figure>
 979         While the above two entities may be represented as separate LDAP
 980         entities, with different distinguished names (such as
 981         cn=domain+ipServiceProtocol=tcp, ... and
 982         cn=domain+ipServiceProtocol=udp, ...) it is convenient to represent
 983         them as a single entry. If a service is represented in multiple
 984         protocol domains with different ports, then multiple entries are
 985         required; multi-valued RDNs MAY be used to distinguish them.)</t>
 986         <t>With the exception of authPassword and userPassword values, empty
 987         values (consisting of a zero length string) are returned by the DUA
 988         to the client. The DUA MUST reject any entries which do not conform
 989         to the schema (missing mandatory attributes). Non-conforming
 990         entries SHOULD be ignored while enumerating entries.</t>
 991         <t>The nisDomainObject object class is provided to associate a NIS
 992         domain with a naming context. A DUA would retrieve the NIS domain
 993         name from a configuration file and enumerate the naming contexts
 994         served by an LDAP server, searching each naming context for
 995         (nisDomain=%s).  The first matching entry that is found MAY be used
 996         as a search base for configuration profile information or for entries
 997         themselves. For example, the following example shows an association
 998         between the NIS domain "nis.aja.com" and the naming context
 999         "dc=aja,dc=com":
1000         <figure>
1001           <artwork>
1002     dn: dc=aja,dc=com
1003     objectClass: top
1004     objectClass: domain
1005     objectClass: nisDomainObject
1006     dc: aja
1007     nisDomain: nis.aja.com
1008           </artwork>
1009         </figure>
1010         The nisObject object class MAY be used as a generic means of
1011         representing NIS entities. Its use is not encouraged; where support
1012         for entities not described in this schema is desired, an appropriate
1013         schema should be devised. Implementers are strongly advised to
1014         support end-user extensible mappings between NIS entities and object
1015         classes. (Where the nisObject class is used, the nisMapName
1016         attribute MAY be used as a RDN.) The nisObject class might be used
1017         to represent automount information.</t>
1018       </section>
1019       <section anchor="impl.canon_entries"
1020         title="Canonicalizing entries with multi-valued naming attributes">
1021         <t>For entities such as hosts, services, networks, protocols, and
1022         RPCs, where there may be one or more aliases, the respective entry's
1023         relative distinguished name SHOULD be used to determine the canonical
1024         name.  Any other values for the same attribute are used as aliases.
1025         For example, the service described in
1026         <xref target="impl.interp_other" /> has the canonical name "domain"
1027         and exactly one alias, "nameserver".</t>
1028         <t>The schema in this document generally only defines one attribute
1029         per class which is suitable for distinguishing an entity (excluding
1030         any attributes with integer syntax; it is assumed that entries will
1031         be distinguished on name). Usually, this is the common name (cn)
1032         attribute.  This aids the DUA in determining the canonical name of
1033         an entity, as it can examine the value of the relative distinguished
1034         name. Aliases are thus any values of the distinguishing attribute
1035         (such as cn) which do not match the canonical name of the entity.</t>
1036         <t>In the event that a different attribute is used to distinguish the
1037         entry, as may be the case where these object classes are used as
1038         auxiliary classes, the entry's canonical name may not be present in
1039         the RDN. In this case, the DUA MUST choose one of the
1040         non-distinguished values to represent the entity's canonical name. As
1041         the directory server guarantees no ordering of attribute values, it
1042         may not be possible to distinguish an entry deterministically. This
1043         ambiguity SHOULD NOT be resolved by mapping one directory entry into
1044         multiple entities.</t>
1045       </section>
1046     </section>
1047     <section anchor="focus" title="Implementation Focus">
1048       <t>Gateways between NIS and LDAP have been developed by PADL Software
1049       and Sun Microsystems. They both support this schema.</t>
1050       <t>An open source implementation of the C library resolution code has
1051       been written and is available from PADL Software. It supports C
1052       libraries on GNU, BSD, AIX, and Solaris operating systems. PADL
1053       have also made available a set of scripts for migrating flat files
1054       into a form suitable for loading into an LDAP server. Another
1055           open source implementation of the C library code is available from
1056           the OpenLDAP Project.</t>
1057     </section>
1058     <section anchor="security" title="Security Considerations">
1059       <t>The entirety of related security considerations are outside the
1060       scope of this document.  It is noted that making passwords
1061       encrypted with a widely understood hash function (such as crypt())
1062       available to non-privileged users is dangerous because it exposes
1063       them to dictionary and brute-force attacks.  This is proposed only
1064       for compatibility with existing UNIX system implementations. Sites
1065       where security is critical SHOULD consider using a strong
1066       authentication service for user authentication.</t>
1067       <t>Alternatively, the encrypted password could be made available only
1068       to a subset of privileged DUAs, which would provide "shadow" password
1069       service to client applications. This may be difficult to enforce.</t>
1070       <t>Because the schema represents operating system-level entities,
1071       access to these entities SHOULD be granted on a discretionary
1072       basis. (There is little point in restricting access to data which
1073       will be republished without restriction, however.) It is particularly
1074       important that only administrators can modify entries defined in this
1075       schema, with the exception of allowing a principal to change their
1076       password (which MAY be done on behalf of the user by a client bound
1077       as a superior principal, such that password restrictions MAY be
1078       enforced). For example, if a user were allowed to change the value of
1079       their uidNumber attribute, they could subvert security by
1080       equivalencing their account with the superuser account.</t>
1081       <t>A subtree of the DIT which is to be republished by a DUA (such as a
1082       NIS gateway) SHOULD be within the same administrative domain that
1083       the republishing DUA represents. (For example, principals outside
1084       an organization, while conceivably part of the DIT, should not be
1085       considered with the same degree of authority as those within the
1086       organization.)</t>
1087       <t>Finally, care should be exercised with integer attributes of a
1088       sensitive nature (particularly the uidNumber and gidNumber attributes)
1089       which contain zero-length values. DUAs MAY treat such values as
1090       corresponding to the "nobody" or "nogroup" user and group,
1091       respectively.</t>
1092     </section>
1093     <section anchor="acks" title="Acknowledgements">
1094       <t> Thanks to Bob Joslin of the Hewlett Packard Company, and to all
1095      those that helped with this document's predecessor, RFC 2307.</t>
1096       <t> UNIX is a registered trademark of The Open Group.</t>
1097     </section>
1098   </middle>
1099   <back>
1100     <references>
1101           &rfc1034;
1102           &rfc1057;
1103           &rfc1279;
1104           &rfc2373;
1105           &rfc2119;
1106           &rfc4511;
1107           &rfc4515;
1108           &rfc4519;
1109           &rfc3112;
1110           &ppolicy;
1111       <reference anchor="ROSE">
1112         <front>
1113           <title>
1114             The Little Black Book: Mail Bonding with OSI Directory Services
1115           </title>
1116           <author initials="M. T." surname="Rose">
1117             <organization abbrev="Prentice-Hall">
1118               Prentice-Hall, Inc
1119             </organization>
1120           </author>
1121           <date month="" year="2001"/>
1122         </front>
1123         <seriesInfo name="ISBN" value="0-13-683210-5"/>
1124       </reference>
1125       <reference anchor="X.500">
1126         <front>
1127           <title>
1128             Information Processing Systems - Open Systems Interconnection -
1129             The Directory: Overview of Concepts, Models and Service
1130           </title>
1131           <author>
1132             <organization>
1133               ISO/IEC JTC 1/SC21
1134             </organization>
1135           </author>
1136           <date month="" year="1988"/>
1137         </front>
1138       </reference>
1139       <reference anchor="UNIX">
1140         <front>
1141           <title>
1142             IEEE Std 1003.1, 2004 Edition, Single UNIX Specification Version 3
1143           </title>
1144           <author>
1145             <organization>
1146               Institute of Electrical and Electronics Engineers
1147             </organization>
1148           </author>
1149           <author>
1150             <organization>
1151               The Open Group
1152             </organization>
1153           </author>
1154           <date month="" year="2004" />
1155         </front>
1156       <seriesInfo name="IEEE" value="Standard 1003.1" />
1157       </reference>
1158           <reference anchor="PAM">
1159             <front>
1160                   <title>
1161                   Unified Login with Pluggable Authentication Modules (PAM)
1162                   </title>
1163                   <author initials="V." surname="Samar" fullname="Vipin Samar">
1164                   <organization>SunSoft, Inc.</organization>
1165                   </author>
1166                   <author initials="R.J." surname="Schemers"
1167                         fullname="Roland J. Schemers III">
1168                         <organization>SunSoft, Inc.</organization>
1169                   </author>
1170                   <date month="October" year="1995"/>
1171                 </front>
1172                 <seriesInfo name="OSF RFC" value="86.0"/>
1173                 <format type="TXT" octets="67952"
1174                         target="http://www.opengroup.org/rfc/mirror-rfc/rfc86.0.txt"/>
1175                 <format type="HTML" octets="59468"
1176                     target="http://www.opengroup.org/rfc/rfc86.0.html" />
1177           </reference>
1178     </references>
1179     <section anchor="appendixa" title="Example Entries">
1180       <t>The examples described in this section are provided to illustrate
1181       the schema described in this draft. They are not meant to be
1182       exhaustive.</t>
1183       <t>The following entry is an example of the posixAccount class:
1184       <figure>
1185         <artwork>
1186     dn: uid=lester,ou=people,dc=aja,dc=com
1187     objectClass: top
1188     objectClass: account
1189     objectClass: posixAccount
1190     uid: lester
1191     cn: Lester the Nightfly
1192     gecos: Lester
1193     uidNumber: 10
1194     gidNumber: 10
1195     loginShell: /bin/csh
1196     userPassword: {crypt}$X5/DBrWPOQQaI
1197     homeDirectory: /home/lester
1198         </artwork>
1199       </figure>
1200       This corresponds to the UNIX system password file entry:
1201       <figure>
1202         <artwork>
1203     lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh
1204         </artwork>
1205       </figure>
1206       The following entry is an example of the ipHost class:
1207       <figure>
1208         <artwork>
1209     dn: cn=josie.aja.com,ou=hosts,dc=aja,dc=com
1210     objectClass: top
1211     objectClass: device
1212     objectClass: ipHost
1213     objectClass: bootableDevice
1214     objectClass: ieee802Device
1215     cn: josie.aja.com
1216     cn: www.aja.com
1217     ipHostNumber: 10.0.0.1
1218     macAddress: 00:00:92:90:ee:e2
1219     bootFile: mach
1220     bootParameter: root=dan.aja.com:/nfsroot/peg
1221     bootParameter: swap=dan.aja.com:/nfsswap/peg
1222     bootParameter: dump=dan.aja.com:/nfsdump/peg
1223         </artwork>
1224       </figure>
1225       This entry represents the host canonically josie.aja.com, also
1226       known as www.aja.com. The Ethernet address and four boot parameters
1227       are also specified.</t>
1228       <t>An example of the nisNetgroup class:
1229       <figure>
1230         <artwork>
1231     dn: cn=nightfly,ou=netgroup,dc=aja,dc=com
1232     objectClass: top
1233     objectClass: nisNetgroup
1234     cn: nightfly
1235     nisNetgroupTriple: (charlemagne,peg,dunes.aja.com)
1236     nisNetgroupTriple: (lester,-,)
1237     memberNisNetgroup: kamakiriad
1238         </artwork>
1239       </figure>
1240         This entry represents the netgroup nightfly, which contains two
1241         triples (the user charlemagne, the host peg, and the domain
1242         dunes.aja.com; and, the user lester, no host, and any domain) and
1243         one netgroup (kamakiriad).</t>
1244         <t>Finally, an example of the nisObject class:
1245       <figure>
1246         <artwork>
1247     dn: nisMapName=tracks,dc=dunes,dc=aja,dc=com
1248     objectClass: top
1249     objectClass: nisMap
1250     nisMapName: tracks
1251
1252     dn: cn=Maxine,nisMapName=tracks,dc=dunes,dc=aja,dc=com
1253     objectClass: top
1254     objectClass: nisObject
1255     cn: Maxine
1256     nisMapName: tracks
1257     nisMapEntry: Nightfly$4
1258         </artwork>
1259       </figure>
1260       This represents the NIS map tracks, and a single map entry.</t>
1261     </section>
1262     <section anchor="appendixb" title="Affected Library Functions">
1263       <t>The following functions are typically found in the C libraries of
1264       most <xref target="UNIX">UNIX and POSIX compliant systems</xref>.
1265       An <xref target="RFC4515"> LDAP search filter string</xref> which
1266       may be used to satisfy the function call is included alongside each
1267       function name. Parameters are denoted by %s and %d for string and
1268       integer arguments, respectively. Long lines are broken:
1269       <figure>
1270         <artwork>
1271     getpwnam()         (&amp;(objectClass=posixAccount)(uid=%s))
1272     getpwuid()         (&amp;(objectClass=posixAccount)(uidNumber=%d))
1273     getpwent()         (objectClass=posixAccount)
1274     getspnam()         (&amp;(objectClass=shadowAccount)(uid=%s))
1275     getspent()         (objectClass=shadowAccount)
1276
1277     getgrnam()         (&amp;(objectClass=posixGroup)(cn=%s))
1278     getgrgid()         (&amp;(objectClass=posixGroup)(gidNumber=%d))
1279     getgrent()         (objectClass=posixGroup)
1280
1281     getservbyname()    (&amp;(objectClass=ipService)(cn=%s)
1282                         (ipServiceProtocol=%s))
1283     getservbyport()    (&amp;(objectClass=ipService)(ipServicePort=%d)
1284                          (ipServiceProtocol=%s))
1285     getservent()       (objectClass=ipService)
1286
1287     getrpcbyname()     (&amp;(objectClass=oncRpc)(cn=%s))
1288     getrpcbynumber()   (&amp;(objectClass=oncRpc)(oncRpcNumber=%d))
1289     getrpcent()        (objectClass=oncRpc)
1290
1291     getprotobyname()   (&amp;(objectClass=ipProtocol)(cn=%s))
1292     getprotobynumber() (&amp;(objectClass=ipProtocol)
1293                           (ipProtocolNumber=%d))
1294     getprotoent()      (objectClass=ipProtocol)
1295
1296     gethostbyname()    (&amp;(objectClass=ipHost)(cn=%s))
1297     gethostbyaddr()    (&amp;(objectClass=ipHost)(ipHostNumber=%s))
1298     gethostent()       (objectClass=ipHost)
1299
1300     getnetbyname()     (&amp;(objectClass=ipNetwork)(cn=%s))
1301     getnetbyaddr()     (&amp;(objectClass=ipNetwork)(ipNetworkNumber=%s))
1302     getnetent()        (objectClass=ipNetwork)
1303
1304     setnetgrent()      (&amp;(objectClass=nisNetgroup)(cn=%s))
1305     getpublickey()     (&amp;(objectClass=nisKeyObject)(...))
1306         </artwork>
1307       </figure></t>
1308     </section>
1309     <section anchor="appendixc" title="Suggested DIT structure">
1310       <t>The cn attribute is typically used to name entities. The
1311       ipHostNumber, ipNetworkNumber, and ipServiceProtocol attributes are also
1312       naming attributes, such that multi-valued RDNs may be used to
1313       distinguish between, for example, different interfaces of a multihomed
1314       host.</t>
1315       <t>The following DIT structure MAY be used for deploying this schema.
1316       It is not required that DC-naming be used, but it is encouraged:
1317       <figure>
1318         <artwork>
1319     Naming context                        ObjectClass
1320     ============================================================
1321     ou=people,dc=...                      posixAccount
1322                                           shadowAcount
1323     ou=group,dc=...                       posixGroup
1324     ou=services,dc=...                    ipService
1325     ou=protocols,dc=...                   ipProtocol
1326     ou=rpc,dc=...                         oncRpc
1327     ou=hosts,dc=...                       ipHost
1328     ou=ethers,dc=...                      ieee802Device
1329                                           bootableDevice
1330     ou=networks,dc=...                    ipNetwork
1331     ou=netgroup,dc=...                    nisNetgroup
1332     nisMapName=...,dc=...                 nisObject
1333     automountMapName=...,dc=...           automountMap
1334         </artwork>
1335       </figure></t>
1336     </section>
1337   </back>
1338 </rfc>