]> git.sur5r.net Git - openldap/blob - doc/drafts/draft-howard-rfc2307bis-xx.xml
Merge remote-tracking branch 'origin/mdb.master'
[openldap] / 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>