Application Working Group M. Ansari
INTERNET-DRAFT Sun Microsystems, Inc.
Expires September 2001 L. Howard
PADL Software Pty. Ltd.
B. Joslin [ed.]
Hewlett-Packard Company
March 2, 2001
Intended Category: Informational
A Configuration Schema for LDAP Based
Directory User Agents
<draft-joslin-config-schema-01.txt>
Status of this Memo
This memo provides information for the Internet community. This
memo does not specify an Internet standard of any kind. Distribu-
tion of this memo is unlimited.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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
Joslin [Page 1]
Internet-Draft DUA Configuration Schema November 2000
This document describes a mechanism for global configuration of
similar directory user agents. This document proposes a schema for
configuration of these DUAs that may be discovered using the Light-
weight 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 mechanism 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.
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
Joslin [Page 2]
Internet-Draft DUA Configuration Schema November 2000
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 document plan to develop such a document for the
Network Information Service DUA, described by RFC 2307 or it's suc-
cessor.
We expect that as DUAs take advantage of this configuration scheme,
each DUA will require additional configuration paramenters, not
specified by this document. Thus, we would expect that new auxili-
ary object classes, containing new configuration attributes will be
created, and then joined with the structural class defined by this
document to create a configuration profile for a particular DUA
service. And that by joining various auxiliary objectclasses for
different 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 document is defined under the "DUA Con-
figuration 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
document 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
authenticationMethod
credentialLevel
Joslin [Page 3]
Internet-Draft DUA Configuration Schema November 2000
serviceSearchDescriptor
serviceCredentialLevel
serviceAuthenticationMethod
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 document.
This document does not define new syntaxes that must be supported
by the directory server. The string encodings used by the attri-
butes defined in this document can be found section 5.
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
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'
Joslin [Page 4]
Internet-Draft DUA Configuration Schema November 2000
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
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 caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
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 caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
( DUAConfSchemaOID.1.7 NAME 'profileTTL'
DESC 'Time to live before a client DUA should re-read this
configuration profile'
Joslin [Page 5]
Internet-Draft DUA Configuration Schema November 2000
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
( DUAConfSchemaOID.1.14 NAME 'serviceSearchDescriptor'
DESC 'LDAP search descriptor list used by Naming-DUA'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( DUAConfSchemaOID.1.9 NAME 'attributeMap'
DESC 'Attribute mappings used by a Naming-DUA'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( DUAConfSchemaOID.1.10 NAME 'credentialLevel'
DESC 'Identifies type of credentials a DUA should
use when binding to the LDAP server'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
( DUAConfSchemaOID.1.11 NAME 'objectclassMap'
DESC 'Objectclass mappings used by a Naming-DUA'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( DUAConfSchemaOID.1.12 NAME 'defaultSearchScope'
DESC 'Default search scope used by a DUA'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
( DUAConfSchemaOID.1.13 NAME 'serviceCredentialLevel'
DESC 'Search scope used by a service of the DUA'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
( DUAConfSchemaOID.1.14 NAME 'serviceAuthenticationMethod'
DESC 'Authentication Method used by a service of the DUA'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
4. Class Definition
The objectclass below is constructed from the attributes defined in
Joslin [Page 6]
Internet-Draft DUA Configuration Schema November 2000
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.4 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 $
serviceCredentialLevel $ serviceAuthenticationMethod $
objectclassMap $ attributeMap $
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.
Syntax:
serverList = host *(space [host])
Default Value:
Joslin [Page 7]
Internet-Draft DUA Configuration Schema November 2000
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, serviceCredentialLevel, bindTimeLimit
and authenticationMethod. 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:
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 document.
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.
Syntax:
serverList = host *(space [host])
Default Value:
If a defaultServerList attribute is not provided, the DUA
should attempt to contact the same DSA which provided the
Joslin [Page 8]
Internet-Draft DUA Configuration Schema November 2000
configuration profile entry itself. The default DSA is con-
tacted only if the preferredServerList attribute is also not
provided.
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, serviceCredentialLevel, bindTimeLimit
and authenticationMethod. 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.
Syntax:
Defined by 1.3.6.1.4.1.1466.115.121.1.12
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.
The serviceAuthenticationAtrribute overrides this value for a
particular service (see 5.1.14.) Each method MUST be
attempted in the order provided by the attribute, until a suc-
cessful LDAP bind is performed ("none" is assumed to always be
successful). See section 5.2 for more information.
Joslin [Page 9]
Internet-Draft DUA Configuration Schema November 2000
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).
Syntax:
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 speci-
fied in the syntax, at most one of each type is allowed.
Default Value:
If the authenticationMethod or serviceAutenticationMethod (for
that particular service) attributes are not provided, the DUA
may choose to bind to the DSA using any method. However, if
either authenticationMethod or serviceAuthenticationMethod are
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,
serviceCredentialLevel and bindTimeLimit. Please review sec-
tion 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
serviceCredentialLevel overrides this value for a particular
service (5.1.15.) The credentialLevel can contain more than
one credential type, separated by white space.
Joslin [Page 10]
Internet-Draft DUA Configuration Schema November 2000
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.
Syntax:
credentialLevel = level *(space level)
level = self | proxy | anonymous
self = "self"
proxy = "proxy"
anonymous = "anonymous"
Note: Although multiple credentialLevels may be specified in
the syntax, at most one of each type is allowed. Refer to
implementation notes in section 5.2 for additional syntax
requirements for the credentialLevel attribute.
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.
Joslin [Page 11]
Internet-Draft DUA Configuration Schema November 2000
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.
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.
Syntax:
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 = UTF-8 encoded string
If the base or filter contains the ";" (ASCII 0x3B) "?"
(ASCII 0x3F) """ (ASCII 0x22) or " escaped (preceded with
the " surrounded 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.
The filter string syntax can be more rigorously defined
by the DUA service. A suggested syntax would be that as
defined by RFC 2253.
Example:
Joslin [Page 12]
Internet-Draft DUA Configuration Schema November 2000
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.
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
Joslin [Page 13]
Internet-Draft DUA Configuration Schema November 2000
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,
the new syntax or usage of the mapped attribute must be int-
rinsically defined by the DUAs service.
Syntax:
attributeMap = serviceId ":" origAttribute "="
attributes
origAttribute = attribute
attributes = wattribute *( space wattribute )
wattribute = whsp newAttribute whsp
newAttribute = descr | "*NULL*"
attribute = descr
Values of the origAttribute depend on the type of appli-
cation using the attribute mapping feature.
Joslin [Page 14]
Internet-Draft DUA Configuration Schema November 2000
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
Interpretation:
Joslin [Page 15]
Internet-Draft DUA Configuration Schema November 2000
The searchTimeLimit attribute defines the maximum time, in
seconds, that a DUA should spend performing a search request
request.
Syntax:
Defined by 1.3.6.1.4.1.1466.115.121.1.27.
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.
Syntax:
Defined by 1.3.6.1.4.1.1466.115.121.1.27.
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
Joslin [Page 16]
Internet-Draft DUA Configuration Schema November 2000
Interpretation:
If set to TRUE, the DUA SHOULD follow any referrals if
discovered.
If set to FALSE, the DUA MUST NOT follow referrals.
Syntax:
Defined by 1.3.6.1.4.1.1466.115.121.1.7.
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.
Syntax:
Defined by 1.3.6.1.4.1.1466.115.121.1.27.
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
Joslin [Page 17]
Internet-Draft DUA Configuration Schema November 2000
necessarily 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
"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
Syntax:
objectclassMap = serviceId ":" origObjectclass "="
objectclass
origObjectclass = objectclass
objectclass = keystring
Values of the origObjectclass depend on the type of applica-
tion using the objectclass mapping feature.
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.
Joslin [Page 18]
Internet-Draft DUA Configuration Schema November 2000
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.
Syntax:
scopeSyntax = "base" | "one" | "sub"
Refer to implementation notes in section 5.2 for additional
syntax requirements for the credentialLevel attribute.
Default Value:
The default value for the defaultSearchScope is "one",
representing one level search.
5.1.14 Interpreting the serviceAuthenticationMethod attribute
Interpretation:
The serviceAuthenticationMethod attribute defines an ordered
list of LDAP bind methods to be used when attempting to con-
tact a DSA for a particular service. Interpretation and used
of this attribute is the same as 5.1.4, but specific for each
service.
Syntax:
svAuthMethod = service ":" method *(";" method)
Note: Although multiple authentication methods may be
specified in the syntax, at most one of each type is
allowed.
Default Value:
If the serviceAuthenticationMethod attribute, or follow
its default if not provided.
Other attribute notes:
Determining how the DUA should bind to the DSAs also
Joslin [Page 19]
Internet-Draft DUA Configuration Schema November 2000
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.15 Interpreting the serviceCredentialLevel attribute
Interpretation:
The serviceCrredentialLevel attribute defines what
type(s) of credential(s) the DUA should use when contact-
ing the DSA for a particular service. Interpretation and
used of this attribute are the same as 5.1.5.
Syntax:
svCredentialLevel = service ":" level *(space level)
Refer to implementation notes in section 5.2 for addi-
tional syntax requirements for the credentialLevel attri-
bute.
Note: Although multiple credentialLevels may be specified
in the syntax, at most one of each type is allowed.
Default Value:
If the serviceCredentialLevel attribute is not defined,
the DUA MUST examine the credentailLevel attribute, or
follow its default if not provided.
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.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) {
if (clevel is anonymous)
return success [Note 2]
for (amethod in authMethod) {
Joslin [Page 20]
Internet-Draft DUA Configuration Schema November 2000
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 contact-
ing
the server to ensure the directory server is available
and responding to requests.
6. Security Considerations
The profile entries MUST be protected against unauthorized
modification. Since the profile is most useful if its content
is available 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 manage-
ment 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. How-
ever 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 pro-
duct and his input for this document. From Hewlett-Packard
we'd like to acknowledge Dave Binder for his work architecting
Hewlett-Packard's LDAP name service product as well as his
design guidance on this document. We'd also like to ack-
nowledge Grace Lu from HP, for her input and implementation of
HP's configuration profile manager code.
Joslin [Page 21]
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 Direc-
tory 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
Locators (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
Identifiers (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
Mechanism", RFC 2831, May 2000
Joslin [Page 22]
Internet-Draft DUA Configuration Schema November 2000
[12]
J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access
Protocol [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 Informa-
tion 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
Levels", 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
Joslin [Page 23]
Internet-Draft DUA Configuration Schema November 2000
Morteza Ansari
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 24]