idnits 2.17.1 draft-joslin-config-schema-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1686. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1676. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2006) is 6426 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'SASLMECH' is defined on line 1482, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Possible downref: Non-RFC (?) normative reference: ref. 'SASLMECH' -- Obsolete informational reference (is this intentional?): RFC 2831 (Obsoleted by RFC 6331) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission B. Neal-Joslin, Ed. 3 Internet-Draft HP 4 Expires: March 5, 2007 L. Howard 5 PADL 6 M. Ansari 7 Infoblox 8 September 2006 10 A Configuration Profile Schema for LDAP-based agents 11 draft-joslin-config-schema-17.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 5, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document consists of two primary components, a schema for agents 45 that make use of the Lightweight Directory Access protocol (LDAP) and 46 a proposed use case of that schema, for distributed configuration of 47 similar directory user agents. A set of attribute types and an 48 objectclass are proposed. In the proposed use case, directory user 49 agents (DUAs) can use this schema to determine directory data 50 location and access parameters for specific services they support. 51 In addition, in the proposed use case, attribute and objectclass 52 mapping allows DUAs to re-configure their expected (default) schema 53 to match that of the end user's environment. This document is 54 intended to be a skeleton for future documents that describe 55 configuration of specific DUA services. 57 Table of Contents 59 1. Background and Motivation . . . . . . . . . . . . . . . . . . 4 60 2. General Information . . . . . . . . . . . . . . . . . . . . . 6 61 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 6 62 2.2. Attributes Summary . . . . . . . . . . . . . . . . . . . . 6 63 2.3. Object Classes Summary . . . . . . . . . . . . . . . . . . 6 64 2.4. Common Syntax/Encoding Definitions . . . . . . . . . . . . 6 65 3. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1. Attribute Definitions . . . . . . . . . . . . . . . . . . 8 67 3.2. Class Definition . . . . . . . . . . . . . . . . . . . . . 10 68 4. DUA Implementation Details . . . . . . . . . . . . . . . . . . 12 69 4.1. Interpreting the preferredServerList attribute . . . . . . 12 70 4.2. Interpreting the defaultServerList attribute . . . . . . . 13 71 4.3. Interpreting the defaultSearchBase attribute . . . . . . . 14 72 4.4. Interpreting the authenticationMethod attribute . . . . . 15 73 4.5. Interpreting the credentialLevel attribute . . . . . . . . 16 74 4.6. Interpreting the serviceSearchDescriptor attribute . . . . 18 75 4.7. Interpreting the attributeMap attribute . . . . . . . . . 21 76 4.8. Interpreting the searchTimeLimit attribute . . . . . . . . 24 77 4.9. Interpreting the bindTimeLimit attribute . . . . . . . . . 25 78 4.10. Interpreting the followReferrals attribute . . . . . . . . 25 79 4.11. Interpreting the dereferenceAliases attribute . . . . . . 26 80 4.12. Interpreting the profileTTL attribute . . . . . . . . . . 26 81 4.13. Interpreting the objectclassMap attribute . . . . . . . . 27 82 4.14. Interpreting the defaultSearchScope attribute . . . . . . 28 83 4.15. Interpreting the serviceAuthenticationMethod attribute . . 29 84 4.16. Interpreting the serviceCredentialLevel attribute . . . . 29 85 5. Binding to the Directory Server . . . . . . . . . . . . . . . 31 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 89 8.1. Registration of Object Classes . . . . . . . . . . . . . . 34 90 8.2. Registration of Attribute Types . . . . . . . . . . . . . 34 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 36 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 37 94 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 38 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 96 Intellectual Property and Copyright Statements . . . . . . . . . . 42 98 1. Background and Motivation 100 LDAP [RFC4510] has brought about a nearly ubiquitous acceptance of 101 the directory server. Many client applications (DUAs) are being 102 created that use LDAP directories for many different services. And 103 although the LDAP protocol has eased the development of these 104 applications, some challenges still exist for both developers and 105 directory administrators. 107 The authors of this document are implementers of DUAs described by 108 [RFC2307]. In developing these agents, we felt there were several 109 issues that still need to be addressed to ease the deployment and 110 configuration of a large network of these DUAs. 112 One of these challenges stems from the lack of a utopian schema. A 113 utopian schema would be one that every application developer could 114 agree upon and that would support every application. Unfortunately 115 today, many DUAs define their own schema, even when they provide 116 similar services (like RFC 2307 vs. Microsoft's Services for Unix 117 [MSSFU]). These schemas contain similar attributes, but use 118 different attribute names. This can lead to data redundancy within 119 directory entries and cause directory administrators unwanted 120 challenges, updating schemas and synchronizing data. Or, in a more 121 common case, two or more applications may agree on common schema 122 elements, but choose a different schema for other elements of data 123 that might also be shareable between the applications. While data 124 synchronization and translation tools exist, the authors of this 125 document believe there is value in providing this capability in the 126 directory user agent itself. 128 Aside from proposing a schema for general use, one goal of this 129 document is to eliminate data redundancy by having DUAs configure 130 themselves to the schema of the deployed directory, instead of 131 forcing the DUA's own schema on the directory. 133 Another goal of this document is to provide the DUA with enough 134 configuration information so that it can discover how to retrieve its 135 data in the directory, such as what locations to search in the 136 directory tree. 138 Finally, this document intends to describe a configuration method for 139 DUAs that can be shared among many DUAs, on various platforms, 140 providing as such, a configuration profile. The purpose of this 141 profile is to centralize and simplify management of DUAs. 143 This document is intended to provide the skeleton framework for 144 future drafts, which will describe the individual implementation 145 details for the particular services provided by that DUA. The 146 authors of this document plan to develop such a document for the 147 Network Information Service DUA, described by RFC 2307 or its 148 successor. 150 We expect that as DUAs take advantage of this configuration scheme, 151 each DUA will require additional configuration parameters, not 152 specified by this document. Thus, we would expect that new auxiliary 153 object classes, containing new configuration attributes will be 154 created, and then joined with the structural class defined by this 155 document to create a configuration profile for a particular DUA 156 service. And that by joining various auxiliary objectclasses for 157 different DUA services, that configuration of various DUA services 158 can be controlled by a single configuration profile entry. 160 2. General Information 162 The schema defined by this document is defined under the "DUA 163 Configuration Schema." This schema is derived from the OID: iso (1) 164 org (3) dod (6) internet (1) private (4) enterprises (1) Hewlett- 165 Packard Company (11) directory (1) LDAP-UX Integration Project (3) 166 DUA Configuration Schema (1). This OID is represented in this 167 document by the keystring "DUAConfSchemaOID" (1.3.6.1.4.1.11.1.3.1). 169 2.1. Requirements notation 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 2.2. Attributes Summary 177 The following attributes are defined in this document: 179 preferredServerList 180 defaultServerList 181 defaultSearchBase 182 defaultSearchScope 183 authenticationMethod 184 credentialLevel 185 serviceSearchDescriptor 186 serviceCredentialLevel 187 serviceAuthenticationMethod 188 attributeMap 189 objectclassMap 190 searchTimeLimit 191 bindTimeLimit 192 followReferrals 193 dereferenceAliases 194 profileTTL 196 2.3. Object Classes Summary 198 The following object class is defined in this document: 200 DUAConfigProfile 202 2.4. Common Syntax/Encoding Definitions 204 The proposed string encodings used by the attributes defined in this 205 document can be found in Section 4. This document makes use of ABNF 206 [RFC4234] for defining new encodings. 208 The following syntax definitions are used throughout this document. 210 The list of used syntaxes are: 212 +---------------------------+---------------------------------------+ 213 | Key | Source | 214 +---------------------------+---------------------------------------+ 215 | keystring | as defined by [RFC4512] section 1.4 | 216 | | | 217 | descr | as defined by RFC 4512 section 1.4 | 218 | | | 219 | SP | as defined by RFC 4512 section 1.4 | 220 | | | 221 | WSP | as defined by RFC 4512 section 1.4 | 222 | | | 223 | base | as defined by distinguishedName in | 224 | | [RFC4514] | 225 | | | 226 | distinguishedName | as defined by RFC 4514 section 2 | 227 | | | 228 | relativeDistinguishedName | as defined by RFC 4514 section 2 | 229 | | | 230 | scope | as defined by [RFC4516] section 2 | 231 | | | 232 | host | as defined by [RFC3986] section 3.2.2 | 233 | | | 234 | hostport | host [":" port ] | 235 | | | 236 | port | as defined by RFC 3986 section 3.2.3 | 237 | | | 238 | serviceID | same as keystring | 239 +---------------------------+---------------------------------------+ 241 This document does not define new syntaxes that must be supported by 242 the directory server. Instead these syntaxes are merely expected to 243 be interpreted by the the DUA. As referenced in the schema 244 definition in Section 3, most encodings are expected to be stored in 245 attributes using common syntaxes, such as the Directory String 246 syntax, as defined in section 3.3.6 by [RFC4517]. Refer to RFC 4517 247 for additional syntaxes used by this schema. 249 3. Schema Definition 251 This section defines a proposed schema. This schema does not require 252 definition of new matching rules or syntaxes. And it may be used for 253 any purpose seen. A proposed use of this schema to support elements 254 of configuration of a directory user agent are described in 255 Section 4. 257 3.1. Attribute Definitions 259 This section contains attribute definitions used by agents. The 260 syntax used to describe these attributes is defined in [RFC4512], 261 section 4.1.2. Individual syntaxes and matching rules used within 262 these descriptions are described in [RFC4517], sections 3.3 and 4.2 263 respectively. 265 ( 1.3.6.1.4.1.11.1.3.1.1.0 NAME 'defaultServerList' 266 DESC 'List of default servers' 267 EQUALITY caseIgnoreMatch 268 SUBSTR caseIgnoreSubstringsMatch 269 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 270 SINGLE-VALUE ) 272 ( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase' 273 DESC 'Default base for searches' 274 EQUALITY distinguishedNameMatch 275 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 276 SINGLE-VALUE ) 278 ( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' 279 DESC 'List of preferred servers' 280 EQUALITY caseIgnoreMatch 281 SUBSTR caseIgnoreSubstringsMatch 282 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 283 SINGLE-VALUE ) 285 ( 1.3.6.1.4.1.11.1.3.1.1.3 NAME 'searchTimeLimit' 286 DESC 'Maximum time an agent or service allows for a 287 search to complete' 288 EQUALITY integerMatch 289 ORDERING integerOrderingMatch 290 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 291 SINGLE-VALUE ) 293 ( 1.3.6.1.4.1.11.1.3.1.1.4 NAME 'bindTimeLimit' 294 DESC 'Maximum time an agent or service allows for a 295 bind operation to complete' 296 EQUALITY integerMatch 297 ORDERING integerOrderingMatch 298 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 299 SINGLE-VALUE ) 301 ( 1.3.6.1.4.1.11.1.3.1.1.5 NAME 'followReferrals' 302 DESC 'An agent or service does or should follow referrals' 303 EQUALITY booleanMatch 304 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 305 SINGLE-VALUE ) 307 ( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' 308 DESC 'Identifies the types of authentication methods either 309 used, required or provided by a service or peer' 310 EQUALITY caseIgnoreMatch 311 SUBSTR caseIgnoreSubstringsMatch 312 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 313 SINGLE-VALUE ) 315 ( 1.3.6.1.4.1.11.1.3.1.1.7 NAME 'profileTTL' 316 DESC 'Time to live, in seconds, before a profile is 317 considered stale' 318 EQUALITY integerMatch 319 ORDERING integerOrderingMatch 320 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 321 SINGLE-VALUE ) 323 ( 1.3.6.1.4.1.11.1.3.1.1.9 NAME 'attributeMap' 324 DESC 'Attribute mappings used, required or supported by an 325 agent or service' 326 EQUALITY caseIgnoreIA5Match 327 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 329 ( 1.3.6.1.4.1.11.1.3.1.1.10 NAME 'credentialLevel' 330 DESC 'Identifies type of credentials either used, required 331 or supported by an agent or service' 332 EQUALITY caseIgnoreIA5Match 333 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 334 SINGLE-VALUE ) 336 ( 1.3.6.1.4.1.11.1.3.1.1.11 NAME 'objectclassMap' 337 DESC 'Objectclass mappings used, required or supported by 338 an agent or service' 339 EQUALITY caseIgnoreIA5Match 340 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 342 ( 1.3.6.1.4.1.11.1.3.1.1.12 NAME 'defaultSearchScope' 343 DESC 'Default scope used when performing a search' 344 EQUALITY caseIgnoreIA5Match 345 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 346 SINGLE-VALUE ) 348 ( 1.3.6.1.4.1.11.1.3.1.1.13 NAME 'serviceCredentialLevel' 349 DESC 'Specifies the type of credentials either used, required 350 or supported by a specific service' 351 EQUALITY caseIgnoreIA5Match 352 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 354 ( 1.3.6.1.4.1.11.1.3.1.1.14 NAME 'serviceSearchDescriptor' 355 DESC 'Specifies search descriptors required, used or 356 supported by a particular service or agent' 357 EQUALITY caseExactMatch 358 SUBSTR caseExactSubstringsMatch 359 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 361 ( 1.3.6.1.4.1.11.1.3.1.1.15 NAME 'serviceAuthenticationMethod' 362 DESC 'Specifies types authentication methods either 363 used, required or supported by a particular service' 364 EQUALITY caseIgnoreMatch 365 SUBSTR caseIgnoreSubstringsMatch 366 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 368 ( 1.3.6.1.4.1.11.1.3.1.1.16 NAME 'dereferenceAliases' 369 DESC 'Specifies if a service or agent either requires, 370 supports or uses dereferencing of aliases.' 371 EQUALITY booleanMatch 372 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 373 SINGLE-VALUE ) 375 3.2. Class Definition 377 The objectclass below is constructed from the attributes defined in 378 Section 3.1, with the exception of the cn attribute, which is defined 379 in [RFC4519]. cn is used to represent the name of the DUA 380 configuration profile and is recommended for the relative 381 distinguished name (RDN) [RFC4514] naming attribute. This object 382 class is used specifically by the DUA described in Section 4. The 383 syntax used to describe this object class is defined in [RFC4519], 384 section 4.1.1. 386 ( 1.3.6.1.4.1.11.1.3.1.2.5 NAME 'DUAConfigProfile' 387 SUP top STRUCTURAL 388 DESC 'Abstraction of a base configuration for a DUA' 389 MUST ( cn ) 390 MAY ( defaultServerList $ preferredServerList $ 391 defaultSearchBase $ defaultSearchScope $ 392 searchTimeLimit $ bindTimeLimit $ 393 credentialLevel $ authenticationMethod $ 394 followReferrals $ dereferenceAliases $ 395 serviceSearchDescriptor $ serviceCredentialLevel $ 396 serviceAuthenticationMethod $ objectclassMap $ 397 attributeMap $ profileTTL ) ) 399 4. DUA Implementation Details 401 This section describes an implementation of the schema described in 402 Section 3. Details about how a DUA should format and interpret the 403 defined attributes are described below. Agents that make use of the 404 DUAConfigProfile object class are expected to follow the 405 specifications in this section. 407 Note: Many of the subsections in this section contain examples. 408 Unless otherwise specified, these examples are rendered using the 409 LDIF format[RFC2849]. 411 4.1. Interpreting the preferredServerList attribute 413 Interpretation: 415 As described by the syntax, the preferredServerList parameter 416 is a white-space separated list of server addresses and 417 associated port numbers. When the DUA needs to contact a 418 directory server agent (DSA), the DUA MUST first attempt to 419 contact one of the servers listed in the preferredServerList 420 attribute. The DUA MUST contact the DSA specified by the first 421 server address in the list. If that DSA is unavailable, the 422 remaining DSAs MUST be queried in the order provided (left to 423 right) until a connection is established with a DSA. Once a 424 connection with a DSA is established, the DUA SHOULD NOT 425 attempt to establish a connection with the remaining DSAs. The 426 purpose of enumerating multiple DSAs is not for supplemental 427 data, but for high availability of replicated data. This is 428 also the main reason why an LDAP URL[RFC3986] syntax was not 429 selected for this document. 431 If the DUA is unable to contact any of the DSAs specified by 432 the preferredServerList, the defaultServerList attribute MUST 433 be examined, as described in Section 4.2. The servers 434 identified by the preferredServerList MUST be contacted before 435 attempting to contact any of the servers specified by the 436 defaultServerList. 438 Syntax: 440 serverList = hostport *(SP [hostport]) 442 Default Value: 444 The preferredServerList attribute does not have a default 445 value. Instead a DUA MUST examine the defaultServerList 446 attribute. 448 Other attribute notes: 450 This attribute is used in conjunction with the 451 defaultServerList attribute. Please see Section 4.2 for 452 additional implementation notes. Determining how the DUA 453 should query the DSAs also depends on the additional 454 configuration attributes, credentialLevel, 455 serviceCredentialLevel, bindTimeLimit, 456 serviceAuthenticationMethod and authenticationMethod. Please 457 review Section 5 for details on how a DUA should properly bind 458 to a DSA. 460 Example: 462 preferredServerList: 192.168.169.170 ldap1.mycorp.com 463 ldap2:1389 [1080::8:800:200C:417A]:389 465 4.2. Interpreting the defaultServerList attribute 467 Interpretation: 469 The defaultServerList attribute MUST only be examined if the 470 preferredServerList attribute is not provided, or the DUA is 471 unable to establish a connection with any of the DSAs specified 472 by the preferredServerList. 474 If more than one address is provided, the DUA may choose to 475 either accept the order provided, or choose to create its own 476 order, based on what the DUA determines is the "best" order of 477 DSAs to query. For example, the DUA may choose to examine the 478 server list and choose to query the DSAs in order based on the 479 "closest" server or the server with the least amount of "load". 480 Interpretation of the "best" server order is entirely up to the 481 DUA, and not part of this document. 483 Once the order of server addresses is determined, the DUA 484 contacts the DSA specified by the first server address in the 485 list. If that DSA is unavailable, the remaining DSAs SHOULD be 486 queried until an available DSA is found or no more DSAs are 487 available. If a server address or port is invalid, the DUA 488 SHOULD proceed to the next server address as described just 489 above. 491 Syntax: 493 serverList = hostport *(SP [hostport]) 495 Default Value: 497 If a defaultServerList attribute is not provided, the DUA MAY 498 attempt to contact the same DSA that provided the configuration 499 profile entry itself. The default DSA is contacted only if the 500 preferredServerList attribute is also not provided. 502 Other attribute notes: 504 This attribute is used in conjunction with the 505 preferredServerList attribute. Please see Section 4.1 for 506 additional implementation notes. Determining how the DUA 507 should query the DSAs also depends on the additional 508 configuration attributes, credentialLevel, 509 serviceCredentialLevel, bindTimeLimit, 510 serviceAuthenticationMethod and authenticationMethod. Please 511 review Section 5 for details on how a DUA should properly 512 contact a DSA. 514 Example: 516 defaultServerList: 192.168.169.170 ldap1.mycorp.com 517 ldap2:1389 [1080::8:800:200C:417A]:5912 519 4.3. Interpreting the defaultSearchBase attribute 521 Interpretation: 523 When a DUA needs to search the DSA for information, this 524 attribute provides the base for the search. This parameter can 525 be overridden or appended by the serviceSearchDescriptor 526 attribute. See Section 4.6. 528 Syntax: 530 Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [RFC4517] 532 Default Value: 534 There is no default value for the defaultSearchBase. A DUA MAY 535 define its own method for determining the search base, if the 536 defaultSearchBase is not provided. 538 Other attribute notes: 540 This attribute is used in conjunction with the 541 serviceSearchDescriptor attribute. See Section 4.6. 543 Example: 545 defaultSearchBase: dc=mycompany,dc=com 547 4.4. Interpreting the authenticationMethod attribute 549 Interpretation: 551 The authenticationMethod attribute defines an ordered list of 552 LDAP bind methods to be used when attempting to contact a DSA. 553 The serviceAuthenticationMethod overrides this value for a 554 particular service (see Section 4.15.) Each method MUST be 555 attempted in the order provided by the attribute, until a 556 successful LDAP bind is performed ("none" is assumed to always 557 be successful.) However the DUA MAY skip over one or more 558 methods. See Section 5 for more information. 560 none - The DUA does not perform an LDAP bind. 562 simple - The DUA performs an LDAP simple bind. 564 sasl - The DUA performs an LDAP SASL [RFC4422] bind using the 565 specified SASL mechanism and options. 567 tls - The DUA performs an LDAP StartTLS operation followed 568 by the specified bind method (for more information 569 refer to section 4.14 of [RFC4511]). 571 Syntax: 573 authMethod = method *(";" method) 575 method = none / simple / sasl / tls 577 none = "none" 579 simple = "simple" 581 sasl = "sasl/" saslmech [ ":" sasloption ] 583 sasloption = "auth-conf" / "auth-int" 584 tls = "tls:" (none / simple / sasl) 586 saslmech = SASL mechanism name as defined in [SASLMECH] 588 Note: Although multiple authentication methods may be specified 589 in the syntax, at most one of each type is allowed. I.E. 590 "simple;simple" is invalid. 592 Default Value: 594 If the authenticationMethod or serviceAuthenticationMethod (for 595 that particular service) attributes are not provided, the DUA 596 MAY choose to bind to the DSA using any method defined by the 597 DUA. However, if either authenticationMethod or 598 serviceAuthenticationMethod are provided, the DUA MUST only use 599 the methods specified. 601 Other attribute notes: 603 When using TLS, the string "tls:sasl/EXTERNAL" implies that 604 both client and server (DSA and DUA) authentication is to be 605 performed. Any other TLS authentication method implies server- 606 only (DSA side credential) authentication, along with the other 607 SASL method used for DUA-side authentication. 609 Determining how the DUA should bind to the DSAs also depends on 610 the additional configuration attributes, credentialLevel, 611 serviceCredentialLevel, serviceAuthenticationMethod and 612 bindTimeLimit. Please review Section 5 for details on how to 613 properly bind to a DSA. 615 Example: 617 authenticationMethod: tls:simple;sasl/DIGEST-MD5 619 (see [RFC2831]) 621 4.5. Interpreting the credentialLevel attribute 623 Interpretation: 625 The credentialLevel attribute defines what type(s) of 626 credential(s) the DUA MUST use when contacting the DSA. The 627 serviceCredentialLevel overrides this value for a particular 628 service (Section 4.16.) The credentialLevel can contain more 629 than one credential type, separated by white space. 631 anonymous The DUA SHOULD NOT use a credential when binding to 632 the DSA. 634 proxy The DUA SHOULD use a known proxy identity when 635 binding to the DSA. A proxy identity is a specific 636 credential that was created to represent the DUA. 637 This document does not define how the proxy user 638 should be created, or how the DUA should determine 639 what the proxy user's credential is. This 640 functionality is up to each implementation. 642 self When the DUA is acting on behalf of a known identity, 643 the DUA MUST attempt to bind to the DSA as that 644 identity. The DUA should contain methods to 645 determine the identity of the user such that that 646 identity can be authenticated by the directory server 647 using the defined authentication methods. 649 If the credentialLevel contains more than one credential type, 650 the DUA MUST use the credential types in the order specified. 651 However, the DUA MAY skip over one or more credential types. 652 As soon as the DUA is able to successfully bind to the DSA, the 653 DUA SHOULD NOT attempt to bind using the remaining credential 654 types. 656 Syntax: 658 credentialLevel = level *(SP level) 660 level = self / proxy / anonymous 662 self = "self" 664 proxy = "proxy" 666 anonymous = "anonymous" 668 Note: Although multiple credential levels may be specified in 669 the syntax, at most one of each type is allowed. Refer to 670 implementation notes in Section 5 for additional syntax 671 requirements for the credentialLevel attribute. 673 Default Value: 675 If the credentialLevel attribute is not defined, the DUA SHOULD 676 NOT use a credential when binding to the DSA (also known as 677 anonymous.) 679 Other attribute notes: 681 Determining how the DUA should bind to the DSAs also depends on 682 the additional configuration attributes, authenticationMethod, 683 serviceAuthenticationMethod, serviceCredentialLevel and 684 bindTimeLimit. Please review Section 5 for details on how to 685 properly bind to a DSA. 687 Example: 689 credentialLevel: proxy anonymous 691 4.6. Interpreting the serviceSearchDescriptor attribute 693 Interpretation: 695 The serviceSearchDescriptor attribute defines how and where a 696 DUA SHOULD search for information for a particular service. 697 The serviceSearchDescriptor contains a serviceID, followed by 698 one or more base-scope-filter triples. These base-scope-filter 699 triples are used to define searches only for the specific 700 service. Multiple base-scope-filters allow the DUA to search 701 for data in multiple locations in the directory information 702 tree (DIT). Although this syntax is very similar to the LDAP 703 URL[RFC3986], this draft requires the ability to supply 704 multiple hosts as part of the configuration of the DSA. In 705 addition, an ordered list of search descriptors is required, 706 which can not be specified by the LDAP URL. 708 The serviceSearchDescriptor might also contain the DN of an 709 entry that will contain an alternate profile. The DSA SHOULD 710 re-evaluate the alternate profile and perform searches as 711 specified by that profile. 713 If the base, as defined in the serviceSearchDescriptor, is 714 followed by the "," (ASCII 0x2C) character, this base is known 715 as a relative base. This relative base may be constructed of 716 one or more RDN components. In this case, the DUA MUST define 717 the search base by appending the relative base with the 718 defaultSearchBase. 720 Syntax: 722 serviceSearchList = serviceID ":" serviceSearchDesc *(";" 723 serviceSearchDesc) 725 serviceSearchDesc = confReferral / searchDescriptor 727 searchDescriptor = [base] ["?" [scopeSyntax] ["?" [filter]]] 729 confReferral = "ref:" distinguishedName 731 base = distinguishedName / relativeBaseName 733 relativeBaseName = 1*(relativeDistinguishedName ",") 735 filter = UTF-8 encoded string 737 If the confReferral, base, relativeBaseName or filter contains 738 the ";" (ASCII 0x3B) "?" (ASCII 0x3F) """ (ASCII 0x22) or "\" 739 (ASCII 0x5C) characters, those characters MUST be escaped 740 (preceded with the "\" character.) Alternately the DN may be 741 surrounded by quotes (ASCII 0x22.) Refer to RFC 4514. If the 742 confReferral, base, relativeBaseName or filter are surrounded 743 by quotes, only the """ character needs to be escaped. Any 744 character that is preceded by the "\" character, which does not 745 need to be escaped results in both "\" character and the 746 character itself. 748 The usage and syntax of the filter string MUST be defined by 749 the DUA service. A suggested syntax would be that as defined 750 by [RFC4515]. 752 If a DUA is performing a search for a particular service, which 753 has a serviceSearchDescriptor defined, the DUA MUST set the 754 base, scope and filter as defined. Each base-scope-filter 755 triple represents a single LDAP search operation. If multiple 756 base-scope-filter triples are provided in the 757 serviceSearchDescriptor, the DUA SHOULD perform multiple search 758 requests and in that case it MUST be in the order specified by 759 the serviceSearchDescriptor. 761 FYI: Service search descriptors do not exactly follow the LDAP 762 URL syntax [RFC4516]. The reasoning for this difference is to 763 separate the host name(s) from the filter. This allows the DUA 764 to have a more flexible solution in choosing its DSA. 766 Default Value: 768 If a serviceSearchDescriptor, or an element their-of, is not 769 defined for a particular service, the DUA SHOULD create the 770 base, scope and filter as follows: 772 base - Same as the defaultSearchBase. 774 scope - Same as the defaultSearchScope. 776 filter - Use defaults as defined by DUAs service. 778 If the defaultSearchBase or defaultSearchScope are not defined, 779 then the DUA service MAY use its own default. 781 Other attribute notes: 783 If a serviceSearchDescriptor exists for a given service, the 784 service MUST use at least one base-scope-filter triple in 785 performing searches. It SHOULD perform multiple searches per 786 service if multiple base-scope-filter triples are defined for 787 that service. 789 The details of how the "filter" is interpreted by each DUA's 790 service is defined by that service. This means the filter is 791 NOT REQUIRED to be a legal LDAP filter [RFC4515]. Furthermore, 792 determining how attribute and objectclass mapping affects that 793 search filter MUST be defined by the service. I.E. The DUA 794 SHOULD specify if the attributes in the filter have assumed to 795 already have been mapped, or if it is expected that attribute 796 mapping (see Section 4.7) would be applied to the filter. In 797 general practice, implementation and usability suggests that 798 attribute and objectclass mapping (Section 4.7 and 799 Section 4.13) SHOULD NOT be applied to the filter defined in 800 the serviceSearchDescriptor. 802 The serviceID is unique to a given service within the scope of 803 any DUA that might use the given profile, and should be defined 804 by that service. Registration of serviceIDs is not addressed 805 by this document. However, as per the guidance at the end of 806 Section 1, when DUA developers define their use of the 807 DUAConfigProfile schema, they will define the serviceIDs used 808 by that DUA. 810 searchGuide and enhancedSearchGuide ([RFC4517]: 812 There are a few reasons why the authors chose not to take 813 advantage of the existing searchGuide and enhancedSearchGuide 814 attributes and relateded syntaxes. While the 815 enhancedSearchGuide met a number of the serviceSearchDescriptor 816 requirements, serviceSearchDescriptor was developed primarially 817 to support associating search operations with services. And 818 that multiple services could be configured using the same 819 profile. This required specifing the serviceID together with 820 the search descriptor information. A few other reasons for not 821 using enhancedSearchGuide include: 823 The need to specify alternate search bases, including the 824 abiltity to specify search bases that are relative to the 825 parent defaultSearchBase. 827 The need to specify alternate profiles using the "ref:" 828 syntax. 830 The ability for individual services to specify their own 831 syntaxes for the format of the search filter. 833 The author's belief that the user community is more familiar 834 with the search filter syntax described by RFC4515, instead 835 of that described by the enhancedSearchGuide syntax. 837 Example: 839 defaultSearchBase: dc=mycompany,dc=com 841 serviceSearchDescriptor: email:ou=people,ou=org1,? 842 one;ou=contractor,?one; 843 ref:cn=profile,dc=mycompany,dc=com 845 In this example, the DUA MUST search in 846 "ou=people,ou=org1,dc=mycompany,dc=com" first. The DUA then 847 SHOULD search in "ou=contractor,dc=mycompany,dc=com", and 848 finally it SHOULD search other locations as specified in the 849 profile described at "cn=profile,dc=mycompany,dc=com". For 850 more examples, see Appendix A. 852 4.7. Interpreting the attributeMap attribute 854 Interpretation: 856 A DUA SHOULD perform attribute mapping for all LDAP operations 857 performed for a service that has an attributeMap entry. 858 Because attribute mapping is specific to each service within 859 the DUA, a "serviceID" is required as part of the attributeMap 860 syntax. I.E. not all DUA services should necessarily perform 861 the same attribute mapping. 863 Attribute mapping in general is expected be used to map 864 attributes of similar syntaxes as specified by the service 865 supported by the DUA. However, a DUA is NOT REQUIRED to verify 866 syntaxes of mapped attributes. If the DUA does discover that 867 the syntax of the mapped attribute does not match that of the 868 original attribute, the DUA MAY perform translation between the 869 original syntax and the new syntax. When DUAs do support 870 attribute value translation, the method and list of capable 871 translations SHOULD be documented in a description of the DUA 872 service. 874 Syntax: 876 attributeMap = serviceID ":" origAttribute "=" attributes 878 origAttribute = attribute 880 attributes = wattribute *( SP wattribute ) 882 wattribute = WSP newAttribute WSP 884 newAttribute = descr / "*NULL*" 886 attribute = descr 888 Values of the origAttribute are defined by and SHOULD be 889 documented for the DUA service, as a list of known supported 890 attributes. 892 Default Value: 894 By default, attributes that are used by a DUA service are not 895 mapped unless mapped by the attributeMap attributes. The DUA 896 SHOULD NOT map an attribute unless it is explicitly defined by 897 an attributeMap attribute. 899 Other attribute notes: 901 When an attribute is mapped to the special keystring "*NULL*", 902 the DUA SHOULD NOT request that attribute from the DSA, when 903 performing a search or compare request. If the DUA is also 904 capable of performing modification on the DSA, the DUA SHOULD 905 NOT attempt to modify any attribute which has been mapped to 906 "*NULL*". 908 It is assumed the serviceID is unique to a given service within 909 the scope of the DSA. 911 A DUA SHOULD support attribute mapping. If it does, the 912 following additional rules apply: 914 1. The list of attributes that are allowed to be mapped SHOULD 915 defined by and documented for the service. 917 2. Any supported translation of mapping from attributes of 918 dissimilar syntax SHOULD also be defined and documented. 920 3. If an attribute may be mapped to multiple attributes the 921 DSA SHOULD define a syntax or usage statement for how the 922 new attribute value will be constructed. Furthermore, the 923 resulting translated syntax of the combined attributes MUST 924 be the same as the attribute being mapped. 926 4. A DUA MUST support mapping of attributes using the 927 attribute OID. It SHOULD support attribute mapping based 928 on the attribute name. 930 5. It is recommended that attribute mapping not be applied to 931 parents of the target entries. 933 6. Attribute mapping is not recursive. In other words, if an 934 attribute has been mapped to a target attribute, that new 935 target attribute MUST NOT be mapped to a third attribute. 937 7. A given attribute MUST only be mapped once for a given 938 service. 940 Example: 942 Suppose a DUA is acting on behalf of an email service. By 943 default the "email" service uses the "mail", "cn" and "sn" 944 attributes to discover mail addresses. However, the email 945 service has been deployed in an environment that uses 946 "employeeName" instead of "cn." And also instead of using the 947 "mail" attribute for email addresses, the "email" attribute is 948 used for that purpose. In this case, the attribute "cn" can be 949 mapped to "employeeName," allowing the DUA to perform searches 950 using the "employeeName" attribute as part of the search 951 filter, instead of "cn". And "mail" can be mapped to "email" 952 when attempting to retrieve the email address. This mapping is 953 performed by adding the attributeMap attributes to the 954 configuration profile entry as follows (represented in 955 LDIF[RFC2849]): 957 attributeMap: email:cn=employeeName 958 attributeMap: email:mail=email 960 As described above, the DUA MAY also map a single attribute to 961 multiple attributes. When mapping a single attribute to more 962 than one attribute, the new syntax or usage of the mapped 963 attribute must be intrinsically defined by the DUAs service. 965 attributeMap: email:cn=firstName lastName 967 In the above example, the DUA creates the new value by 968 generating space separated string using the values of the 969 mapped attributes. In this case, a special mapping must be 970 defined so that a proper search filter can be created. For 971 further information on this example, please refer to 972 Appendix A. 974 Another possibility for multiple attribute mapping might come 975 in when constructing returned attributes. For example, perhaps 976 all email addresses are of a guaranteed syntax of "uid@domain". 977 And in this example, the uid and domain are separate attributes 978 in the directory. The email service may define that if the 979 "mail" attribute is mapped to two different attributes, it will 980 construct the email address as a concatenation of the two 981 attributes (uid and domain), placing the "@" character between 982 them. 984 attributeMap: email:mail=uid domain 986 4.8. Interpreting the searchTimeLimit attribute 988 Interpretation: 990 The searchTimeLimit attribute defines the maximum time, in 991 seconds, that a DUA SHOULD allow to perform a search request. 993 Syntax: 995 Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. [RFC4517] 997 Default Value: 999 If the searchTimeLimit attribute is not defined or is zero, the 1000 search time limit SHOULD NOT be enforced by the DUA. 1002 Other attribute notes: 1004 This time limit only includes the amount of time required to 1005 perform the LDAP search operation. If other operations are 1006 required, those operations do not need to be considered part of 1007 the search time. See bindTimeLimit for the LDAP bind 1008 operation. 1010 4.9. Interpreting the bindTimeLimit attribute 1012 Interpretation: 1014 The bindTimeLimit attribute defines the maximum time, in 1015 seconds, that a DUA SHOULD allow to perform an LDAP bind 1016 request against each server on the preferredServerList or 1017 defaultServerList. 1019 Syntax: 1021 Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. 1023 Default Value: 1025 If the bindTimeLimit attribute is not defined or is zero, the 1026 bind time limit SHOULD NOT be enforced by the DUA. 1028 Other attribute notes: 1030 This time limit only includes the amount of time required to 1031 perform the LDAP bind operation. If other operations are 1032 required, those operations do not need to be considered part of 1033 the bind time. See searchTimeLimit for the LDAP search 1034 operation. 1036 4.10. Interpreting the followReferrals attribute 1038 Interpretation: 1040 If set to TRUE, the DUA SHOULD follow any referrals if 1041 discovered. 1043 If set to FALSE, the DUA MUST NOT follow referrals. 1045 Syntax: 1047 Defined by OID 1.3.6.1.4.1.1466.115.121.1.7. [RFC4517] 1049 Default Value: 1051 If the followReferrals attribute is not set or set to an 1052 invalid value the default value is TRUE. 1054 4.11. Interpreting the dereferenceAliases attribute 1056 Interpretation: 1058 If set to TRUE, the DUA SHOULD enable alias dereferencing. 1060 If set to FALSE, the DUA MUST NOT enable alias dereferencing. 1062 Syntax: 1064 Defined by OID 1.3.6.1.4.1.1466.115.121.1.7. 1066 Default Value: 1068 If the dereferenceAliases attribute is not set or set to an 1069 invalid value the default value is TRUE. 1071 4.12. Interpreting the profileTTL attribute 1073 Interpretation: 1075 The profileTTL attribute defines how often the DUA SHOULD re- 1076 load and reconfigure itself using the corresponding 1077 configuration profile entry. The value is represented in 1078 seconds. Once a DUA reloads the profile entry, it SHOULD re- 1079 configure itself with the new values. 1081 Syntax: 1083 Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. 1085 Default Value: 1087 If not specified the DUA MAY use its own reconfiguration 1088 policy. 1090 Other attribute notes: 1092 If the profileTTL value is zero, the DUA SHOULD NOT 1093 automatically re-load the configuration profile. 1095 4.13. Interpreting the objectclassMap attribute 1097 Interpretation: 1099 A DUA MAY perform objectclass mapping for all LDAP operations 1100 performed for a service that has an objectclassMap entry. 1101 Because objectclass mapping is specific for each service within 1102 the DUA, a "serviceID" is required as part of the 1103 objectclassMap syntax. I.E. Not all DUA services should 1104 necessarily perform the same objectclass mapping. 1106 Objectclass mapping SHOULD be used in conjunction with 1107 attribute mapping to map the required schema by the service to 1108 an equivalent schema that is available in the directory. 1110 Objectclass mapping may or may not be required by a DUA. 1111 Often, the objectclass attribute is used in search filters. 1112 Section 4.7 recommends that attribute mapping not be applied to 1113 the serviceSearchDescriptor. Thus, if the default 1114 objectclasses are not used in a DUA deployment, typically only 1115 the serviceSearchDescriptor needs to be defined to reflect that 1116 mapping. However, when the service search descriptor is not 1117 provided, and the default search filter for that service 1118 contains the objectclass attribute, that search filter SHOULD 1119 be re-defined by objectclass mapping if defined. If a default 1120 search filter is not used, it SHOULD be re-defined through the 1121 serviceSearchDescriptor. If a serviceSearchDescriptor is 1122 defined for a particular service, it SHOULD NOT be re-mapped by 1123 either the objectclassMap or attributeMap values. 1125 One condition where the objectclassMap SHOULD be used is when 1126 the DUA is providing gateway functionality. In this case, the 1127 DUA is acting on behalf of another service, which may pass in a 1128 search filter itself. In this type of DUA, the DUA may alter 1129 the search filter according to the appropriate attributeMap and 1130 objectclassMap values. And in this case, it is also assumed 1131 that a serviceSearchDescriptor is not defined. 1133 Syntax: 1135 objectclassMap = serviceID ":" origObjectclass "=" 1136 objectclass 1138 origObjectclass = objectclass 1140 objectclass = keystring 1142 Values of the origObjectclass depend on the type of DUA Service 1143 using the objectclass mapping feature. 1145 Default Value: 1147 The DUA MUST NOT remap an objectclass unless it is explicitly 1148 defined by an objectclassMap attribute. 1150 Other attribute notes: 1152 A DUA SHOULD support objectclass mapping. If it does, the DUA 1153 MUST support mapping of objectclasses using the objectclass 1154 OID. It SHOULD support objectclass mapping based on the 1155 objectclass name. 1157 It is assumed the serviceID is unique to a given service within 1158 the scope of the DSA. 1160 Example: 1162 Suppose a DUA is acting on behalf of an email service. By 1163 default the "email" service uses the "mail", "cn" and "sn" 1164 attributes to discover mail addresses in entries created using 1165 inetOrgPerson objectclass[RFC2789]. However, the email service 1166 has been deployed in an environment that uses entries created 1167 using "employee" objectclass. In this case, the attribute "cn" 1168 can be mapped to "employeeName", and "inetOrgPerson" can be 1169 mapped to "employee", allowing the DUA to perform LDAP 1170 operations using the entries that exist in the directory. This 1171 mapping is performed by adding attributeMap and objectclassMap 1172 attributes to the configuration profile entry as follows 1173 (represented in LDIF[RFC2849]): 1175 attributeMap: email:cn=employeeName 1176 objectclassMap: email:inetOrgPerson=employee 1178 4.14. Interpreting the defaultSearchScope attribute 1180 Interpretation: 1182 When a DUA needs to search the DSA for information, this 1183 attribute provides the "scope" for the search. This parameter 1184 can be overridden by the serviceSearchDescriptor attribute. 1185 See Section 4.6. 1187 Syntax: 1189 scopeSyntax = "base" / "one" / "sub" 1191 Default Value: 1193 The default value for the defaultSearchScope SHOULD be defined 1194 by the DUA service. If the default search scope for a service 1195 is not defined then the scope SHOULD be for the DUA to perform 1196 a subtree search. 1198 4.15. Interpreting the serviceAuthenticationMethod attribute 1200 Interpretation: 1202 The serviceAuthenticationMethod attribute defines an ordered 1203 list of LDAP bind methods to be used when attempting to contact 1204 a DSA for a particular service. Interpretation and use of this 1205 attribute is the same as Section 4.4, but specific for each 1206 service. 1208 Syntax: 1210 svAuthMethod = serviceID ":" method *(";" method) 1212 Note: Although multiple authentication methods may be specified 1213 in the syntax, at most one of each type is allowed. 1215 Default Value: 1217 If the serviceAuthenticationMethod attribute is not provided, 1218 the authenticationMethod SHOULD be followed, or its default. 1220 Other attribute notes: 1222 Determining how the DUA should bind to the DSAs also depends on 1223 the additional configuration attributes, credentialLevel, 1224 serviceCredentialLevel and bindTimeLimit. Please review 1225 Section 5 for details on how to properly bind to a DSA. 1227 Example: 1229 serviceAuthenticationMethod: email:tls:simple;sasl/DIGEST-MD5 1231 4.16. Interpreting the serviceCredentialLevel attribute 1232 Interpretation: 1234 The serviceCredentialLevel attribute defines what type(s) of 1235 credential(s) the DUA SHOULD use when contacting the DSA for a 1236 particular service. Interpretation and used of this attribute 1237 are the same as Section 4.5. 1239 Syntax: 1241 svCredentialLevel = serviceID ":" level *(SP level) 1243 Refer to implementation notes in Section 5 for additional 1244 syntax requirements for the credentialLevel attribute. 1246 Note: Although multiple credential levels may be specified in 1247 the syntax, at most one of each type is allowed. 1249 Default Value: 1251 If the serviceCredentialLevel attribute is not defined, the DUA 1252 MUST examine the credentialLevel attribute, or follow its 1253 default if not provided. 1255 Other attribute notes: 1257 Determining how the DUA should bind to the DSAs also depends on 1258 the additional configuration attributes, 1259 serviceAuthenticationMethod, authenticationMethod and 1260 bindTimeLimit. Please review Section 5 for details on how to 1261 properly bind to a DSA. 1263 Example: 1265 serviceCredentialLevel: email:proxy anonymous 1267 5. Binding to the Directory Server 1269 The DUA SHOULD use the following algorithm when binding to the 1270 server: 1272 for (clevel in credLevel) [see note 1] 1273 if (clevel is "anonymous") 1274 for (host in hostnames) [see note 2] 1275 if (server is responding) 1276 return success 1277 return failure 1278 else 1279 for (amethod in authMethod) [see note 3] 1280 if (amethod is none) 1281 for (host in hostnames) 1282 if (server is responding) 1283 return success 1284 return failure 1285 else 1286 for (host in hostnames) 1287 authenticate using amethod and clevel 1288 if (authentication passed) 1289 return success 1290 return failure 1292 Note 1: The credLevel is a list of credential levels as defined in 1293 serviceCredentialLevel (Section 4.16) for a given service. 1294 If the serviceCredentialLevel is not defined, the DUA MUST 1295 examine the credentialLevel attribute. 1297 Note 2: hostnames is the list of servers to contact as defined in 1298 Section 4.1 and Section 4.2. 1300 Note 3: The authMethod is a list of authentication methods as 1301 defined in serviceAuthenticationMethod (Section 4.15) for a 1302 given service. If the serviceAuthenticationMethod is not 1303 defined, the DUA MUST examine the authenticationMethod 1304 attribute. 1306 6. Security Considerations 1308 The profile entries MUST be protected against unauthorized 1309 modification. Each service needs to consider implications of 1310 providing its service configuration as part of this profile and limit 1311 access to the profile entries accordingly. 1313 The management of the authentication credentials for the DUA is 1314 outside the scope of this document and needs to be handled by the 1315 DUA. 1317 Since the DUA needs to know how to properly bind to the directory 1318 server, the access control configuration of the DSA MUST assure that 1319 the DSA can view all the elements of the DUAConfigProfile attributes. 1320 For example, if the credentialLevel attribute contains "Self" but the 1321 DSA is unable to access the credentialLevel attribute, the DUA will 1322 instead attempt an anonymous connection to the directory server. 1324 The algorithm described by Section 5 also has security 1325 considerations. Altering that design will alter the security aspects 1326 of the configuration profile. 1328 When DUAs connect to multiple directory servers it is for the purpose 1329 to support potential high-availability and/or performance 1330 requirements. As such, each directory server specified in the 1331 preferredServer list and defaultServerList MUST contain the same 1332 (replicated) data and be part of the same security domain. This 1333 means the directory supported authentication methods, authentication 1334 polices and directory data access control policies are exactly the 1335 same across all the defined directory servers. 1337 7. Acknowledgments 1339 There were several additional authors of this document. However we 1340 chose to represent only one author per company in the heading. From 1341 Sun we also would like to acknowledge Roberto Tam for his design work 1342 on Sun's first LDAP name service product and his input for this 1343 document. From Hewlett-Packard we'd like to acknowledge Dave Binder 1344 for his work architecting Hewlett-Packard's LDAP name service product 1345 as well as his design guidance on this document. We'd also like to 1346 acknowledge Grace Lu from HP, for her input and implementation of 1347 HP's configuration profile manager code. 1349 8. IANA Considerations 1351 This document defines new LDAP attributes and objectclass for object 1352 identifier descriptors. As specified by section 3.4 and required by 1353 section 4 of [RFC4520] this document registers new descriptors as 1354 follows per the Expert Review. 1356 8.1. Registration of Object Classes 1358 Subject: Request for LDAP Descriptor Registration 1360 Descriptor (short name): DUAConfigProfile 1362 Object Identifier: 1.3.6.1.4.1.11.1.3.1.2.5 1364 Person & email address to contact for further information: 1365 See "Author/Change Controller" 1367 Usage: object class 1369 Specification: draft-joslin-config-schema-17.txt 1371 Author/Change Controller: 1373 Bob Neal-Joslin 1374 Hewlett-Packard Company 1375 19420 Homestead RD 1376 Cupertino, CA 95014 1377 USA 1378 Phone: +1 408-447-3044 1379 EMail: bob_joslin@hp.com 1381 Comments: 1383 See also associated request for the defaultServerList, 1384 defaultSearchBase, preferredServerList, searchTimeLimit, 1385 bindTimeLimit, followReferrals, authenticationMethod, 1386 profileTTL, attributeMap, credentialLevel, objectclassMap, 1387 defaultSearchScope, serviceCredentialLevel, 1388 serviceSearchDescriptor, serviceAuthenticationMethod and 1389 dereferenceAliases attribute types. 1391 8.2. Registration of Attribute Types 1393 Subject: Request for LDAP Descriptor Registration 1394 Descriptor (short name): See comments 1396 Object Identifier: See comments 1398 Person & email address to contact for further information: 1399 See "Author/Change Controller" 1401 Usage: attribute type 1403 Specification: draft-joslin-config-schema-17.txt 1405 Author/Change Controller: 1407 Bob Neal-Joslin 1408 Hewlett-Packard Company 1409 19420 Homestead RD 1410 Cupertino, CA 95014 1411 USA 1412 Phone: +1 408-447-3044 1413 EMail: bob_joslin@hp.com 1415 Comments: 1417 The following object identifiers and associated attribute 1418 types are being registered. 1420 OID Attribute Type 1421 -------------------------- --------------------------- 1422 1.3.6.1.4.1.11.1.3.1.1.0 defaultServerList 1423 1.3.6.1.4.1.11.1.3.1.1.1 defaultSearchBase 1424 1.3.6.1.4.1.11.1.3.1.1.2 preferredServerList 1425 1.3.6.1.4.1.11.1.3.1.1.3 searchTimeLimit 1426 1.3.6.1.4.1.11.1.3.1.1.4 bindTimeLimit 1427 1.3.6.1.4.1.11.1.3.1.1.5 followReferrals 1428 1.3.6.1.4.1.11.1.3.1.1.6 authenticationMethod 1429 1.3.6.1.4.1.11.1.3.1.1.7 profileTTL 1430 1.3.6.1.4.1.11.1.3.1.1.9 attributeMap 1431 1.3.6.1.4.1.11.1.3.1.1.10 credentialLevel 1432 1.3.6.1.4.1.11.1.3.1.1.11 objectclassMap 1433 1.3.6.1.4.1.11.1.3.1.1.12 defaultSearchScope 1434 1.3.6.1.4.1.11.1.3.1.1.13 serviceCredentialLevel 1435 1.3.6.1.4.1.11.1.3.1.1.14 serviceSearchDescriptor 1436 1.3.6.1.4.1.11.1.3.1.1.15 serviceAuthenticationMethod 1437 1.3.6.1.4.1.11.1.3.1.1.16 dereferenceAliases 1439 Please also see associated registration request for the 1440 DUAConfigProfile object class. 1442 9. References 1444 9.1. Normative References 1446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1447 Requirement Levels", BCP 14, RFC 2119, March 1997. 1449 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1450 Resource Identifier (URI): Generic Syntax", STD 66, 1451 RFC 3986, January 2005. 1453 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1454 Specifications: ABNF", RFC 4234, October 2005. 1456 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 1457 (LDAP): Technical Specification Road Map", RFC 4510, 1458 June 2006. 1460 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 1461 (LDAP): The Protocol", RFC 4511, June 2006. 1463 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 1464 (LDAP): Directory Information Models", RFC 4512, 1465 June 2006. 1467 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 1468 (LDAP): String Representation of Distinguished Names", 1469 RFC 4514, June 2006. 1471 [RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access 1472 Protocol (LDAP): Uniform Resource Locator", RFC 4516, 1473 June 2006. 1475 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 1476 Syntaxes and Matching Rules", RFC 4517, June 2006. 1478 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 1479 (LDAP): Schema for User Applications", RFC 4519, 1480 June 2006. 1482 [SASLMECH] 1483 Internet Assigned Numbers Authority, "SIMPLE 1484 AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS, 1485 http://www.iana.org/assignments/sasl-mechanisms", 1486 July 2006. 1488 9.2. Informative References 1490 [MSSFU] Microsoft Corporation, "Windows Services for Unix 3.5, 1491 http://www.microsoft.com/windows/sfu/default.asp". 1493 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 1494 Information Service", RFC 2307, March 1998. 1496 [RFC2789] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 2789, 1497 March 2000. 1499 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 1500 SASL Mechanism", RFC 2831, May 2000. 1502 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 1503 Technical Specification", RFC 2849, June 2000. 1505 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1506 Security Layer (SASL)", RFC 4422, June 2006. 1508 [RFC4515] Smith, M. and T. Howes, "Lightweight Directory Access 1509 Protocol (LDAP): String Representation of Search Filters", 1510 RFC 4515, June 2006. 1512 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 1513 Considerations for the Lightweight Directory Access 1514 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 1516 Appendix A. Examples 1518 In this section we will describe a fictional DUA which provides one 1519 service, called the "email" service. This service would be similar 1520 to an email client that uses an LDAP directory to discover email 1521 addresses based on a textual representation of the recipient's 1522 colloquial name. 1524 This email service is defined by default to expect that users with 1525 email addresses will be of the "inetOrgPerson" objectclass type 1526 [RFC2789]. And by default, the "email" service expects the 1527 colloquial name to be stored in the "cn" attribute, while it expects 1528 the email address to be stored in the "mail" attribute (as one would 1529 expect as defined by the inetOrgPerson objectclass.) 1531 As a special feature, the "email" service will perform a special type 1532 of attribute mapping, when performing searches. If the "cn" 1533 attribute has been mapped to two or more attributes, the "email" 1534 service will parse the requested search string and map each white- 1535 space separated token into the mapped attributes, respectively. 1537 The default search filter for the "email" service is 1538 "(objectclass=inetOrgPerson)". The email service also defines that 1539 when it performs a name to address discovery, it will wrap the search 1540 filter inside a complex search filter as follows: 1542 (&()(cn~=) 1544 or if "cn" has been mapped to multiple attributes, that wrapping 1545 would appear as follows: 1547 (&()(attr1~=)(attr2~=)...) 1549 The below examples show how the "email" service builds it search 1550 requests, based on the defined profile. In all cases, the 1551 defaultSearchBase is "o=airius.com" and the defaultSearchScope is 1552 undefined. 1554 In addition, for all examples, we assume that the "email" service has 1555 been requested to discover the email address for "Jane Hernandez." 1556 Example 1: 1558 serviceSearchDescriptor: email:"ou=marketing," 1560 base: ou=marketing,o=airius.com 1561 scope: sub 1562 filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez)) 1564 Example 2: 1566 serviceSearchDescriptor: email:"ou=marketing,"?one? 1567 (&(objectclass=inetOrgPerson)(c=us)) 1568 attributeMap: email:cn=2.5.4.42 sn 1570 Note: 2.5.4.42 is the OID that represents the "givenName" 1571 attribute. 1573 In this example, the email service performs parsing as 1574 described above to generate a complex search filter. The above 1575 example results in one search. 1577 base: ou=marketing,o=airius.com 1578 scope: one 1579 filter: (&(&(objectclass=inetOrgPerson)(c=us)) 1580 (2.5.4.42~=Jane)(sn~=Hernandez)) 1582 Example 3: 1584 serviceSearchDescriptor: email:ou=marketing,"?base 1585 attributeMap: email:cn=name 1587 This example is invalid, because either the quote should have been 1588 escaped, or there should have been a leading quote. 1590 Example 4: 1592 serviceSearchDescriptor: email:ou=\\mar\\\\keting,\\"?base 1593 attributeMap: email:cn=name 1595 base: ou=\\mar\\keting," 1596 scope: base 1597 filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez)) 1599 Example 5: 1601 serviceSearchDescriptor: email:ou="marketing",o=supercom 1602 This example is invalid, since the quote was not a leading quote, and 1603 thus should have been escaped. 1605 Example 6: 1607 serviceSearchDescriptor: email:??(&(objectclass=person) 1608 (ou=Org1 \\\\(temporary\\\\))) 1610 base: o=airius.com 1611 scope: sub 1612 filter: (&((&(objectclass=person)(ou=Org1 \\(Temporary\\))) 1613 (cn~=Jane Henderson))) 1615 Example 7: 1617 serviceSearchDescriptor: email:"ou=funny?org," 1619 base: ou=funny?org,o=airius.com 1620 scope: sub 1621 filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez)) 1623 Authors' Addresses 1625 Bob Neal-Joslin (editor) 1626 Hewlett-Packard Company 1627 19420 Homestead RD 1628 M/S 4029 1629 Cupertino, CA 95014 1630 US 1632 Phone: +1 408 447 3044 1633 Email: bob_joslin@hp.com 1634 URI: http://www.hp.com 1636 Luke Howard 1637 PADL Software Pty. Ltd. 1638 PO Box 59 1639 Central Park, Vic 3145 1640 AU 1642 Email: lukeh@padl.com 1643 URI: http://www.padl.com 1645 Morteza Ansari 1646 Infoblox 1647 475 Potrero Avenue 1648 Sunnyvale, CA 94085 1649 US 1651 Phone: +1 408 716 4300 1652 Email: morteza@infoblox.com 1654 Intellectual Property Statement 1656 The IETF takes no position regarding the validity or scope of any 1657 Intellectual Property Rights or other rights that might be claimed to 1658 pertain to the implementation or use of the technology described in 1659 this document or the extent to which any license under such rights 1660 might or might not be available; nor does it represent that it has 1661 made any independent effort to identify any such rights. Information 1662 on the procedures with respect to rights in RFC documents can be 1663 found in BCP 78 and BCP 79. 1665 Copies of IPR disclosures made to the IETF Secretariat and any 1666 assurances of licenses to be made available, or the result of an 1667 attempt made to obtain a general license or permission for the use of 1668 such proprietary rights by implementers or users of this 1669 specification can be obtained from the IETF on-line IPR repository at 1670 http://www.ietf.org/ipr. 1672 The IETF invites any interested party to bring to its attention any 1673 copyrights, patents or patent applications, or other proprietary 1674 rights that may cover technology that may be required to implement 1675 this standard. Please address the information to the IETF at 1676 ietf-ipr@ietf.org. 1678 Disclaimer of Validity 1680 This document and the information contained herein are provided on an 1681 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1682 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1683 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1684 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1685 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1686 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1688 Copyright Statement 1690 Copyright (C) The Internet Society (2006). This document is subject 1691 to the rights, licenses and restrictions contained in BCP 78, and 1692 except as set forth therein, the authors retain all their rights. 1694 Acknowledgment 1696 Funding for the RFC Editor function is currently provided by the 1697 Internet Society.