idnits 2.17.1 draft-sermersheim-nds-ldap-schema-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 13) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2256], [LDAPV3], [RFC2252]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 101: '...stinguished name MUST be validated by ...' RFC 2119 keyword, line 105: '...lidDNSyntax (34) MUST be returned in t...' RFC 2119 keyword, line 142: '... If true, this object class MAY NOT be...' RFC 2119 keyword, line 155: '...th a list of all MUST and MAY attribut...' RFC 2119 keyword, line 299: '... NDS servers MUST, and Clients that ...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 343 has weird spacing: '... number uint3...' == Line 390 has weird spacing: '... number uint3...' == Line 416 has weird spacing: '... number uint3...' == Line 617 has weird spacing: '...Seconds uin...' == Line 673 has weird spacing: '... number uint3...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Valid values for the qdstrings following X-NDS_NONREMOVABLE are '0' (false) and '1' (true). If true, this object class MAY NOT be removed from the schema. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'LDAPV3' on line 765 looks like a reference -- Missing reference section? 'RFC2252' on line 775 looks like a reference -- Missing reference section? 'RFC2256' on line 51 looks like a reference -- Missing reference section? 'RFC2119' on line 788 looks like a reference -- Missing reference section? 'Self' on line 536 looks like a reference -- Missing reference section? 'Creator' on line 539 looks like a reference -- Missing reference section? 'Public' on line 541 looks like a reference -- Missing reference section? 'Root' on line 544 looks like a reference -- Missing reference section? 'RFC1778' on line 770 looks like a reference -- Missing reference section? 'RFC2253' on line 780 looks like a reference -- Missing reference section? 'BYTEORDER' on line 792 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission J. Sermersheim 2 Internet Draft Novell, Inc. 3 Document: draft-sermersheim-nds-ldap-schema-00.txt March, 2000 4 Category: Informational 6 LDAP Schema for NDS 8 1. Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 2. Abstract 28 This document defines [LDAPV3] schema used by Novell Directory 29 Services (referred to here as NDS). The syntaxes, attribute types 30 and object classes defined in this document are unique to NDS and 31 are meant to compliment those defined in [RFC2252], [RFC2256] and 32 other RFCs and Internet Drafts. 34 3. Overview 36 The purpose of this document is to advertise any schema elements 37 used by an NDS server which haven't previously been defined in 38 another RFC or Internet Draft. The schema elements defined here 39 represent those in use by NDS version 8 and later. 41 4. Conventions used in this document 43 The key words from [RFC2119] are used in this document are to be 44 interpreted as described there. 46 4.1. Encodings 48 This document describes encodings used in an Internet protocol. 50 Sermersheim Informational - Expires September 2000 1 51 This document builds upon [RFC2252], [RFC2256] and their 52 predecessors. Implementers are strongly encouraged to become 53 familiar with those documents before reading this. 55 The attribute syntax definitions in this document, are represented 56 as strings in BNF and in some cases, ASN.1. The intention is that 57 the string representations are used in normal transmissions of 58 attributes using these syntaxes. The ASN.1 is included for cases 59 where the "binary" Attribute Type Option is used (see 4.1.5.1 of 60 [LDAPV3]). Applications may use the "binary" Attribute Type option 61 when transmitting and requesting attributes, in which case the BER 62 encoding of the ASN.1 data type will be returned. 64 4.1.1. BNF 66 The BNF descriptions used here are described in section 4.1 of 67 [RFC2252]. The following definitions are also added: 69 distinguishedname = 70 uint16string = numericstring ; values transmitted as 71 ; uint16string have an 72 ; upper bound of "65535" 73 uint32string = numericstring ; values transmitted as 74 ; uint32string have an 75 ; upper bound of "4294967295" 77 There is no historical set convention for the use of value 78 delimiting characters. In this document, the following convention is 79 used: 80 "#" is used to delimit disparate elements 81 "$" is used to delimit like elements (such as those in a list) 82 "," is used to delimit disparate values which make up a single list 83 element or to separate disparate elements of a complex element which 84 itself is being separated by the "#" character. 86 4.1.2. ASN.1 88 The ASN.1 definitions include ASN.1 definitions from [LDAPV3] as 89 well as the following: 91 uint16 ::= INTEGER(0..maxUint16) 92 maxUint16 ::= 65535 -- (2^^16 - 1) 94 uint32 ::= INTEGER(0..maxUint32) 95 maxUint32 ::= 4294967295 -- (2^^32 - 1) 97 4.2. Distinguished Names 99 One must be aware that, when storing values in attributes of any 100 syntax listed here which contain a distinguished name, the value of 101 the distinguished name MUST be validated by the DSA. If a client 102 sends a distinguished name, which does not exist in the DIT, the 104 Sermersheim Informational - Expires September 2000 2 105 LDAP error invalidDNSyntax (34) MUST be returned in the LDAPResult. 107 4.3. Object Class Description 109 The NDSObjectClassDescription defined here, adds to the 110 ObjectClassDescription, which is defined in section 4.4 of 111 [RFC2252]. The added terms, which begin with the characters 112 "X-NDS ", exist to describe NDS specific object class flags and 113 states which have not yet been adopted by LDAP object classes. 115 Lines have been folded for readability, transmissions of the 116 NDSObjectClassDescription do not contain newlines. The description 117 of whsp, qdescrs, qdstring, woid, numericstring, and noidlen are 118 given in section 4.1 of [RFC2252]. 120 NDSObjectClassDescription = "(" whsp 121 numericoid whsp ; ObjectClass identifier 122 [ "NAME" qdescrs ] 123 [ "DESC" qdstring ] 124 [ "OBSOLETE" whsp ] 125 [ "SUP" oids ] ; Superior ObjectClasses 126 [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] 127 ; default structural 128 [ "MUST" oids ] ; AttributeTypes 129 [ "MAY" oids ] ; AttributeTypes 130 [ "X-NDS_NOT_CONTAINER" qdstrings ] ; default container ('0') 131 [ "X-NDS_NONREMOVABLE" qdstrings ] ; default removable ('0') 132 [ "X-NDS_CONTAINMENT" qdstrings ] 133 [ "X-NDS_NAMING" qdstrings ] 134 [ "X-NDS_NAME" qdstrings ] ; legacy NDS name 135 whsp ")" 137 Valid values for the qdstrings following X-NDS_NOT_CONTAINER are '0' 138 (false) and '1' (true). If true, instances of this object class may 139 not contain other object entries (it is a leaf node). 141 Valid values for the qdstrings following X-NDS_NONREMOVABLE are '0' 142 (false) and '1' (true). If true, this object class MAY NOT be 143 removed from the schema. 145 The qdstrings following X-NDS_CONTAINMENT contains a list of all 146 object class names which may contain this object class. In other 147 words, only entries that are of an object class listed here may be a 148 direct superior in the DIT to entries of this object class. If this 149 term is not included when defining an object class, it will be 150 automatically filled with ( 'c' 'o' 'ou' 'l' 'domain'). 152 The qdstrings following X-NDS_NAMING holds a list of all attribute 153 type names that may be used to name this object class. If this term 154 is not supplied when defining an object class, it will automatically 155 be filled with a list of all MUST and MAY attributes which use any 156 of the following syntaxes: Country String, Directory String, IA5 158 Sermersheim Informational - Expires September 2000 3 159 String, and Printable String. 161 X-NDS_NAME is followed by a qdstrings which contains the legacy NDS 162 name for this object class. An example is ('Organizational Person'). 163 Because NDS was created before LDAP was defined, it sometimes 164 doesn't adhere to the exact same rules as LDAP. One such LDAP rule 165 is that the names of schema elements cannot contain anything other 166 than ASCII letters, the hyphen character and semicolon. NDS allows 167 spaces, colons, and others. For this reason, some schema elements 168 will have LDAP names that are different from the NDS names that they 169 were first known as. 171 4.4. Attribute Description 173 The NDSAttributeTypeDescription defined here, adds to the 174 AttributeTypeDescription, which is defined in section 4.2 of 175 [RFC2252]. The added terms, which begin with the characters 176 "X-NDS ", exist to describe NDS specific attribute constraints which 177 have not yet been adopted by LDAP attributes. 179 Lines have been folded for readability, transmissions of the 180 NDSAttributeTypeDescription do not contain newlines. The description 181 of whsp, qdescrs, qdstring, woid, numericstring, and noidlen are 182 given in section 4.3.2 of [RFC2252]. 184 NDSAttributeTypeDescription = "(" whsp 185 numericoid whsp ; AttributeType identifier 186 [ "NAME" qdescrs ] ; name used in AttributeType 187 [ "DESC" qdstring ] ; description 188 [ "OBSOLETE" whsp ] 189 [ "SUP" woid ] ; derived from this other 190 ; AttributeType 191 [ "EQUALITY" woid ] ; Matching Rule name 192 [ "ORDERING" woid ] ; Matching Rule name 193 [ "SUBSTR" woid ] ; Matching Rule name 194 [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 of[RFC2252] 195 [ "SINGLE-VALUE" whsp ] ; default multi-valued 196 [ "COLLECTIVE" whsp ] ; default not collective 197 [ "NO-USER-MODIFICATION" whsp ] ; default user modifiable 198 [ "USAGE" whsp AttributeUsage ] ; default userApplications 199 [ "X-NDS_PUBLIC_READ" qdstrings ] 200 ; default not public read ('0') 201 [ "X-NDS_SERVER_READ" qdstrings ] 202 ; default not server read ('0') 203 [ "X-NDS_NEVER_SYNC" qdstrings ] 204 ; default not never sync ('0') 205 [ "X-NDS_NOT_SCHED_SYNC_IMMEDIATE" qdstrings ] 206 ; default sched sync 207 ; immediate ('0') 208 [ "X-NDS_SCHED_SYNC_NEVER" qdstrings ] 209 ; default schedule sync ('0') 210 [ "X-NDS_LOWER_BOUND" qdstrings ] 212 Sermersheim Informational - Expires September 2000 4 213 ; default no lower bound 214 ; ('0')(upper is specified in 215 ; SYNTAX) 216 [ "X-NDS_NAME_VALUE_ACCESS" qdstrings ] 217 ; default not name value 218 ; access ('0') 219 [ "X-NDS_NAME" qdstrings ] ; legacy NDS name 221 whsp ")" 223 AttributeUsage = 224 "userApplications" / 225 "directoryOperation" / 226 "distributedOperation" / ; DSA-shared 227 "dSAOperation" ; DSA-specific, value depends 228 ; on server 230 Valid values for the qdstrings following X-NDS_PUBLIC_READ are '0' 231 (false) and '1' (true). Setting this value to true indicates that 232 anyone can read the attribute without read privileges being 233 assigned. The use of ACL's to restrict the access to this attribute 234 will be ineffective. 236 Valid values for the qdstrings following X-NDS_SERVER_READ are '0' 237 (false) and '1' (true). When this is true, server class objects can 238 read the attribute even though the privilege to read has not been 239 granted. Clients cannot set or modify this value. 241 Valid values for the qdstrings following X-NDS_NEVER_SYNC are '0' 242 (false) and '1' (true). True here, indicates that this attribute is 243 never synchronized on other replicas. Clients may not set or modify 244 this value. 246 Valid values for the qdstrings following 247 X-NDS_NOT_SCHED_SYNC_IMMEDIATE are '0' (false) and '1' (true). By 248 default, any update to an attribute value will cause a replica 249 synchronization session to occur within 10 seconds. If this flag is 250 set to true, updates to this attribute won't immediately initiate a 251 synchronization session, instead, a synchronization session will be 252 initiated within 30 minutes at that time the updates will be 253 replicated to other servers. 255 Valid values for the qdstrings following X-NDS_SCHED_SYNC_NEVER are 256 '0' (false) and '1' (true). If this flag is set to true, updates to 257 this attribute will not cause a synchronization session to be 258 scheduled. Note that this flag does not prevent the attribute from 259 being synchronized like the X-NDS_NEVER_SYNC does. Once a 260 synchronization session is initiated by another process, the updates 261 to this attribute will be replicated. 263 Valid values for the qdstrings following X-NDS_LOWER_BOUND is a 264 quoted uint32string. This represents the lowest value that may be 266 Sermersheim Informational - Expires September 2000 5 267 used in this attribute. LDAP only allows for an upper bound (see the 268 definition of noidlen in RFC 2252) 270 Valid values for the qdstrings following X-NDS_NAME_VALUE_ACCESS are 271 '0' (false) and '1' (true). This is specified only when the 272 attribute uses a Distinguished Name syntax. It specifies (when true) 273 that the subject (user) must have management rights (write 274 permissions on the acl attribute) to the entry which the DN names, 275 that is being added or removed from this attribute. In other words, 276 if this is set on my 'friends' attribute, I can't add your DN to my 277 list of friends unless I have write permissions to your acl 278 attribute. For those familiar with legacy NDS access APIs, this is 279 the "Write Managed" flag and is renamed here for clarity. 281 5. Syntaxes 283 The NDSSyntaxDescription defined here, adds to the 284 SyntaxDescription, which is defined in section 4.3.3 of [RFC2252]. 285 The added terms, which begin with the characters 286 "X-NDS ", exist to describe NDS specific information. 288 Lines have been folded for readability, transmissions of the 289 NDSSyntaxDescription do not contain newlines. The description of 290 whsp, qdescrs, qdstring, woid, numericstring, and noidlen are given 291 in section 4.1 of [RFC2252]. 293 NDSSyntaxDescription = "(" whsp 294 numericoid whsp ; Syntax identifier 295 [ "DESC" qdstring ] ; description 296 [ "X-NDS_SYNTAX" qdstrings ] ; legacy NDS syntax identifier 297 whsp ")" 299 NDS servers MUST, and Clients that wish to operate with NDS servers 300 SHOULD recognize all the syntaxes described in this section. 302 5.1 Case Ignore List 304 ( 2.16.840.1.113719.1.1.5.1.6 DESC 'Case Ignore List' ) 306 This syntax is the same as Postal Address (6.27 of [RFC2252]) except 307 there is no limitation of characters per line, nor number of lines. 308 NDS limits Postal Address to six strings. 310 Values in this syntax are encoded according to the following BNF: 312 caseIgnorelist = dstring *( "$" dstring) 314 Backslashes and dollar characters are escaped as described in 6.27 315 of [RFC2252]. 317 The following ASN.1 data type is used to represent this syntax when 318 transferred in binary form (see 4.1): 320 Sermersheim Informational - Expires September 2000 6 321 caseIgnorelist ::= SEQUENCE OF LDAPString 323 Attributes of this syntax match for equality using 324 caseIgnoreListMatch (2.5.13.11) 326 5.2 Tagged Data 328 ( 2.16.840.1.113719.1.1.5.1.12 DESC 'Tagged Data' ) 330 This is the Net Address syntax in NDS. 332 Values in this syntax are encoded according to the following BNF: 334 taggedData = uint32string "#" octetstring 336 Note that the data portion of the value is represented as an octet 337 string, which may contain non printable characters. 339 The following ASN.1 data type is used to represent this syntax when 340 transferred in binary form (see 4.1): 342 taggedData ::= SEQUENCE { 343 number uint32, 344 data OCTET STRING 345 } 347 Attributes of this syntax match for equality if the number (using 348 integerMatch (2.5.13.14)) and the data matches exactly. 350 5.3 Octet List 352 ( 2.16.840.1.113719.1.1.5.1.13 DESC 'Octet List' ) 354 Used for attributes that are ordered sequences of octet strings. 356 Those familiar with this syntax as it is represented in NDS will 357 note that the length field has been omitted. 359 Because of problems finding a suitable separator character, Values 360 in this syntax may not be transmitted in text form and MUST be 361 transmitted in binary form. 363 The following ASN.1 data type is used to represent this syntax when 364 transferred in binary form (see 4.1): 366 octetList ::= SEQUENCE OF OCTET STRING 368 Attributes of this syntax match for equality if the number of octet 369 strings is the same and each octet string matches. 371 Attributes of this syntax match approximately if at least one octet 373 Sermersheim Informational - Expires September 2000 7 374 string matches. 376 5.4 Tagged String 378 ( 2.16.840.1.113719.1.1.5.1.14 DESC 'Tagged String' ) 380 This is the Email Address syntax in NDS 382 Values in this syntax are encoded according to the following BNF: 384 taggedString = uint32string "#" IA5String 386 The following ASN.1 data type is used to represent this syntax when 387 transferred in binary form (see 4.1): 389 taggedString ::= SEQUENCE { 390 number uint32, 391 string IA5String 392 } 394 Attributes of this syntax match for equality if the number (using 395 integerMatch (2.5.13.14)) and the string (using 396 caseExactStringIA5Match (1.3.6.1.4.1.1466.109.114.1)) matches. 398 5.5 Tagged Name And String 400 ( 2.16.840.1.113719.1.1.5.1.15 DESC 'Tagged Name And String' ) 402 This is the Path syntax in NDS 404 Values in this syntax are encoded according to the following BNF: 406 taggedNameAndString = distinguishedname "#" uint32string "#" dstring 408 Although the '#' character may occur in a string representation of a 409 distinguished name, no additional special quoting is done. 411 The following ASN.1 data type is used to represent this syntax when 412 transferred in binary form (see 4.1): 414 taggedNameAndString ::= SEQUENCE { 415 name LDAPDN, 416 number uint32, 417 string LDAPString 418 } 420 The string represented by the string field is compared for equality 421 using the same rules that CaseExactIA5Match 422 (1.3.6.1.4.1.1466.109.114.1) uses. That is, two Paths match for 423 equality when their lengths and corresponding characters, including 424 case, are identical. 426 Sermersheim Informational - Expires September 2000 8 427 In comparing two values, the following white space (spaces, tabs, 428 etc.) is not significant: 429 Leading spaces (those preceding the first printable character) 430 Trailing spaces (those following the last printable character) 431 Multiple consecutive internal spaces (these are taken as equivalent 432 to a single space character) 434 In searches and comparisons, the string field can specify a presence 435 match by setting the string to "*". 437 5.6 NDS Replica Pointer 439 ( 2.16.840.1.113719.1.1.5.1.16 DESC 'NDS Replica Pointer') 441 Used for attributes whose values represent partition replicas. A 442 value of this syntax is composed of five parts: 444 1. The distinguished name of the server that stores the replica. 445 2. A value describing the capabilities of this copy of the 446 partition: master, secondary, read-only or subordinate reference. 447 3. A value indicating the current state of the replica (new, dying, 448 locked, changing state, splitting, joining, moving). 449 4. A number representing the replica (all replicas of a partition 450 have different numbers that are assigned when the replicas are 451 created). 452 5. A referral containing one or more network addresses that hint at 453 the node at which the server probably resides. Since servers are 454 accessible over different protocols, the server may have an address 455 for each supported protocol. 457 Values in this syntax may not be transmitted in string format. They 458 MUST be transmitted as BER representations of the following ASN.1: 460 ndsReplicaPointer ::= SEQUENCE { 461 serverName LDAPDN, 462 replicaType uint16, 463 replicaState uint16, 464 replicaNumber uint32, 465 replicaAddressHint SEQUENCE OF NetAddress 466 } 468 NetAddress ::= SEQUENCE { 469 transportType uint32, 470 addressValue OCTET STRING 471 } 473 Values for replicaType are: 0=Master, 1=Secondary, 2=Read Only, 474 3=Subordinate Reference. 476 Values for replicaState are: 0=On, 1=New Replica, 2=Dying Replica, 477 3=Locked, 4=Change Replica Type State 0, 5=ChangeReplica Type State 478 1, 6=Transition On, 48=Split State 0, 49=Split State 1, 64=Join 480 Sermersheim Informational - Expires September 2000 9 481 State 0, 65=Join State 1, 66=Join State 2, 80=Move State 0, 81=Move 482 State 1, 82=Move State 2. 484 Values for transportType are: 0=ipx, 1=ip, 2=sdlc, 485 3=tokenringEthernet, 4=osi nsap, 5=appleTalk, 6=netbeui, 7=sockAddr, 486 8=udp, 9=tcp, 10=udp6, 11=tcp6, 12=internal, 13=url 488 Attributes of this syntax match for equality if the servername 489 matches using distinguishedNameMatch (2.5.13.1) 491 5.7 NDS ACL 493 ( 2.16.840.1.113719.1.1.5.1.17 DESC 'NDS ACL') 495 Used for attributes whose values represent ACL entries. An ACL value 496 can protect either an object or an attribute. The protected object 497 is always the one that contains the ACL attribute. 499 Values in this syntax are encoded according to the following BNF: 501 ndsAcl = privileges "#" scope "#" subjectname "#" protectedattrname 503 privileges = uint32string 505 scope = "entry" / "subtree" 507 subjectname = distinguishedname / "[Self]" / "[Creator]" / 508 "[Public]" / "[Inheritance Mask]" / "[Root]" 510 protectedattrname = caseignorestring / "[Entry Rights]" / 511 "[All Attributes Rights]" 513 The privileges field is number that represents the kind of access 514 being granted. Performing a bitwise OR on the numbers that represent 515 the desired access arrives at this number. Below a table is shown 516 which specifies the values: 518 Value Individual Attributes [Entry Rights] 519 ----------------------------------------------------------- 520 1 Compare Attributes Browse Entry 521 2 Read Attributes Add Entry 522 4 Write, Add, Delete Attrs Delete Entry 523 8 Add/Delete Self Rename Entry 524 16 (none) Supervisory 525 32 Supervisory (none) 527 The scope field specifies whether or not the privileges are applied 528 to the target entry (the entry containing the ACL) or the target and 529 its subtree. 531 The subjectname either contains the distinguished name of the entry 532 being granted the privileges, or one of the special values: 534 Sermersheim Informational - Expires September 2000 10 536 [Self] Indicates the user authenticated in the current 537 connection. This can only be used in the Add 538 Entry operation. 539 [Creator] The user who created the object. This can only 540 be used in the Add Entry operation. 541 [Public] Includes all objects in the tree. 542 [Inheritance Mask] Filters or masks the privileges granted to an 543 object. 544 [Root] Denotes the directory tree root object 546 Although the '#' character may occur in a string representation of a 547 distinguished name used in the subjectname, no additional special 548 quoting is done. 550 The protectedattrname either names a specific attribute that the 551 privileges are applied to, or it contains one of the following 552 special values: 554 [Entry Rights] Privileges apply to the entire object, 555 rather than an attribute. 556 [All Attributes Rights] Privileges apply to all attributes of 557 the object. 559 If the protectedattrname neither specifies a valid attribute as 560 defined in the schema, nor one of the special values, an 561 invalidSyntax error will be returned 563 The following ASN.1 data type is used to represent this syntax when 564 transferred in binary form (see 4.1): 566 ndsAcl ::= SEQUENCE { 567 privileges uint32, 568 subjectName LDAPDN, 569 protectedAttrName LDAPString 570 } 572 The special string values for protectedAttrName and subjectName are 573 the same as given in the BNF above. The privileges field is an 574 integer which represents the bit mask as described above. 576 Attributes of this syntax match for equality if all fields match for 577 equality and match approximate if the attribute name and the subject 578 name match, and any privilege bits set in the filter are also set in 579 the target value. 581 5.8 NDS Timestamp 583 ( 2.16.840.1.113719.1.1.5.1.19 DESC 'NDS Timestamp') 585 Used for attributes whose values mark the time when a particular 586 event occurred or will occur. A time stamp value has three 587 components: 589 Sermersheim Informational - Expires September 2000 11 590 1. The wholeseconds value consists of the whole number of seconds, 591 where zero equals 12:00 midnight, January 1, 1970, UTC. 592 2. The replicanum value identifies the server that minted the 593 timestamp. A replica number is assigned whenever a replica is 594 created on a server. 595 3. The event field is an integer that orders events occurring within 596 the same whole-second interval. The event number restarts at one for 597 each new second. 599 The initial value of a time stamp has seconds = 1 and event = 0. 600 Values can be skipped, but MUST NOT be reused. An unknown event is 601 coded as 0xFFFF. 603 Values in this syntax are encoded according to the following BNF: 605 ndsTimestamp = wholeseconds "#" replicanum "#" event 607 wholeseconds = uint32string ; 0 = 12:00 midnight Jan 01 1970, UTC 609 replicanum = uint16string 611 event = uint16string 613 The following ASN.1 data type is used to represent this syntax when 614 transferred in binary form (see 4.1): 616 ndsTimestamp ::= SEQUENCE { 617 wholeSeconds uint32, 618 replicaNum uint16, 619 eventID uint16 620 } 622 Attributes of this syntax match for equality if the wholeSeconds 623 matches and the eventID matches. 625 Attributes of this syntax match for ordering using first the 626 wholeSeconds and then the eventID. 628 5.9 Counter 630 ( 2.16.840.1.113719.1.1.5.1.22 DESC 'Counter') 632 This syntax is the same as Integer (1.3.6.1.4.1.1466.115.121.1.27) 633 except that it has the following special properties: 635 - Attributes using this syntax are implicitly single-valued. 637 - The LDAP modify-add operation will add the passed number to the 638 value of the counter 640 - The LDAP modify-delete operation will subtract the passed number 642 Sermersheim Informational - Expires September 2000 12 643 to the value of the counter. 645 Values in this syntax are encoded in the same manner as the INTEGER 646 syntax. See [RFC2252] section 6.16. For example the value 11667 is 647 represented as the character string "11667" 649 The following ASN.1 data type is used to represent this syntax when 650 transferred in binary form (see 4.1): 652 counter ::= uint32 654 Integer matching rules apply to attributes of this syntax. 656 5.10 Tagged Name 658 ( 2.16.840.1.113719.1.1.5.1.23 DESC 'Tagged Name' ) 660 Holds a distinguished name and a 32 bit unsigned integer. 662 This is the Back Link syntax in NDS. 664 Values in this syntax are encoded according to the following BNF: 666 taggedName = uint32string "#" distinguishedname 668 The following ASN.1 data type is used to represent this syntax when 669 transferred in binary form (see 4.1): 671 taggedName ::= SEQUENCE { 672 name LDAPDN, 673 number uint32 674 } 676 Sermersheim Informational - Expires September 2000 13 677 Attributes of this syntax match for equality when the name matches 678 using distinguishedNameMatch (2.5.13.1) and the number matches. 680 5.11 Typed Name 682 ( 2.16.840.1.113719.1.1.5.1.25 DESC 'Typed Name') 684 Used for attributes whose values represent a level and an interval 685 associated with an object. This syntax names a directory entry and 686 attaches two numeric values to it: 688 1. The level of the attribute indicates the priority. 689 2. The interval indicates the frequency of reference. 691 The objectname value identifies the directory entry referred to by 692 the Typed Name. The values of level and interval are user-assigned 693 and relative. 695 To be effective, the user must implement them. The user can use them 696 to implement iterative intervals or to enforce priorities. 698 Values in this syntax are encoded according to the following BNF: 700 typedname = objectname "#" level "#" interval 702 objectname = distinguishedname 704 level = uint32string 706 interval = uint32string 708 Although the '#' character may occur in a string representation of a 709 distinguished name, no additional special quoting is done. 711 The following ASN.1 data type is used to represent this syntax when 712 transferred in binary form (see 4.1): 714 typedName ::= SEQUENCE { 715 objectName LDAPDN, 716 level uint32, 717 interval uint32 718 } 720 Attributes of this syntax match for equality if the name matches 721 using distinguishedNameMatch (2.5.13.1) and both values match. 723 6 Attribute Types 725 As of this printing, NDS ships with attribute types which are 726 essential to it successfully running. It also ships with attribute 727 types which are non-essential. This document will be updated with a 728 list of those essential attribute types when they are identified. 730 Sermersheim Informational - Expires September 2000 14 731 7. Object Classes 733 As of this printing, NDS ships with object classes which are 734 essential to it successfully running. It also ships with object 735 classes which are non-essential. This document will be updated with 736 a list of those essential object classes when they are identified. 738 8. Matching Rules 740 As of this printing, NDS tightly binds matching rules to syntaxes. 741 See the syntax definitions in section 5 for matching rule 742 explanations. 744 9. Security Considerations 745 While this document discusses the use of security related LDAP 746 attributes and syntaxes, it does not expose or create any security 747 problems which haven't been addressed in other documents. 749 10. Acknowledgements 750 The author would like to thank the generous input and review by 751 individuals at Novell including but not limited to Ed Reed, Renea 752 Campbell, Brian Jarvis, Mark Hinckley, Gary Anderson, Steve McLain, 753 and Judy Wilson. 755 11. Author's Address 756 Jim Sermersheim 757 Novell, Inc. 758 122 East 1700 South 759 Provo, UT 84606 760 USA 761 +1 801 861 3088 763 12. Bibliography 765 [LDAPV3] 766 M. Wahl, S. Kille and T. Howes, "Lightweight Directory Access 767 Protocol (v3)", Internet Standard, December, 1997. Available as 768 RFC2251. 770 [RFC1778] 771 T. Howes, S. Kille, W Yeong, C. Robbins, "The String 772 Representation of Standard Attribute Syntaxes", Internet 773 Standard, March, 1995. Available as RFC1778. 775 [RFC2252] 776 M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 777 Directory Access Protocol (v3): Attribute Syntax Definitions", 778 Internet Standard, December, 1997. Available as RFC2252. 780 [RFC2253] 781 M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access 783 Sermersheim Informational - Expires September 2000 15 784 Protocol (v3): UTF-8 String Representation of Distinguished 785 Names", Internet Standard, December, 1997. Available as 786 RFC2253. 788 [RFC2119] 789 S. Bradner, "Key Words for use in RFCs to Indicate Requirement 790 Levels", Internet Standard, March, 1997. Available as RFC2119. 792 [BYTEORDER] 793 C. Newman, "Network Byte Order" Internet Draft, February, 1999. 794 Available as draft-newman-network-byte-order-01.txt 796 Full Copyright Statement 798 "Copyright (C) The Internet Society 1999. All Rights Reserved. This 799 document and translations of it may be copied and furnished to 800 others, and derivative works that comment on or otherwise explain it 801 or assist in its implementation may be prepared, copied, published 802 and distributed, in whole or in part, without restriction of any 803 kind, provided that the above copyright notice and this paragraph 804 are included on all such copies and derivative works. However, this 805 document itself may not be modified in any way, such as by removing 806 the copyright notice or references to the Internet Society or other 807 Internet organizations, except as needed for the purpose of 808 developing Internet standards in which case the procedures for 809 copyrights defined in the Internet Standards process must be 810 followed, or as required to translate it into. 812 Sermersheim Informational - Expires September 2000 16