Application Working Group M. Ansari INTERNET-DRAFT Sun Microsystems, Inc. Expires June 2001 L. Howard PADL Software Pty. Ltd. B. Joslin [ed.] Hewlett-Packard Company November 17, 2000 Intended Category: Informational A Configuration Schema for LDAP Based Directory User Agents Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Abstract ABSTRACT Joslin [Page 1] Internet-Draft DUA Configuration Schema November 2000 This document describes a mechanism for global confi- guration of similar directory user agents. This docu- ment proposes a schema for configuration of these DUAs that may be discovered using the Lightweight Directory Access Protocol [RFC2251]. A set of attribute types and an objectclass are proposed, along with specific guide- lines for interpreting them. A significant feature of the global configuration policy for DUAs, is a mechan- ism that allows DUAs to re-configure their schema to that of the end user's environment. This configuration is achieved through attribute and objectclass mapping. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. 1. Background & Motivation The LDAP protocol has brought about a new and nearly ubiquitous acceptance of the directory server. Many new client applications (DUAs) are being created that use LDAP directories for many dif- ferent services. And although the LDAP protocol has eased the development of these applications, some challenges still exist for both developers and directory administrators. The authors of this document are implementors of DUAs described by RFC 2307 [14]. In developing these agents, we felt there are several issues that still need to be addressed to ease the deploy- ment and configuration of a large network of these DUAs. One of these challenges stems from the lack of a utopian schema. A utopian schema would be one that every application developer could agree upon and that would support every application. Unfortunately today, many DUAs define their own schema (like RFC 2307 vs Microsoft's Services for Unix [13]) containing similar attributes, but with different attribute names. This can lead to data redun- dancy within directory entries and give directory administrators unwanted challenges, updating schemas and synchronizing data. So, one goal of this document is to eliminate data redundancy by having DUAs configure themselves to the schema of the deployed directory, instead of forcing it's own schema on the directory. Another goal of this document is to provide the DUA with enough configuration information so that it can discover how to retrieve its data in the directory, such as what locations to search in the directory tree. Joslin [Page 2] Internet-Draft DUA Configuration Schema November 2000 Finally, this document intends to describe a configuration method for DUAs that can be shared among many DUAs, on various platforms, providing as such, a configuration profile. The purpose being to centralize and simplify management of DUAs. This document is intended to provide the skeleton framework for future drafts, which will describe the individual implementation details for the particular services provided by that DUA. The authors of this draft plan to develop such an document for the Net- work Information Service DUA, described by RFC 2307 or it's succes- sor. We expect that as DUAs take advantage of this configuration scheme, each DUA will require additional configuration paramenters, not specified by this draft. Thus, we would expect that new auxiliary object classes, containing new configuration attributes will be created, and then joined with the structural class defined by this draft to create a configuration profile for a particular DUA ser- vice. And that by joining various auxiliary objectclasses for dif- ferent DUA services, that configuration of various DUA services can be controlled by a single configuration profile entry. 2. General Issues The schema defined by this draft is defined under the "DUA Confi- guration Schema." This schema is derived from the OID: iso (1) org (3) dod (6) internet (1) private (4) enterprises (1) Hewlett- Packard Company (11) directory (1) LDAP-UX Integration Project (3) DUA Configuration Schema (1). This OID is represented in this draft by the keystring "DUAConfSchemaOID" (1.3.6.1.4.1.11.1.3.1). 2.1 Terminology The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [RFC2119]. 2.2 Attributes The attributes and classes defined in this document are summarized below. The following attributes are defined in this document: preferredServerList defaultServerList defaultSearchBase defaultSearchScope Joslin [Page 3] Internet-Draft DUA Configuration Schema November 2000 authenticationMethod credentialLevel serviceSearchDescriptor attributeMap objectclassMap searchTimeLimit bindTimeLimit followReferrals profileTTL 2.3 Object Classes The following object class is defined in this document: DUAConfigProfile 2.4 Syntax Definitions The following syntax definitions are used throughout this draft. keystring as defined by RFC 2252 [2] descr as defined by RFC 2252 section 4.1 a as defined by RFC 2252 section 4.1 d as defined by RFC 2252 section 4.1 space as defined by RFC 2252 section 4.1 whsp as defined by RFC 2252 section 4.1 base as defined by RFC 2253 [3] DistinguishedName as defined by RFC 2253 section 2 RelativeDistinguishedName as defined by RFC 2253 section 2 scope as defined by RFC 2255 [5] IPv4address as defined by RFC 2396 [9] hostport as defined by RFC 2396 section 3.2.2 port as defined by RFC 2396 section 3.2.2 ipv6reference as defined by RFC 2732 [10] host as defined by RFC 2732 section 3 serviceId = keystring The following additional syntax definitions are defined in this schema. 2.4.1 serviceSearchSyntax The serviceSearchSyntax describes a structure used to help DUA ser- vices discover information in the directory. ( DUAConfSchemaOID.0.8 NAME 'serviceSearchSyntax' DESC 'DUA service search descriptor list syntax' ) Joslin [Page 4] Internet-Draft DUA Configuration Schema November 2000 Values in this syntax are represented by the following: serviceSearchList = serviceId ":" serviceSearchDesc *(";" serviceSearchDesc) serviceSearchDesc = confReferral | searchDescriptor searchDescriptor = [base] ["?" [scope] ["?" [filter]]] confReferral = "ref:" DistinguishedName base = DistinguishedName | RelativeDistinguishedName "," filter = 1*filterc filterc = a | d | "&" | "|" | "!" | "=" | ">" | "<" | "~" | "(" | ")" | "*" | ":" If the base or filter contains the ";" (ASCII 0x3B) "?" (ASCII 0x3F) """ (ASCII 0x22) or " escaped (preceded with the " sur- rounded by quotes (ASCII 0x22.) Refer to RFC 2253, section 4. If the DN is surrounded by quotes, only the """ character must be escaped. Any character that is preceded by the " need to be escaped results in both " itself. 2.4.2 serverListSyntax The serverListSyntax represents the list of DSAs that will be con- tacted to retrieve DUA service data. ( DUAConfSchemaOID.0.1 NAME 'serverListSyntax' DESC 'DSA host address list to be used by a Posix DUA' ) serverList = host *(space [host]) 2.4.3 attributeMappingSyntax The attributeMappingSyntax represents a mapping from an attribute defined by a DUA to an attribute in an alternative schema used in the directory. ( DUAConfSchemaOID.0.2 NAME 'attributeMappingSyntax' DESC 'DUA attribute mapping syntax' ) Values in this syntax are represented by the following: attributeMap = serviceId ":" origAttribute "=" attributes origAttribute = attribute attributes = wattribute *( space wattribute ) wattribute = whsp newAttribute whsp Joslin [Page 5] Internet-Draft DUA Configuration Schema November 2000 newAttribute = descr | "*NULL*" attribute = descr Values of the origAttribute depend on the type of application using the attribute mapping feature. 2.4.4 ObjectClassMappingSyntax The ObjectClassMappingSyntax represents a mapping from an objectclass defined by a DUA to an objectclass in an alternative schema used in the directory. ( DUAConfSchemaOID.0.6 NAME 'ObjectclassMappingSyntax' DESC 'DUA objectclass mapping syntax' ) Values in this syntax are represented by the following: objectclassMap = serviceId ":" origObjectclass "=" objectclass origObjectclass = objectclass objectclass = keystring Values of the origObjectclass depend on the type of applica- tion using the objectclass mapping feature. 2.4.5 authenticationMethodSyntax The authenticationMethodSyntax represents required authentication method a DUA MUST use when authenticating to the DUA. ( DUAConfSchemaOID.0.3 NAME 'authenticationMethodSyntax' DESC 'DUA authentication method hint' ) Values in this syntax are represented by the following: authMethod = method *(";" method) method = none | simple | sasl | tls none = "none" simple = "simple" sasl = "sasl/" saslmech [ ":" sasloption ] sasloption = "auth-conf" | "auth-int" tls = "tls:" (none | simple | sasl) saslmech = SASL mechanism name as defined in RFC 2222, section 3 Note: Although multiple authentication methods may be Joslin [Page 6] Internet-Draft DUA Configuration Schema November 2000 specified in the syntax, at most one of each type is allowed. 2.4.6 credentialLevelSyntax The credentialLevelSyntax identifies the type of credentials that should be used when an DUA is authenticating to an LDAP directory. ( DUAConfSchemaOID.0.5 NAME 'credentialLevelSyntax' DESC 'DUA authentication credential level' ) Values in this syntax are represented by the following: credentialLevel = level *(space level) level = self | proxy | anonymous self = "self" proxy = "proxy" anonymous = "anonymous" Refer to implementation notes in section 5.2 for additional syntax requirements for the credentialLevel attribute. 2.4.7 scopeSyntax The scopeSyntax defines the default scope for LDAP searches per- formed by the DUA. ( DUAConfSchemaOID.0.7 NAME 'scopeSyntax' DESC 'Default DUA search scope' ) Values in this syntax are represented by the following: scopeSyntax = "base" | "one" | "sub" Refer to implementation notes in section 5.2 for additional syntax requirements for the credentialLevel attribute. 3. Attribute Definitions This section contains attribute definitions to be used by DUAs when discovering their configuration. ( DUAConfSchemaOID.1.0 NAME 'defaultServerList' DESC 'Default LDAP server host address used by a DUA' EQUALITY caseIgnoreIA5Match SYNTAX DUAConfSchemaOID.0.1 Joslin [Page 7] Internet-Draft DUA Configuration Schema November 2000 SINGLE-VALUE ) ( DUAConfSchemaOID.1.1 NAME 'defaultSearchBase' DESC 'Default LDAP base DN used by a DUA' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) ( DUAConfSchemaOID.1.2 NAME 'preferredServerList' DESC 'Preferred LDAP server host addresses to be used by a DUA' EQUALITY caseIgnoreIA5Match SYNTAX DUAConfSchemaOID.0.1 SINGLE-VALUE ) ( DUAConfSchemaOID.1.3 NAME 'searchTimeLimit' DESC 'Maximum time in seconds a DUA should allow for a search to complete' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( DUAConfSchemaOID.1.4 NAME 'bindTimeLimit' DESC 'Maximum time in seconds a DUA should allow for the bind operation to complete' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( DUAConfSchemaOID.1.5 NAME 'followReferrals' DESC 'Tells DUA if it should follow referrals returned by a DSA search result' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) ( DUAConfSchemaOID.1.6 NAME 'authenticationMethod' DESC 'A keystring which identifies the type of authentication method used to contact the DSA' EQUALITY caseIgnoreIA5Match SYNTAX DUAConfSchemaOID.0.3 SINGLE-VALUE ) ( DUAConfSchemaOID.1.7 NAME 'profileTTL' DESC 'Time to live before a client DUA should re-read this configuration profile' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 Joslin [Page 8] Internet-Draft DUA Configuration Schema November 2000 SINGLE-VALUE ) ( DUAConfSchemaOID.1.14 NAME 'serviceSearchDescriptor' DESC 'LDAP search descriptor list used by Naming-DUA' EQUALITY caseExactIA5Match SYNTAX DUAConfSchemaOID.0.8 ) ( DUAConfSchemaOID.1.9 NAME 'attributeMap' DESC 'Attribute mappings used by a Naming-DUA' EQUALITY caseIgnoreIA5Match SYNTAX DUAConfSchemaOID.0.2 ) ( DUAConfSchemaOID.1.10 NAME 'credentialLevel' DESC 'Identifies type of credentials a DUA should use when binding to the LDAP server' EQUALITY caseIgnoreIA5Match SYNTAX DUAConfSchemaOID.0.5 SINGLE-VALUE ) ( DUAConfSchemaOID.1.11 NAME 'objectclassMap' DESC 'Objectclass mappings used by a Naming-DUA' EQUALITY caseIgnoreIA5Match SYNTAX DUAConfSchemaOID.0.6 ) ( DUAConfSchemaOID.1.12 NAME 'defaultSearchScope' DESC 'Default search scope used by a DUA' EQUALITY caseIgnoreIA5Match SYNTAX DUAConfSchemaOID.0.7 SINGLE-VALUE ) 4. Class Definition The objectclass below is constructed from the attributes defined in 3, with the exception of the cn attribute, which is defined in RFC 2256 [8]. cn is used to represent the name of the DUA configura- tion profile. ( DUAConfSchemaOID.2.3 NAME 'DUAConfigProfile' SUP top STRUCTURAL DESC 'Abstraction of a base configuration for a DUA' MUST ( cn ) MAY ( defaultServerList $ preferredServerList $ defaultSearchBase $ defaultSearchScope $ searchTimeLimit $ bindTimeLimit $ credentialLevel $ authenticationMethod $ followReferrals $ serviceSearchDescriptor $ objectclassMap $ attributeMap $ Joslin [Page 9] Internet-Draft DUA Configuration Schema November 2000 profileTTL ) ) 5. Implementation Details 5.1.1 Interpreting the preferredServerList attribute Interpretation: As described by the syntax, the preferredServerList parameter is a white-space separated list of server addresses and asso- ciated port numbers. When the DUA needs to contact a DSA, the DUA MUST first attempt to contact one of the servers listed in the preferredServerList attribute. The DUA should contact the DSA specified by the first server address in the list. If that DSA is unavailable, the remaining DSAs should be queried in the order provided until a connection is established with a DSA. Once a connection with a DSA is established, the DUA SHOULD NOT attempt to establish a connection with the remain- ing DSAs. If the DUA is unable to contact any of the DSAs specified by the preferredServerList, the defaultServerList attribute should be examined, as described in 5.1.2. The servers iden- tified by the preferredServerList MUST be contacted before attempting to contact any of the servers specified by the defaultServerList. Default Value: The preferredServerList attribute does not have a default value. Instead a DUA should examine the defaultServerList attribute. Other attribute notes: This attribute is used in conjunction with the defaultServer- List attribute. Please see section 5.1.2 for additional implementation notes. Determining how the DUA should query the DSAs also depends on the additional configuration attri- butes, credentialLevel, bindTimeLimit, and authentication- Method. Please review section 5.2 for details on how a Posix DUA should properly bind to a DSA. 5.1.2 Interpreting the defaultServerList attribute Interpretation: Joslin [Page 10] Internet-Draft DUA Configuration Schema November 2000 The defaultServerList attribute MUST only be examined if the preferredServerList attribute is not provided, or the DUA is unable to establish a connection with one of the DSAs speci- fied by the preferredServerList. If more than one address is provided, the DUA may choose to either accept the order provided, or choose to create its own order, based on what the DUA determines is the "best" order of servers to query. For example, the DUA may choose to examine the server list and choose to query the DSAs in order based on the "closest" server or the server with the least amount of "load." Interpretation of the "best" server order is entirely up to the DUA, and not part of this draft. Once the order of server addresses is determined, the DUA should contact the DSA specified by the first server address in the list. If that DSA is unavailable, the remaining DSAs should be queried until an available DSA is found or no more DSAs are available. If a server address or port is invalid, the DUA should proceed to the next server address as described just above. Default Value: If a defaultServerList attribute is not provided, the DUA should attempt to contact the same DSA which provided the con- figuration profile entry itself. The default DSA is contacted only if the preferredServerList attribute is also not pro- vided. Other attribute notes: This attribute is used in conjunction with the preferredSer- verList attribute. Please see section 5.1.1 for additional implementation notes. Determining how the DUA should query the DSAs also depends on the additional configuration attri- butes, credentialLevel, bindTimeLimit, and authentication- Method. Please review section 5.2 for details on how a DUA should properly contact a DSA. 5.1.3 Interpreting the defaultSearchBase attribute Interpretation: When a DUA needs to search the DSA for information, this attribute provides the "base" for the search. This parameter can be overridden or appended by the serviceSearchDescriptor attribute. See section 5.1.6. Joslin [Page 11] Internet-Draft DUA Configuration Schema November 2000 Default Value: There is no default value for the defaultSearchBase. Other attribute notes: This attribute is used in conjunction with the serviceSear- chDescriptor attribute. See section 5.1.6. 5.1.4 Interpreting the authenticationMethod attribute Interpretation: The authenticationMethod attribute defines an ordered list of LDAP bind methods to be used when attempting to contact a DSA. Each method MUST be attempted in the order provided by the attribute, until a successful LDAP bind is performed ("none" is assumed to always be successful). See section 5.2 for more information. none - The DUA does not perform an LDAP bind. simple - The DUA performs an LDAP simple bind. sasl - The DUA performs an LDAP SASL bind using the specified SASL mechanism and options. tls - The DUA performs an LDAP start_tls operation followed by the specified bind method (for more information refer to section 5.1 of RFC 2830). Default Value: If the authenticationMethod attribute is not provided, the DUA may choose to bind to the DSA using any method. However, if the authenticationMethod is provided, the DUA MUST only use the methods specified. Other attribute notes: Determining how the DUA should bind to the DSAs also depends on the additional configuration attributes, credentialLevel and bindTimeLimit. Please review section 5.2 for details on how to properly bind to a DSA. 5.1.5 Interpreting the credentialLevel attribute Interpretation: The credentialLevel attribute defines what type(s) of credential(s) the DUA should use when contacting the DSA. The Joslin [Page 12] Internet-Draft DUA Configuration Schema November 2000 credentialLevel can contain more than one credential type, separated by white space. anonymous - The DUA should not use a credential when binding to the DSA. proxy - The DUA should use a known proxy identity when binding to the DSA. A proxy identity is a specific credential that was created to represent the DUA. This document does not define how the proxy user should be created, or how the DUA should determine what the proxy user's credential is. This functionality is up to each implementation. self - When the DUA is acting on behalf of a "real user" the DUA should attempt to bind to the DSA as that user. The DUA should map the user's identity to a credential used in the directory. If the DUA contains more than one credential type, the DUA SHOULD use the credential types in the order specified. As soon as the DUA is able to successfully bind to the DSA, the DUA should not attempt to bind using the remaining credential types. If the DUA discovers that the credentials specified are invalid, it should not attempt further binds using any additional methods. Default Value: If the credentialLevel attribute is not defined, the DUA should not use a credential when binding to the DSA (also known as anonymous.) Other attribute notes: Determining how the DUA should bind to the DSAs also depends on the additional configuration attributes, credentialLevel and bindTimeLimit. Please review section 5.2 for details on how to properly bind to a DSA. 5.1.6 Interpreting the serviceSearchDescriptor attribute Interpretation: The serviceSearchDescriptor attribute defines how and where a DUA should search for a given service. The serviceSear- chDescriptor contains a serviceId, followed by one or more base-scope-filter triples. These base-scope-filter triples are used to define searches only for the specific service. Joslin [Page 13] Internet-Draft DUA Configuration Schema November 2000 Multiple base-scope-filters allow the DUA to search for data in multiple locations of the DIT. In addition to the triples, serviceSearchDescriptor might also contain the DN of an entry which will contain more servi- ceSearchDescriptors for the given service. If the base, as defined in the serviceSearchDescriptor, is followed by the "," (ASCII 0x2C) character, this base is known as a relative base (or relative distinguished name.) The DUA MUST define the search base by appending the relative base with the defaultSearchBase. Example: defaultSearchBase: dc=mycompany,dc=com serviceSearchDescriptor: email:ou=people,?one; ou=contractor,?one; ref:cn=profile,dc=mycompany,dc=com In this example, the DUA SHOULD search in "ou=people,dc=mycompany,dc=com" first. The DUA then MAY search in "ou=contractor,dc=mycompany,dc=com", and finally it MAY search other locations as specified in "cn=profile,dc=mycompany,dc=com". If a DUA is performing a search for a particular service which has a serviceSearchDescriptor defined, the DUA should set the base, scope and filter as defined. Each base-scope-filter triple represents a single LDAP search operation. If multiple base-scope-filter triples are provided, the DUA should perform the search requests in the order specified by the serviceSear- chDescriptor. Default Values: If a serviceSearchDescriptor or an element there-of is not defined for a particular service, the DUA SHOULD create the base, scope and filter as follows: base - Same as the defaultSearchBase scope - Same as the defaultSearchScope filter - Use defaults as defined by DUAs service. If the defaultSearchBase is not defined, then the DUAs service may use its own default. Joslin [Page 14] Internet-Draft DUA Configuration Schema November 2000 Other attribute notes: If a serviceSearchDescriptor exists for a given service, the service MUST use at least one base-scope-filter triple in per- forming searches. It MAY perform multiple searches per ser- vice if multiple base-scope-filter triples are defined for that service. The details of how the "filter" is interpreted by each DUAs service is defined by each service. This means the filter is NOT REQUIRED to be a legal LDAP filter [4]. Furthermore, whether attribute mapping or objectclass mapping applies to the filter or not should be defined by each service. It is assumed the serviceID is unique to a given service within the scope of the DSA. 5.1.7 Interpreting the attributeMap attribute Interpretation: A DUA SHOULD perform attribute mapping for all LDAP operations performed for a service which has an attributeMap entry. Because attribute mapping is specific to each service within the DUA, a "serviceId" is required as part of the attributeMap syntax. Not all DUA services should necessarily perform the same attribute mapping. Attribute mapping MUST only be used to map attributes of simi- lar syntaxes as required by the service supported by the DUA. However, a DUA is NOT REQUIRED to verify syntaxes of mapped attributes. Suppose a DUA is acting on behalf of an email service. By default the "email" service uses the "mail", "cn" and "sn" attributes to discover mail addresses. However, the email service has been deployed in an environment that uses "employ- eeName". In this case, the attribute "cn" can be mapped to "employeeName," allowing the DUA to perform searches using the "employeeName" attribute as part of the search filter, instead of "cn". This mapping is performed by adding an attributeMap attribute to the configuration profile entry as follows (represented in [LDIF]): attributeMap: email:cn=employeeName DUAs MAY also map a single attribute to multiple attributes. When mapping a single attribute to more than one attribute, Joslin [Page 15] Internet-Draft DUA Configuration Schema November 2000 the new syntax or usage of the mapped attribute must be int- rinsically defined by the DUAs service. Example: attributeMap: email:cn=firstName lastName In this example, the DUA creates the new value by generating space separated string using the values of the mapped attri- butes. That might result in: "Bill Myponga" Default Value: The DUA MUST NOT remap an attribute unless it is explicitly defined by an attributeMap attribute. Other attribute notes: When an attribute is mapped to the special keystring "*NULL*", the DUA MUST NOT request that attribute from the DSA, when performing a search request. If the DUA is also capable of performing modification on the DSA, the DUA MUST NOT attempt to modify any attribute which has been mapped to "*NULL*". It is assumed the serviceID is unique to a given service within the scope of the DSA. A DUA SHOULD support attribute mapping. If it does, the fol- lowing additional rules apply: 1) If an attribute may be mapped to multiple attributes the DSA MUST define a syntax or usage statement for how the new attribute value will be evaluated. Furthermore, the resulting syntax of the combined attributes must be the same as the attribute being mapped. 2) A DUA MUST support mapping of attributes using the attri- bute OID. It SHOULD support attribute mapping based on the attribute name. 3) Naming attribute MAY NOT be mapped using one to many map- ping. 4) Mapping should only be applied to the target entries being searched. Attribute mapping should not be applied to parents of the target entries. 5.1.8 Interpreting the searchTimeLimit attribute Joslin [Page 16] Internet-Draft DUA Configuration Schema November 2000 Interpretation: The searchTimeLimit attribute defines the maximum time, in seconds, that a DUA should spend performing a search request request. Default Value: If the searchTimeLimit attribute is not defined or is zero, the search time limit is not enforced by the DUA. Other attribute notes: This timelimit only includes the amount of time required to perform the LDAP search operation. If other operations are required, those operations do not need to be considered part of the search time. See bindTimeLimit for the LDAP bind operation. 5.1.9 Interpreting the bindTimeLimit attribute Interpretation: The bindTimeLimit attribute defines the maximum time, in seconds, that a DUA should spend performing an LDAP bind request against each server on the preferredServerList or defaultServerList. Default Value: If the bindTimeLimit attribute is not defined or is zero, the bind time limit is not enforced by the DUA. Other attribute notes: This time limit only includes the amount of time required to perform the LDAP bind operation. If other operations are required, those operations do not need to be considered part of the bind time. See searchTimeLimit for the LDAP search operation. 5.1.10 Interpreting the followReferrals attribute Interpretation: If set to TRUE, the DUA SHOULD follow any referrals if discovered. Joslin [Page 17] Internet-Draft DUA Configuration Schema November 2000 If set to FALSE, the DUA MUST NOT follow referrals. Default Value: If the followReferrals attribute is not set or set to an invalid value the default value is TRUE. 5.1.11 Interpreting the profileTTL attribute Interpretation: The profileTTL attribute defines how often the DUA SHOULD re- load and reconfigure itself with using the corresponding con- figuration profile entry. The value is represented in seconds. Once a DUA reloads the profile entry, it SHOULD re- configure itself with the new values. Default Value: If not specified the DUA MAY use its own reconfiguration pol- icy. Other attribute notes: If the profileTTL value is zero, the DUA SHOULD NOT automati- cally re-load the configuration profile. 5.1.12 Interpreting the objectclassMap attribute Interpretation: A DUA SHOULD perform objectclass mapping for all LDAP opera- tions performed for a service which has an objectclassMap entry. Because objectclass mapping is specific to each ser- vice within the DUA, a "serviceId" is required as part of the objectclassMap syntax. Not all DUA services should neces- sarily perform the same objectclass mapping. Objectclass mapping should be used in conjunction with attri- bute mapping to map the required schema by the service to an equivalent schema that is available in the directory. Suppose a DUA is acting on behalf of an email service. By default the "email" service uses the "mail", "cn" and "sn" attributes to discover mail addresses in entries created using inetorgperson objectclass. However, the email service has been deployed in an environment that uses entries created using "employee" objectclass. In this case, the attribute Joslin [Page 18] Internet-Draft DUA Configuration Schema November 2000 "cn" can be mapped to "employeeName", and "inetorgperson" can be mapped to "employee", allowing the DUA to perform LDAP operations using the entries which exist in the directory. This mapping is performed by adding attributeMap and objectclassMap attributes to the configuration profile entry as follows (represented in [LDIF]): attributeMap: email:cn=employeeName objectclassMap: email:inetorgperson=employee Default Value: The DUA MUST NOT remap an objectclass unless it is explicitly defined by an objectclassMap attribute. Other attribute notes: A DUA SHOULD support objectclass mapping. If it does, the DUA MUST support mapping of objectclasses using the objectclass OID. It SHOULD support objectclass mapping based on the objectclass name. It is assumed the serviceID is unique to a given service within the scope of the DSA. 5.1.13 Interpreting the defaultSearchScope attribute Interpretation: When a DUA needs to search the DSA for information, this attribute provides the "scope" for the search. This parameter can be overridden by the serviceSearchDescriptor attribute. See section 5.1.6. Default Value: The default value for the defaultSearchScope is "one", representing one level search. 5.2 Binding to the Directory Server The DUA SHOULD use the following algorithm when binding to the server: for (host in hostnames) [Note 1] for (clevel in credentialLevel) { Joslin [Page 19] Internet-Draft DUA Configuration Schema November 2000 if (clevel is anonymous) return success [Note 2] for (amethod in authMethod) { if (amethod is none) return success [Note 2] authenticate to host, using amethod and clevel if (authentication failed with bad credential) try next clevel if (authentication passed) return success } } Note 1: hostnames is the list of server to contact as defined in 5.1.1 & 5.1.2. Note 2: In case of anonymous or none, the DUA MAY try contacting the server to ensure the directory server is available and responding to requests. 6. Security Considerations The profile entries MUST be protected against unauthorized modifi- cation. Since the profile is most useful if its content is avail- able broadly, it is recommended that the profile entries will be readable anonymously. However, ultimately each service needs to consider implications of providing its service configuration as part of this profile and limit access to the profile entries accordingly. Additionally, the management of the authentication credentials for the DUA is outside the scope of this document and needs to be handled by the DUA. 7. Acknowledgments There were several additional authors of this document. However we chose to represent only one author per company in the heading. From Sun we also would like to acknowledge Roberto Tam for his design work on Sun's first LDAP name service product and his input for this draft. From Hewlett-Packard we'd like to acknowledge Dave Binder for his work architecting Hewlett-Packard's LDAP name ser- vice product as well as his design guidance on this draft. We'd also like to acknowledge Grace Lu from HP, for her input and imple- mentation of HP's configuration profile manager code. Joslin [Page 20] Internet-Draft DUA Configuration Schema November 2000 8. References [1] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication Methods for LDAP", RFC 2828, May 2000 [2] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [3] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [4] T. Howes, "The String Representation of LDAP Search Filters", RFC 2254, December 1997. [5] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Loca- tors (URL)", RFC 1738, December 1994. [7] J. Meyers, "Simple Authentication and Security Layer [SASL]", RFC 2222, October 1997 [8] M. Wahl, "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [9] T. Berners-Lee, R. Fielding, R. Fielding, "Uniform Resource Iden- tifiers (URI): Generic Syntax", RFC 2396, August 1998. [10] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal IPv6 Addresses in URL's, RFC 2732, December 1999. [11] P. Leach, C. Newman, "Using Digest Authentication as a SASL Mechan- ism", RFC 2831, May 2000 [12] Joslin [Page 21] Internet-Draft DUA Configuration Schema November 2000 J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Proto- col [v3]: Extension for Transport Layer Security", RFC 2830, May 2000 [13] Microsoft Corporation, "Services for Unix 2.0", http://www.microsoft.com/WINDOWS2000/sfu/default.asp [14] L. Howard, "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998. [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev- els", RFC 2119, March 1997. [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000. 10. Author's Addresses Luke Howard PADL Software Pty. Ltd. PO Box 59 Central Park Vic 3145 Australia EMail: lukeh@padl.com Bob Joslin Hewlett-Packard Company 19420 Homestead RD MS43-LF Cupertino, CA 95014 USA Phone: +1 408 447-3044 EMail: bob_joslin@hp.com Morteza Ansari Joslin [Page 22] Internet-Draft DUA Configuration Schema November 2000 Sun Microsystems, Inc. 901 San Antonio RD MS MPK17-203 Palo Alto, CA 94303 USA Phone: +1 650 786-6178 EMail: morteza.ansari@sun.com Joslin [Page 23]