RFC 4876
A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents
RFC 4876: A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents 💖
Okay bestie, let's start with the title block tea ☕. This is from May 2007 and it's an Informational RFC from the Network Working Group, so it's giving "here's some useful info" 📚 rather than "this is a standard" 🦋. The authors are B. Neal-Joslin (editor, from HP), L. Howard (from PADL), and M. Ansari (from Infoblox) 👑. It doesn't obsolete or update any other RFCs, so it's not stepping on anyone's toes 🫶.
Status of This Memo ✨
This memo is here to give the Internet community some info 📚. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈.
Copyright Notice 🎀
Copyright (C) The IETF Trust (2007).
IESG Note 💅
This RFC is not a candidate for any level of Internet Standard, so no pressure 🙈. The IETF disclaims any knowledge of the fitness of this RFC for any purpose. It also notes that the decision to publish is not based on IETF review for things like security, congestion control, or inappropriate interaction with deployed protocols 😭. The RFC Editor chose to publish this document at its discretion. Readers should be careful about how much they lean on it when deciding whether to implement or deploy it 💀. See RFC 3932 for more information.
Abstract 🦋
So this doc has two main parts 💖. First there's a schema for agents that use the Lightweight Directory Access protocol (LDAP), and second there's a proposed use case for that schema, which is distributed configuration of similar directory user agents. The doc proposes a set of attribute types and an object class 🧚. In the proposed use case, directory user agents (DUAs) can use this schema to figure out where directory data lives and what access parameters to use for the specific services they support 🔥. It also covers attribute and object class mapping, which lets a DUA reconfigure its expected (default) schema so it matches the end user's environment ✨. And honestly, this doc is meant to be a skeleton for future docs that describe configuring specific DUA services 🌸.
Table of Contents 🍓
1. Background and Motivation . . . . . . . . . . . . . . . . . . 3
2. General Information . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2.2. Attributes Summary . . . . . . . . . . . . . . . . . . . . 5
2.3. Object Classes Summary . . . . . . . . . . . . . . . . . . 5
2.4. Common Syntax/Encoding Definitions . . . . . . . . . . . . 5
3. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Attribute Definitions . . . . . . . . . . . . . . . . . . 6
3.2. Class Definition . . . . . . . . . . . . . . . . . . . . . 9
4. DUA Implementation Details . . . . . . . . . . . . . . . . . . 10
4.1. Interpreting the preferredServerList Attribute . . . . . . 10
4.2. Interpreting the defaultServerList Attribute . . . . . . . 11
4.3. Interpreting the defaultSearchBase Attribute . . . . . . . 12
4.4. Interpreting the authenticationMethod Attribute . . . . . 13
4.5. Interpreting the credentialLevel Attribute . . . . . . . . 15
4.6. Interpreting the serviceSearchDescriptor Attribute . . . . 16
4.7. Interpreting the attributeMap Attribute . . . . . . . . . 20
4.8. Interpreting the searchTimeLimit Attribute . . . . . . . . 23
4.9. Interpreting the bindTimeLimit Attribute . . . . . . . . . 23
4.10. Interpreting the followReferrals Attribute . . . . . . . . 24
4.11. Interpreting the dereferenceAliases Attribute . . . . . . 24
4.12. Interpreting the profileTTL Attribute . . . . . . . . . . 24
4.13. Interpreting the objectclassMap Attribute . . . . . . . . 25
4.14. Interpreting the defaultSearchScope Attribute . . . . . . 27
4.15. Interpreting the serviceAuthenticationMethod Attribute . . 27
4.16. Interpreting the serviceCredentialLevel Attribute . . . . 28
5. Binding to the Directory Server . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. Registration of Object Classes . . . . . . . . . . . . . . 31
8.2. Registration of Attribute Types . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 351. Background and Motivation 🌸
Okay so LDAP [RFC4510] basically took over, and now pretty much everyone uses a directory server 💅. Tons of client apps (DUAs) are getting built on LDAP directories for all kinds of services 🔥. LDAP has made building these apps way easier, but developers and directory admins still run into some challenges 😭.
The authors of this doc are the people who actually built DUAs described in [RFC2307] 🧚. While building them, they noticed a few issues that still need fixing if you want to deploy and configure a big network of these DUAs without losing your mind 💀.
One of these challenges comes from the lack of a utopian schema 🦋. A utopian schema would be one that every app developer agrees on, and that supports every app. Sadly, lots of DUAs define their own schema even when they offer similar services (like RFC 2307 vs. Microsoft's Services for Unix [MSSFU]) 🙈. These schemas have similar attributes but use different attribute names, which causes data redundancy in directory entries and gives admins extra work when updating schemas and syncing data 😩. Or, in a more common case, two or more apps agree on some schema elements but pick different ones for other data that could've been shared between them 🍓. Data sync and translation tools do exist, but the authors think it's worth putting this capability directly into the directory user agent itself 💖.
Beyond proposing a schema for general use, another goal here is to kill data redundancy by letting DUAs configure themselves to match the schema of the deployed directory, instead of forcing the DUA's own schema onto the directory 👑.
Another goal is giving the DUA enough config info to figure out how to pull its data from the directory, like which parts of the directory tree to search ✨.
Finally, this doc wants to describe a config method that lots of DUAs on different platforms can share, which makes it a configuration profile 🌈. The whole point of this profile is to centralize and simplify DUA management 🫶.
This doc is meant to be a skeleton framework for future docs that will describe the specific details for each service a DUA provides 🎀. The authors plan to write one like that for the Network Information Service DUA, described by RFC 2307 or its successor 🔥.
We expect that as DUAs start using this config scheme, each one will need extra config parameters that this doc doesn't specify 🧚. So new auxiliary object classes with new config attributes will be created, then joined with the structural class defined here to make a configuration profile for a particular DUA service 💅. By joining different auxiliary object classes for different DUA services, you can control the config of multiple DUA services from one single configuration profile entry 💜.
2. General Information 🍓
The schema in this doc is defined under the "DUA Configuration Schema" 💖. It comes from this object identifier (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) 🦋. In this doc, that OID is represented by the keystring "DUAConfSchemaOID" (1.3.6.1.4.1.11.1.3.1) ✨.
2.1. Requirements Notation 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💅.
2.2. Attributes Summary 🌈
Here's the list of attributes this doc defines 🧚:
preferredServerListdefaultServerListdefaultSearchBasedefaultSearchScopeauthenticationMethodcredentialLevelserviceSearchDescriptorserviceCredentialLevelserviceAuthenticationMethodattributeMapobjectclassMapsearchTimeLimitbindTimeLimitfollowReferralsdereferenceAliasesprofileTTL
2.3. Object Classes Summary 👑
This doc defines just one object class 💜:
DUAConfigProfile
2.4. Common Syntax/Encoding Definitions 🫶
The string encodings proposed for the attributes in this doc are in Section 4 ✨. This doc uses ABNF [RFC4234] to define new encodings 🌸.
Here are the syntax definitions used throughout this doc 💖:
The list of used syntaxes are:
+---------------------------+---------------------------------------+
| Key | Source |
+---------------------------+---------------------------------------+
| keystring | as defined by [RFC4512] Section 1.4 |
| descr | as defined by [RFC4512] Section 1.4 |
| SP | as defined by [RFC4512] Section 1.4 |
| WSP | as defined by [RFC4512] Section 1.4 |
| base | as defined by distinguishedName in |
| | [RFC4514] |
| distinguishedName | as defined by [RFC4514] Section 2 |
| relativeDistinguishedName | as defined by [RFC4514] Section 2 |
| scope | as defined by [RFC4516] Section 2 |
| host | as defined by [RFC3986] Section 3.2.2 |
| hostport | host [":" port ] |
| port | as defined by [RFC3986] Section 3.2.3 |
| serviceID | same as keystring |
+---------------------------+---------------------------------------+This doc doesn't define any new syntaxes the directory server has to support 🙈. Instead, these syntaxes are just expected to be interpreted by the DUA 🦋. As the schema definition in Section 3 references, most encodings are expected to be stored in attributes using common syntaxes, like the Directory String syntax as defined in Section 3.3.6 of [RFC4517] 💅. Refer to RFC 4517 for any other syntaxes this schema uses 🌈.
3. Schema Definition 💜
This section defines a proposed schema 🧚. This schema doesn't require defining new matching rules or syntaxes, and it may be used for any purpose seen 🍓. A proposed use of this schema to support config elements for a directory user agent is described in Section 4 🎀.
3.1. Attribute Definitions
okay so this is where the attributes live 💖 the syntax used to describe them is defined in [RFC4512], Section 4.1.2 🎀, and the individual syntaxes and matching rules used in these descriptions are covered in [RFC4517], Sections 3.3 and 4.2, respectively ✨
( 1.3.6.1.4.1.11.1.3.1.1.0 NAME 'defaultServerList'
DESC 'List of default servers'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase'
DESC 'Default base for searches'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList'
DESC 'List of preferred servers'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.3 NAME 'searchTimeLimit'
DESC 'Maximum time an agent or service allows for a
search to complete'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.4 NAME 'bindTimeLimit'
DESC 'Maximum time an agent or service allows for a
bind operation to complete'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.5 NAME 'followReferrals'
DESC 'An agent or service does or should follow referrals'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod'
DESC 'Identifies the types of authentication methods either
used, required, or provided by a service or peer'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.7 NAME 'profileTTL'
DESC 'Time to live, in seconds, before a profile is
considered stale'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.9 NAME 'attributeMap'
DESC 'Attribute mappings used, required, or supported by an
agent or service'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.11.1.3.1.1.10 NAME 'credentialLevel'
DESC 'Identifies type of credentials either used, required,
or supported by an agent or service'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.11 NAME 'objectclassMap'
DESC 'Object class mappings used, required, or supported by
an agent or service'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.11.1.3.1.1.12 NAME 'defaultSearchScope'
DESC 'Default scope used when performing a search'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.13 NAME 'serviceCredentialLevel'
DESC 'Specifies the type of credentials either used, required,
or supported by a specific service'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.11.1.3.1.1.14 NAME 'serviceSearchDescriptor'
DESC 'Specifies search descriptors required, used, or
supported by a particular service or agent'
EQUALITY caseExactMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.4.1.11.1.3.1.1.15 NAME 'serviceAuthenticationMethod'
DESC 'Specifies types authentication methods either
used, required, or supported by a particular service'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.4.1.11.1.3.1.1.16 NAME 'dereferenceAliases'
DESC 'Specifies if a service or agent either requires,
supports, or uses dereferencing of aliases.'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )3.2. Class Definition
this object class is built from the attributes in Section 3.1 💅 the only exception is "cn", which comes from [RFC4519] 🌸. "cn" holds the name of the DUA configuration profile, and it's recommended for the relative distinguished name (RDN) [RFC4514] naming attribute 🦋. this class is used specifically by the DUA described in Section 4 ✨. the syntax for describing it is defined in [RFC4512], Section 4.1.1 🎀
( 1.3.6.1.4.1.11.1.3.1.2.5 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 $ dereferenceAliases $
serviceSearchDescriptor $ serviceCredentialLevel $
serviceAuthenticationMethod $ objectclassMap $
attributeMap $ profileTTL ) )4. DUA Implementation Details ✨
this section walks through an implementation of the schema from Section 3 💖 it explains how a DUA should format and interpret the attributes we just defined. any agent using the DUAConfigProfile object class is expected to follow what's written here 🫶
Note: a lot of the subsections below come with examples 🍓 unless it says otherwise, those examples are written in the LDAP Data Interchange Format (LDIF) [RFC2849] 🧚
4.1. Interpreting the preferredServerList Attribute
Interpretation:
okay so, as the syntax says, preferredServerList is a whitespace-separated list of server addresses with their port numbers 🎀 when a DUA needs to reach a directory server agent (DSA), the DUA MUST first attempt to contact one of the servers listed in the preferredServerList attribute 💅 the DUA MUST contact the DSA named by the first server address in the list. if that DSA is unavailable, the remaining DSAs MUST be queried in the order given (left to right) until a connection with a DSA is established. once that connection is up, the DUA SHOULD NOT try to connect to the remaining DSAs 🔥 listing several DSAs isn't about getting extra data, it's about high availability of replicated data ✨ this is also the main reason an LDAP URL [RFC3986] syntax wasn't chosen for this document 🦋
if the DUA can't contact any of the DSAs in preferredServerList, the defaultServerList attribute MUST be examined, as described in Section 4.2 😭 the servers in preferredServerList MUST be contacted before the DUA tries any of the servers in defaultServerList 👑
Syntax:
serverList = hostport *(SP [hostport])Default Value:
preferredServerList doesn't have a default value 🙈 instead, a DUA MUST examine the defaultServerList attribute 💜
Other attribute notes:
this attribute works together with defaultServerList, so check Section 4.2 for more implementation notes 🌈 how the DUA queries the DSAs also depends on credentialLevel, serviceCredentialLevel, bindTimeLimit, serviceAuthenticationMethod, and authenticationMethod 💖 for the details on how a DUA should properly bind to a DSA, look at Section 5 🫶
Example:
preferredServerList: 192.168.169.170 ldap1.mycorp.com
ldap2:1389 [1080::8:800:200C:417A]:3894.2. Interpreting the defaultServerList Attribute
Interpretation:
defaultServerList MUST only be examined if preferredServerList isn't provided, or if the DUA can't connect to any of the DSAs listed in preferredServerList 😭
if more than one address is given, the DUA may keep the order it was handed or make its own order, based on whatever it decides is the "best" order to query DSAs 💅 for example, it might check the list and query DSAs by the "closest" server, or by the server with the least amount of "load" 🌸 how the "best" server order gets decided is totally up to the DUA and isn't part of this document 🦋
once the order is set, the DUA contacts the DSA named 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 there are no more DSAs left ✨ if a server address or port is invalid, the DUA SHOULD move on to the next server address, as described just above 🔥
Syntax:
serverList = hostport *(SP [hostport])Default Value:
if defaultServerList isn't provided, the DUA MAY try to contact the same DSA that gave it the configuration profile entry 🧚 that default DSA only gets contacted if preferredServerList isn't provided either 💜
Other attribute notes:
this attribute goes hand in hand with preferredServerList, so see Section 4.1 for more implementation notes 🌈 how the DUA queries DSAs also depends on credentialLevel, serviceCredentialLevel, bindTimeLimit, serviceAuthenticationMethod, and authenticationMethod 💖 for how a DUA should properly contact a DSA, check out Section 5 🫶
Example:
defaultServerList: 192.168.169.170 ldap1.mycorp.com
ldap2:1389 [1080::8:800:200C:417A]:59124.3. Interpreting the defaultSearchBase Attribute
Interpretation:
when a DUA needs to search the DSA for information, this attribute gives the base for that search 🍓 the serviceSearchDescriptor attribute can override or append to this parameter, so see Section 4.6 🦋
Syntax:
defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [RFC4517] 🎀
Default Value:
defaultSearchBase has no default value 🙈 a DUA MAY define its own method for working out the search base when defaultSearchBase isn't provided 💜
Other attribute notes:
this attribute is used together with serviceSearchDescriptor, so see Section 4.6 🌈
Example:
defaultSearchBase: dc=mycompany,dc=com4.4. Interpreting the authenticationMethod Attribute ✨
Interpretation:
okay so this one is the ordered list of LDAP bind methods the DUA uses when it's trying to contact a DSA 🦋 the serviceAuthenticationMethod can override it for one particular service (see Section 4.15). each method MUST be attempted in the order the attribute gives, until an LDAP bind succeeds ("none" is assumed to always be successful) 💅 the DUA MAY skip over one or more methods though, so bestie, see Section 5 for the full deets 🫶
none- the DUA does not perform an LDAP bind. 🌸simple- the DUA performs an LDAP simple bind. 🍓sasl- the DUA performs an LDAP Simple Authentication and Security Layer (SASL) [RFC4422] bind using the specified SASL mechanism and options. 🔥tls- the DUA performs an LDAP StartTLS operation followed by the specified bind method (for more information refer to Section 4.14 of [RFC4511]). 🧚
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 [SASLMECH]Note: although you can list multiple authentication methods in the syntax, at most one of each type is allowed. so "simple;simple" is invalid, no cap 🙅♀️
Default Value:
okay so if the authenticationMethod or serviceAuthenticationMethod attributes (for that particular service) aren't provided, the DUA MAY choose to bind to the DSA using any method it has defined. but if either authenticationMethod or serviceAuthenticationMethod IS provided, the DUA MUST only use the methods specified. the vibe is literally "respect the list" 👑
Other attribute notes:
when you're using TLS, the string "tls:sasl/EXTERNAL" implies that both client and server (DSA and DUA) authentications are to be performed. any other TLS authentication method implies server-only (DSA side credential) authentication, along with the other SASL method used for DUA-side authentication. it's giving layers 🧁
determining how the DUA should bind to the DSAs also depends on the additional configuration attributes credentialLevel, serviceCredentialLevel, serviceAuthenticationMethod, and bindTimeLimit. please review Section 5 for details on how to properly bind to a DSA 💖
Example:
authenticationMethod: tls:simple;sasl/DIGEST-MD5(see [RFC2831])
4.5. Interpreting the credentialLevel Attribute 🎀
Interpretation:
the credentialLevel attribute defines what type(s) of credential(s) the DUA MUST use when contacting the DSA. the serviceCredentialLevel overrides this value for a particular service (Section 4.16). the credentialLevel can hold more than one credential type, separated by whitespace ✨
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. that's up to each implementation 🤷♀️self- when the DUA is acting on behalf of a known identity, the DUA MUST attempt to bind to the DSA as that identity. the DUA should contain methods to determine the identity of the user, so that the identity can be authenticated by the directory server using the defined authentication methods. main character energy 👑
if the credentialLevel contains more than one credential type, the DUA MUST use the credential types in the order specified. the DUA MAY skip over one or more credential types though. 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. once it's in, it's in 😌
Syntax:
credentialLevel = level *(SP level)
level = self / proxy / anonymous
self = "self"
proxy = "proxy"
anonymous = "anonymous"Note: although you can list multiple credential levels in the syntax, at most one of each type is allowed. refer to the implementation notes in Section 5 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 authenticationMethod, serviceAuthenticationMethod, serviceCredentialLevel, and bindTimeLimit. please review Section 5 for details on how to properly bind to a DSA. it's all connected, iykyk 🦋
Example:
credentialLevel: proxy anonymous4.6. Interpreting the serviceSearchDescriptor Attribute ✨
Interpretation 💖
Okay bestie, the serviceSearchDescriptor attribute is basically the map that tells a DUA how and where it should look for stuff for one specific service 🗺️ The DUA SHOULD search using it. It starts with a serviceID, then has one or more base-scope-filter triples. Those triples only define searches for that one service, so they're not a free-for-all 🙅♀️
Multiple base-scope-filters let the DUA hunt in multiple spots in the directory information tree (DIT), which is so useful. It looks super similar to an LDAP URL [RFC3986], but this document requires the ability to supply multiple hosts as part of the configuration of the DSA. Also, you need an ordered list of search descriptors, and the LDAP URL can't do that, so this is its own thing 🦋
The serviceSearchDescriptor might also hold the DN of an entry that contains an alternate profile. The DSA SHOULD re-evaluate that alternate profile and perform searches as that profile specifies 🔁
If the base is followed by a "," (ASCII 0x2C) character, it's called a relative base 🧩 A relative base can be made of one or more RDN components. When that happens, the DUA MUST define the search base by appending the relative base to the defaultSearchBase. Lowkey clever! ✨
Syntax 🧩
serviceSearchList = serviceID ":" serviceSearchDesc *(";"
serviceSearchDesc)
serviceSearchDesc = confReferral / searchDescriptor
searchDescriptor = [base] ["?" [scopeSyntax] ["?" [filter]]]
confReferral = "ref:" distinguishedName
base = distinguishedName / relativeBaseName
relativeBaseName = 1*(relativeDistinguishedName ",")
filter = UTF-8 encoded stringNow the escaping stuff, which is a little bit extra 💅 If the confReferral, base, relativeBaseName, or filter contains a ; (ASCII 0x3B), ? (ASCII 0x3F), " (ASCII 0x22), or \ (ASCII 0x5C) character, those characters MUST be escaped (preceded by the \ character). You can alternately surround the DN with quotes (ASCII 0x22). Go check RFC 4514 for the details 📖 If the confReferral, base, relativeBaseName, or filter is surrounded by quotes, only the " character needs escaping. And if you escape a character that didn't need it, you end up with both the \ and the character itself. Messy, but that's the rule 🙈
The usage and syntax of the filter string MUST be defined by the DUA service. A suggested syntax would be the one defined by [RFC4515] 🌈
If a DUA is searching for a particular service that has a serviceSearchDescriptor defined, the DUA MUST set the base, scope, and filter as defined. Each base-scope-filter triple represents a single LDAP search operation. If you provide multiple base-scope-filter triples in the serviceSearchDescriptor, the DUA SHOULD perform multiple search requests, and in that case, they MUST be done in the order the serviceSearchDescriptor specifies 🔢
FYI: Service search descriptors don't exactly follow the LDAP URL syntax [RFC4516]. The reason for the difference is to separate the host name(s) from the filter. That gives the DUA more flexibility when it's choosing its DSA 🦋
Default Value 🌸
If a serviceSearchDescriptor, or any element of it, isn't defined for a particular service, the DUA SHOULD create the base, scope, and filter like this:
base- Same as the defaultSearchBase.scope- Same as the defaultSearchScope.filter- Use defaults as defined by DUA's service.
If the defaultSearchBase or defaultSearchScope isn't defined, then the DUA 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 when it performs searches. It SHOULD perform multiple searches per service if multiple base-scope-filter triples are defined for that service 🔍
How the "filter" gets interpreted is up to each DUA's service. That means the filter is NOT REQUIRED to be a legal LDAP filter [RFC4515]. Also, the service MUST define how attribute and object class mapping affects that search filter. The DUA SHOULD say whether the attributes in the filter are assumed to already be mapped, or whether attribute mapping (see Section 4.7) should be applied to the filter. In general practice, implementation and usability suggest that attribute and object class mapping (Sections 4.7 and 4.13) SHOULD NOT be applied to the filter defined in the serviceSearchDescriptor 🙅♀️
The serviceID is unique to a given service within the scope of any DUA that might use the given profile, and should be defined by that service. This document doesn't cover registering serviceIDs. But as per the guidance at the end of Section 1, when DUA developers define their use of the DUAConfigProfile schema, they'll define the serviceIDs their DUA uses 🎀
searchGuide and enhancedSearchGuide [RFC4517] 🧐
There are a few reasons the authors chose not to use the existing searchGuide and enhancedSearchGuide attributes and related syntaxes. The enhancedSearchGuide met a bunch of the serviceSearchDescriptor requirements, but serviceSearchDescriptor was built mainly to link search operations to services. Multiple services can be configured using the same profile, so the serviceID has to be specified alongside the search descriptor info. A few other reasons for skipping enhancedSearchGuide:
- The need to specify alternate search bases, including the ability to specify search bases that are relative to the parent defaultSearchBase.
- The need to specify alternate profiles using the
ref:syntax. - The ability for individual services to specify their own syntaxes for the format of the search filter.
- The authors' belief that the user community is more familiar with the search filter syntax described by RFC 4515 than with that described by the enhancedSearchGuide syntax.
Example 🎀
defaultSearchBase: dc=mycompany,dc=com
serviceSearchDescriptor: email:ou=people,ou=org1,?
one;ou=contractor,?one;
ref:cn=profile,dc=mycompany,dc=comIn this example, the DUA MUST search in ou=people,ou=org1,dc=mycompany,dc=com first 🥰 The DUA then SHOULD search in ou=contractor,dc=mycompany,dc=com, and finally it SHOULD search other locations listed in the profile at cn=profile,dc=mycompany,dc=com. For more examples, see Appendix A 🌈✨
4.7. Interpreting the attributeMap Attribute ✨
Interpretation:
okay so a DUA SHOULD do attribute mapping for every LDAP operation it runs for a service that has an attributeMap entry 💅 Mapping belongs to each service inside the DUA, so every attributeMap needs a "serviceID" in its syntax. Not every DUA service has to map things the same way 🦋
Attribute mapping is mostly meant for mapping attributes with similar syntaxes, as defined by the service the DUA supports. But a DUA is NOT REQUIRED to check the syntaxes of mapped attributes 🙈 If the DUA does notice that a mapped attribute's syntax doesn't match the original one, it MAY translate between the two syntaxes. If a DUA does support value translation, the method and the list of translations it can do SHOULD be written down in the description of that DUA service 📝
Syntax:
attributeMap = serviceID ":" origAttribute "=" attributes
origAttribute = attribute
attributes = wattribute *( SP wattribute )
wattribute = WSP newAttribute WSP
newAttribute = descr / "*NULL*"
attribute = descrThe values of origAttribute are defined by the DUA service and SHOULD be documented as a list of the attributes it supports 🌸
Default Value:
by default, attributes a DUA service uses are NOT mapped unless an attributeMap attribute maps them 🙅♀️ The DUA SHOULD NOT map an attribute unless an attributeMap attribute explicitly defines it. No surprise mapping, bestie 💖
Other attribute notes:
when an attribute is mapped to the special keystring "*NULL*", the DUA SHOULD NOT ask the DSA for that attribute during a search or compare request 🫣 If the DUA can also do modifications on the DSA, it SHOULD NOT try to modify any attribute that's been mapped to "*NULL*" either.
the serviceID is assumed to be unique to a given service within the scope of the DSA 🔑
A DUA SHOULD support attribute mapping. If it does, these extra rules apply, and they're lowkey important:
- The list of attributes that are allowed to be mapped SHOULD be defined by and documented for the service.
- Any supported translation of mapping from attributes of dissimilar syntax SHOULD also be defined and documented.
- If an attribute may be mapped to multiple attributes, the DSA SHOULD define a syntax or usage statement for how the new attribute value will be constructed. Furthermore, the resulting translated syntax of the combined attributes MUST be the same as the attribute being mapped. 🧩
- A DUA MUST support mapping of attributes using the attribute OID. It SHOULD support attribute mapping based on the attribute name. 🆔
- It is recommended that attribute mapping not be applied to parents of the target entries.
- Attribute mapping is not recursive. In other words, if an attribute has been mapped to a target attribute, that new target attribute MUST NOT be mapped to a third attribute. 🚫
- A given attribute MUST only be mapped once for a given service. ☝️
Example:
okay picture this 🎀 A DUA is acting for an email service. By default, the "email" service uses the "mail", "cn", and "sn" attributes to find mail addresses. BUT the email service is deployed somewhere that uses "employeeName" instead of "cn", and it uses the "email" attribute for addresses instead of "mail". So you map "cn" to "employeeName" so the DUA can search with "employeeName" in the search filter instead of "cn". And you map "mail" to "email" for getting the address back. You do this by adding the attributeMap attributes to the configuration profile entry, like this (written in LDIF [RFC2849]):
attributeMap: email:cn=employeeName
attributeMap: email:mail=emailAlso, the DUA MAY map a single attribute to multiple attributes 🧠 When one attribute maps to more than one attribute, the new syntax or usage of the mapped attribute has to be intrinsically defined by the DUA's service.
attributeMap: email:cn=firstName lastNamein that example, the DUA makes the new value by building a space-separated string out of the values of the mapped attributes. For this to work, a special mapping has to be defined so a proper search filter can be built 🔍 For more on this example, check out Appendix A.
another way multiple attribute mapping can show up is when you're building returned attributes. Say every email address has the guaranteed syntax "uid@domain". In the directory, the uid and the domain are separate attributes. The email service can say that if "mail" is mapped to two different attributes, it builds the email address by concatenating those two attributes (uid and domain) and putting an "@" character between them 💌
attributeMap: email:mail=uid domainNote: the attributeMap attribute only holds a list of attribute names that should be mapped. It does NOT define how the syntax translation actually happens. How the translation runs (like turning a uid into a DN) and/or how multiple values get joined into the target syntax (like in the email example above) is up to the service. The attribute list in the attributeMap just gives the attributes that get used as inputs to the translation function the service provides. Not the same thing, bestie 🙃
4.8. Interpreting the searchTimeLimit Attribute ⏱️
Interpretation:
the searchTimeLimit attribute sets the maximum time, in seconds, that the DUA SHOULD allow for a search request to finish ⏳
Syntax:
defined by OID 1.3.6.1.4.1.1466.115.121.1.27 [RFC4517] 🧾
Default Value:
if the searchTimeLimit attribute isn't defined or is zero, the DUA SHOULD NOT enforce the searchTimeLimit 🫠
Other attribute notes:
this time limit only counts the time needed to perform the LDAP search operation. Other operations don't need to be counted as part of the search time. For the LDAP bind operation, see bindTimeLimit 💅
4.9. Interpreting the bindTimeLimit Attribute 🔐
Interpretation:
the bindTimeLimit attribute sets the maximum time, in seconds, that a DUA SHOULD allow for the bind request to finish when it's done against each server on the preferredServerList or defaultServerList 🤝
Syntax:
defined by OID 1.3.6.1.4.1.1466.115.121.1.27 🧾
Default Value:
if the bindTimeLimit attribute isn't defined or is zero, the DUA SHOULD NOT enforce the bindTimeLimit 🙃
Other attribute notes:
this time limit only counts the time needed to perform the LDAP bind operation. Any other operations don't need to be part of the bind time. For the LDAP search operation, see searchTimeLimit 🔁
4.10. Interpreting the followReferrals Attribute 🪄
Interpretation:
if set to TRUE, the DUA SHOULD follow any referrals it discovers ✅
if set to FALSE, the DUA MUST NOT follow referrals 🚫
Syntax:
defined by OID 1.3.6.1.4.1.1466.115.121.1.7 [RFC4517] 🧾
Default Value:
if the followReferrals attribute isn't set, or is set to an invalid value, the default value is TRUE 💜
4.11. Interpreting the dereferenceAliases Attribute 🦋
Interpretation:
if set to TRUE, the DUA SHOULD enable alias dereferencing ✨
if set to FALSE, the DUA MUST NOT enable alias dereferencing ❌
Syntax:
defined by OID 1.3.6.1.4.1.1466.115.121.1.7 🧾
Default Value:
if the dereferenceAliases attribute isn't set, or is set to an invalid value, the default value is TRUE 🌈
4.12. Interpreting the profileTTL Attribute ⏰
Interpretation:
the profileTTL attribute defines how often the DUA SHOULD reload and reconfigure itself using the matching configuration profile entry. The value is in seconds ⏲️ Once a DUA reloads the profile entry, it SHOULD reconfigure itself with the new values. Fresh settings, no drama 🫶
Syntax:
defined by OID 1.3.6.1.4.1.1466.115.121.1.27 🧾
Default Value:
if not specified, the DUA MAY use its own reconfiguration policy 🍓
Other attribute notes:
if the profileTTL value is zero, the DUA SHOULD NOT automatically reload the configuration profile. No auto-reload for you 🙅♀️
4.13. Interpreting the objectclassMap Attribute ✨
Interpretation:
okay bestie, so a DUA MAY do object class mapping for every LDAP operation a service runs, as long as that service has an objectclassMap entry 💅. The mapping is specific to each service inside the DUA, so a "serviceID" is required as part of the syntax. Not every DUA service has to do the same object class mapping 🌸
Object class mapping SHOULD be used alongside attribute mapping, so the schema a service expects gets translated into an equivalent schema that actually exists in the directory 🦋
Object class mapping may or may not be required by a DUA. The objectclass attribute often shows up in search filters. Section 4.7 recommends that attribute mapping NOT be applied to the serviceSearchDescriptor 🙈 So if the default object classes aren't used in a deployment, usually only the serviceSearchDescriptor needs to be defined to show that mapping. But if there's no service search descriptor and the service's default search filter contains the objectclass attribute, that filter SHOULD be redefined by object class mapping, if one is defined. If a default search filter isn't used, it SHOULD be redefined through the serviceSearchDescriptor. If a serviceSearchDescriptor is defined for a particular service, it SHOULD NOT be remapped by either the objectclassMap or attributeMap values 🔥
One situation where the objectclassMap SHOULD be used is when the DUA is providing gateway functionality. Here the DUA is acting on behalf of another service, which might pass in its own search filter. In this kind of DUA, the DUA may alter that search filter using the appropriate attributeMap and objectclassMap values. It's also assumed that no serviceSearchDescriptor is defined in this case ✨
Syntax:
objectclassMap = serviceID ":" origObjectclass "=" objectclass
origObjectclass = objectclass
objectclass = keystringThe values of origObjectclass depend on the type of DUA Service using the object class mapping feature 🧚
Default Value:
The DUA MUST NOT remap an object class unless it is explicitly defined by an objectclassMap attribute. Main character rules 👑
Other attribute notes:
A DUA SHOULD support object class mapping. If it does, the DUA MUST support mapping of object classes using the objectclass OID. It SHOULD also support object class mapping based on the object class name 💜
It's assumed the serviceID is unique to a given service within the scope of the DSA 🌈
Example:
Say a DUA is acting on behalf of an email service. By default, the "email" service uses the "mail", "cn", and "sn" attributes to find mail addresses in entries created with the inetOrgPerson object class [RFC2789]. But this email service is deployed in an environment whose entries use the "employee" object class 😭 In that case, "cn" can be mapped to "employeeName", and "inetOrgPerson" can be mapped to "employee". That way the DUA can run LDAP operations on the entries that actually exist in the directory. The mapping is set up by adding attributeMap and objectclassMap attributes to the configuration profile entry, like this (written in LDIF [RFC2849]):
attributeMap: email:cn=employeeName
objectclassMap: email:inetOrgPerson=employee4.14. Interpreting the defaultSearchScope Attribute 🔍
Interpretation:
When a DUA needs to search the DSA for information, this attribute gives the "scope" for that search 🎯 The serviceSearchDescriptor attribute can override this parameter. See Section 4.6.
Syntax:
scopeSyntax = "base" / "one" / "sub"Default Value:
The default value for the defaultSearchScope SHOULD be defined by the DUA service. If a service's default search scope isn't defined, then the scope SHOULD be for the DUA to perform a subtree search 🌳
4.15. Interpreting the serviceAuthenticationMethod Attribute 🔐
Interpretation:
The serviceAuthenticationMethod attribute sets up an ordered list of LDAP bind methods to use when trying to contact a DSA for a particular service 💌 How this attribute is interpreted and used is the same as Section 4.4, just scoped to each service.
Syntax:
svAuthMethod = serviceID ":" method *(";" method)Heads up: even though the syntax lets you list several authentication methods, at most one of each type is allowed 🙅♀️
Default Value:
If the serviceAuthenticationMethod attribute isn't provided, the authenticationMethod SHOULD be followed, or its default 🫶
Other attribute notes:
How the DUA binds to DSAs also depends on the other configuration attributes: credentialLevel, serviceCredentialLevel, and bindTimeLimit. Check out Section 5 for the details on how to bind to a DSA properly 🦋
Example:
serviceAuthenticationMethod: email:tls:simple;sasl/DIGEST-MD54.16. Interpreting the serviceCredentialLevel Attribute 🪪
Interpretation:
The serviceCredentialLevel attribute defines which type(s) of credential(s) the DUA SHOULD use when contacting the DSA for a particular service ✨ How this attribute is interpreted and used is the same as Section 4.5.
Syntax:
svCredentialLevel = serviceID ":" level *(SP level)Refer to the implementation notes in Section 5 for additional syntax requirements for the credentialLevel attribute 📝
Note: even though multiple credential levels can be specified in the syntax, at most one of each type is allowed 💅
Default Value:
If the serviceCredentialLevel attribute isn't defined, the DUA MUST examine the credentialLevel attribute. If there isn't one either, the DUA must follow its default 🌸
Other attribute notes:
How the DUA binds to DSAs also depends on the other configuration attributes: serviceAuthenticationMethod, authenticationMethod, and bindTimeLimit. Check Section 5 for the details on binding properly 🧚
Example:
serviceCredentialLevel: email:proxy anonymous5. Binding to the Directory Server 🚪
The DUA SHOULD use the following algorithm when binding to the server 💖
for (clevel in credLevel) [see Note 1]
if (clevel is "anonymous")
for (host in hostnames) [see Note 2]
if (server is responding)
return success
return failure
else
for (amethod in authMethod) [see Note 3]
if (amethod is none)
for (host in hostnames)
if (server is responding)
return success
return failure
else
for (host in hostnames)
authenticate using amethod and clevel
if (authentication passed)
return success
return failureNote 1: The credLevel is a list of credential levels, as defined in serviceCredentialLevel (Section 4.16) for a given service. If the serviceCredentialLevel isn't defined, the DUA MUST examine the credentialLevel attribute 🔑
Note 2: hostnames is the list of servers to contact, as defined in Sections 4.1 and 4.2 🌐
Note 3: The authMethod is a list of authentication methods, as defined in serviceAuthenticationMethod (Section 4.15) for a given service. If the serviceAuthenticationMethod isn't defined, the DUA MUST examine the authenticationMethod attribute 🫧
6. Security Considerations 🚨
Read this part carefully, bestie. Security is not the place to vibe-check your way through 🙈
The profile entries MUST be protected against unauthorized modification 🔒 Each service needs to think about what it means to put its service configuration into this profile, and it should limit access to the profile entries to match.
Managing the authentication credentials for the DUA is outside the scope of this document, so the DUA has to handle that itself 🗝️
The DUA needs to know how to bind to the directory server properly, so the DSA's access control configuration MUST make sure the DSA can view all the elements of the DUAConfigProfile attributes 👀 For example, if the credentialLevel attribute contains "Self", but the DSA can't access the credentialLevel attribute, the DUA will instead try an anonymous connection to the directory server. That's a total plot twist nobody wants 💀
The algorithm described in Section 5 also has security considerations. If you change that design, you change the security aspects of the configuration profile too ⚠️
DUAs sometimes connect to multiple directory servers to support high availability and/or performance needs 🦋 Because of that, each directory server listed in the preferredServer list and defaultServerList MUST contain the same (replicated) data and be part of the same security domain. In other words, the directory-supported authentication methods, authentication policies, and access control policies for directory data have to be exactly the same across all the defined directory servers 🛡️
7. Acknowledgments 🫶
There were a bunch of other authors on this document too, but we only put one author per company in the heading 💅 From Sun, we want to give a shoutout to Roberto Tam for his design work on Sun's first LDAP name service product and his input on this document 👑 From Hewlett-Packard, we'd like to thank Dave Binder for architecting Hewlett-Packard's LDAP name service product and for his design guidance on this document ✨ We also want to thank Grace Lu from HP for her input and for implementing HP's configuration profile manager code 🌸
8. IANA Considerations 📋
This document defines new LDAP attributes and an object class for object identifier descriptors 🧚 As specified by Section 3.4 and required by Section 4 of [RFC4520], this document registers new descriptors as follows, per Expert Review.
8.1. Registration of Object Classes 🎀
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): DUAConfigProfile
Object Identifier: 1.3.6.1.4.1.11.1.3.1.2.5
Person & email address to contact for further information:
See "Author/Change Controller"
Usage: object class
Specification: RFC 4876Author/Change Controller:
Bob Neal-Joslin
Hewlett-Packard Company
19420 Homestead RD
Cupertino, CA 95014
USA
Phone: +1 408-447-3044
EMail: bob_joslin@hp.comComments: see also the associated request for the defaultServerList, defaultSearchBase, preferredServerList, searchTimeLimit, bindTimeLimit, followReferrals, authenticationMethod, profileTTL, attributeMap, credentialLevel, objectclassMap, defaultSearchScope, serviceCredentialLevel, serviceSearchDescriptor, serviceAuthenticationMethod, and dereferenceAliases attribute types 🌈
8.2. Registration of Attribute Types 📝
okay so this is the registration request for the attribute types, and it's giving very official but also very cute 🎀 here's the whole template exactly as it's written:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): See comments
Object Identifier: See comments
Person & email address to contact for further information:
See "Author/Change Controller"
Usage: attribute type
Specification: RFC 4876
Author/Change Controller:
Bob Neal-Joslin
Hewlett-Packard Company
19420 Homestead RD
Cupertino, CA 95014
USA
Phone: +1 408-447-3044
EMail: bob_joslin@hp.com
Comments:
The following object identifiers and associated attribute
types have been registered.
OID Attribute Type
-------------------------- ---------------------------
1.3.6.1.4.1.11.1.3.1.1.0 defaultServerList
1.3.6.1.4.1.11.1.3.1.1.1 defaultSearchBase
1.3.6.1.4.1.11.1.3.1.1.2 preferredServerList
1.3.6.1.4.1.11.1.3.1.1.3 searchTimeLimit
1.3.6.1.4.1.11.1.3.1.1.4 bindTimeLimit
1.3.6.1.4.1.11.1.3.1.1.5 followReferrals
1.3.6.1.4.1.11.1.3.1.1.6 authenticationMethod
1.3.6.1.4.1.11.1.3.1.1.7 profileTTL
1.3.6.1.4.1.11.1.3.1.1.9 attributeMap
1.3.6.1.4.1.11.1.3.1.1.10 credentialLevel
1.3.6.1.4.1.11.1.3.1.1.11 objectclassMap
1.3.6.1.4.1.11.1.3.1.1.12 defaultSearchScope
1.3.6.1.4.1.11.1.3.1.1.13 serviceCredentialLevel
1.3.6.1.4.1.11.1.3.1.1.14 serviceSearchDescriptor
1.3.6.1.4.1.11.1.3.1.1.15 serviceAuthenticationMethod
1.3.6.1.4.1.11.1.3.1.1.16 dereferenceAliases
Please also see the associated registration request for the
DUAConfigProfile object class.So the vibe is that the registration is for the attribute types, and the OIDs are all listed in that table above 💅 Bob Neal-Joslin from Hewlett-Packard is the person to contact for more info, and the registration request for the DUAConfigProfile object class is the other thing to look at too ✨
9. References 📚
9.1. Normative References 🔒
These are the must-read ones for this spec, bestie 🫶
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510,
June 2006.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512,
June 2006.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006.
[RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access
Protocol (LDAP): Uniform Resource Locator", RFC 4516,
June 2006.
[RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519,
June 2006.
[SASLMECH] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
MECHANISMS", July 2006,
<http://www.iana.org/assignments/sasl-mechanisms>.9.2. Informative References 💡
These ones are good to know but aren't strictly required, so they're the optional extra reading 🌸
[MSSFU] Microsoft Corporation, "Windows Services for Unix 3.5",
<http://www.microsoft.com/windows/sfu/>.
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network
Information Service", RFC 2307, March 1998.
[RFC2789] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 2789,
March 2000.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as
a SASL Mechanism", RFC 2831, May 2000.
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4515] Smith, M. and T. Howes, "Lightweight Directory Access
Protocol (LDAP): String Representation of Search
Filters", RFC 4515, June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 4520, June 2006.Appendix A. Examples 🧁
Okay so this appendix is where we meet a made-up DUA (that's a directory user agent, fyi 🤓) that has exactly one service, called the "email" service. Think of it like an email client that uses an LDAP directory to find email addresses from somebody's casual name 💌
By default, this service expects users with email addresses to be of the "inetOrgPerson" object class type [RFC2789]. It also expects the colloquial name to live in the "cn" attribute and the email address to live in the "mail" attribute, which is exactly what you'd expect from inetOrgPerson 🎀
Here's the special feature 👑 If the "cn" attribute has been mapped to two or more attributes, the "email" service parses the requested search string and maps each whitespace-separated token into the mapped attributes, one by one. Iconic behaviour, honestly 😭
The default search filter for the "email" service is "(objectclass=inetOrgPerson)". When it does a name-to-address discovery, it wraps the search filter inside a complex search filter like this:
(&(<filter>)(cn~=<name string>))Or, if "cn" has been mapped to multiple attributes, that wrapping looks like this:
(&(<filter>)(attr1~=<token1>)(attr2~=<token2>)...)The examples below show how the "email" service builds its search requests based on the defined profile. In every case, the defaultSearchBase is "o=airius.com", and the defaultSearchScope is undefined 🦋 Also, for all of them, we assume the "email" service was asked to find the email address for "Jane Hernandez" 💖
Example 1:
serviceSearchDescriptor: email:"ou=marketing,"
base: ou=marketing,o=airius.com
scope: sub
filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))Example 2:
serviceSearchDescriptor: email:"ou=marketing,"?one?
(&(objectclass=inetOrgPerson)(c=us))
attributeMap: email:cn=2.5.4.42 snNote: 2.5.4.42 is the OID that represents the "givenName" attribute.
In this one, the email service does that <name string> parsing we talked about to make a complex search filter, and the whole thing turns into one search 🔥
base: ou=marketing,o=airius.com
scope: one
filter: (&(&(objectclass=inetOrgPerson)(c=us))
(2.5.4.42~=Jane)(sn~=Hernandez))Example 3:
serviceSearchDescriptor: email:ou=marketing,"?base
attributeMap: email:cn=nameThis example is invalid, because either the quote should have been escaped, or there should have been a leading quote. 🙈
Example 4:
serviceSearchDescriptor: email:ou=\\mar\\\\keting,\\"?base
attributeMap: email:cn=name
base: ou=\\mar\\keting,"
scope: base
filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))Example 5:
serviceSearchDescriptor: email:ou="marketing",o=supercomThis one is invalid too, since the quote wasn't a leading quote, and so it should have been escaped 💀
Example 6:
serviceSearchDescriptor: email:??(&(objectclass=person)
(ou=Org1 \\\\(temporary\\\\)))
base: o=airius.com
scope: sub
filter: (&((&(objectclass=person)(ou=Org1 \\(Temporary\\)))
(cn~=Jane Henderson)))Example 7:
serviceSearchDescriptor: email:"ou=funny?org,"
base: ou=funny?org,o=airius.com
scope: sub
filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))Authors' Addresses 💌
Here are the people who wrote this spec, with their addresses and contact info so you can reach out 🧚
Bob Neal-Joslin (editor)
Hewlett-Packard Company
19420 Homestead RD
M/S 4029
Cupertino, CA 95014
US
Phone: +1 408 447 3044
EMail: bob_joslin@hp.com
URI: http://www.hp.com
Luke Howard
PADL Software Pty. Ltd.
PO Box 59
Central Park, Vic 3145
AU
EMail: lukeh@padl.com
URI: http://www.padl.com
Morteza Ansari
Infoblox
475 Potrero Avenue
Sunnyvale, CA 94085
US
Phone: +1 408 716 4300
EMail: morteza@infoblox.comFull Copyright Statement 🔐
So the copyright here belongs to The IETF Trust, dated 2007 🌈 This document falls under the rights, licenses and restrictions in BCP 78, and apart from what's set out there, the authors keep all their rights.
The document and the info in it are provided on an "AS IS" basis, and the contributor, the organization they represent or are sponsored by, the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes, but isn't limited to, any warranty that using the info won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. Here's the exact wording, because it matters:
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🧠
The IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) that might be claimed for implementing or using this tech are valid or what their scope is. It also doesn't say whether licenses for those rights are available, and it hasn't independently tried to find any such rights either. If you want the procedures for rights in RFC documents, look at BCP 78 and BCP 79 📖
Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses that will be made available, or the results of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF also invites anyone to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💜
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society 🌸
📦 where this page comes from
- ietf: rfc4876 2007-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms