Overview #

Best Practices for LDAP Naming Attributes and Attribute-Names.

All LDAP Naming Attributes should follow the Best Practices For Unique Identifiers for each of the RDNs within the DN.

These recommendations are based on considerable experience within the LDAP and IDM/IAM context. Many of the characters outside of this list will work fine within LDAP; but we have found characters outside of the recommendation may cause considerable effort to interact with the LDAP data, LDIF and other typical Enterprise technologies. You will do best if you use only:

  • A-Z
  • a-z
  • 0-9
  • -


Generally, the obstacles are within one of the following areas:
  • Conflicts within LDAP or vendor server tools that do not properly escape or un-escape characters
  • Readability of data stored within LDAP
  • Ability to perform exports and imports between various LDAP servers or other applications without extensive data conversions.
  • Ability to synchronize with applications without extensive data conversions.
  • Ease of creation of applications that provide access to LDAP data.
  • Characters are considered "unsafe" to be rendered within a URI or URL which may be required or used by applications
  • Auditing Monitoring Metrics Logging may only record UserId values and can create improper identification of the LDAP Entry
  • Which Jane Doe

We outline some of the reasons and specifications that we have used for our decisions below.

RFC 2849 LDAP Data Interchange Format (RFC 2849 Section 4)#

States: "Any DN or RDN that contains characters other than those defined as "SAFE-UTF8-CHAR", or begins with a character other than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. Any value that contains characters other than those defined as "SAFE-CHAR", or begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded.

String Representation of Distinguished Names (RFC 4514)#

By the String Representation of Distinguished Names (RFC 4514) String Representation of Distinguished Names (of which uid or cn are part of the DN), states "..the following characters which need escaping.."
  • SPACE character occurring at the beginning of the string
  • "#" character occurring at the beginning of the string
  • a space character occurring at the end of the string
  • one of the characters:
    • ,
    • +
    • "
    • \
    • <
    • >
    • ;

As many applications do not properly handled escaping of LDAP String Representation of Distinguished Names, these characters should be avoided.

From An LDAP URL Format-RFC 1959: #

"The <dn> is an LDAP Distinguished Name using the string format described in [1], with any URL-illegal characters (e.g., spaces) escaped using the % method described in RFC 1738."

From Uniform Resource Locators (URL)-RFC 1738 #

Many times applications may reference a LDAP Entry as a LDAP URL and therefore each entry may also be subject to the An LDAP URL Format-RFC 1959.

URL Unsafe Characters can be unsafe for a number of reasons.

  • The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs.
  • "<" and ">" - Characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text;
  • the quote mark (""") is used to delimit URLs in some systems.
  • "#" - Character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it.
  • "%" - Character "%" is unsafe because it is used for encoding of other characters.
  • Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. The known characters are:
    • {
    • }
    • |
    • \
    • ^
    • ~
    • **
    • `

All unsafe characters must always be encoded within a URL. For example, the character "#" must be encoded within URLs even in systems that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another system that does use them, it will not be necessary to change the URL encoding.


When using the JNDI to access an LDAP service, you should be aware that the forward slash character ("/") in a string name has special meaning to the JNDI. If the LDAP entry's name contains this character, then you need to escape it (using the backslash character ("\")). For example, an LDAP entry with the name "cn=O/R" must be presented as the string "cn=O
/R" to the JNDI context methods. We have observed that MANY LDAP applications do not properly handle this condition and so we recommend NOT using forward slash character ("/").

Many URL schemes reserve certain characters for a special meaning: their appearance in the scheme-specific part of the URL has a designated semantics. If the character corresponding to an octet is reserved in a scheme, the octet must be encoded. The characters:

  • ;
  • /
  • ?
  • :
  • @
  • =
  • &
are the characters which may be reserved for special meaning within a scheme. No other characters may be reserved within a scheme.

Usually a URL has the same interpretation when an octet is represented by a character and when it encoded. However, this is not true for reserved characters: encoding a character reserved for a particular scheme may change the semantics of a URL.

Thus, only

  • alphanumeric characters
  • the special characters
    • $
    • -
    • _
    • .
    • +
    • !
    • *
    • '
    • (
    • )
    • "
    • ,
  • and reserved characters
used for their reserved purposes may be used unencoded within a URL.

On the other hand, characters that are not required to be encoded (including alphanumeric characters) may be encoded within the scheme-specific part of a URL, as long as they are not being used for a reserved purpose.

Examples of What Happens #

Using Novell's eDirectory, we create a user with a space within their name. A "space" placed in a dn for a "user test" will certainly work within LDAP but when passed through some applications the URL showing the user will be encoded as the RFC states:

Attempt to create an entry as "user_test" fails as it is interpreted as the same named entry as the previously created user which was "user test". (Error -606) An attempt was made to add an object at the same level as a preexisting object of the same name but not necessarily the same class.

Novell's iManager (iMan26_3_20070302) uses the space and the "_" as the same character.

Special Characters #

Some characters have special meaning in a DN. For example, = (equals) separates an attribute name and value, and , (comma) separates attribute=value pairs. The special characters are , (comma), = (equals), + (plus), < (less than), > (greater than), # (number sign), ; (semicolon), \ (backslash), and " (quotation mark, ASCII 34).

A special character can be escaped in an attribute value to remove the special meaning. To escape these special characters or other characters in an attribute value in a DN string, use the following methods:

If a character to be escaped is one of the special characters, precede it by a backslash ('\' ASCII 92). This example shows a method of escaping a comma in an organization name:

CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB 
This is the preferred method.

Otherwise replace the character to be escaped by a backslash and two hex digits, which form a single byte in the code of the character. The code of the character must be in UTF-8 code set.

CN=L. Eagle,O=Sue\2C Grabbit and Runn,C=GB 

Surround the entire attribute value by "" (quotation marks) (ASCII 34), that are not part of the value. Between the quotation character pair, all characters are taken as is, except for the \ (backslash). The \ (backslash) can be used to escape a backslash (ASCII 92) or quotation marks (ASCII 34), any of the special characters previously mentioned, or hex pairs as in method 2. For example, to escape the quotation marks in cn=xyz"qrs"abc, it becomes cn=xyz\"qrs\"abc or to escape a \:

"you need to escape a single backslash this way \\" 
Another example, "\Zoo" is illegal, because 'Z' cannot be escaped in this context.

Pseudo DNs #

Pseudo DNs are used in access control definition and evaluation. The LDAP directory supports several pseudo DNs (for example, "group:CN=THIS" and "access-id:CN=ANYBODY"), which are used to refer to large numbers of DNs that share a common characteristic, in relation to either the operation being performed or the object on which the operation is being performed. For more information on access control, see Directory Server security.

Three pseudo DNs are supported by Directory Server:

access-id: CN=THIS 
When specified as part of an ACL, this DN refers to the bindDN, which matches the DN on which the operation is performed. For example, if an operation is performed on the object "cn=personA, ou=IBM, c=US" and the bindDn is "cn=personA, ou=IBM, c=US", the permissions granted are a combination of those given to "CN=THIS" and those given to "cn=personA, ou=IBM, c=US". 

group: CN=ANYBODY 
When specified as part of an ACL, this DN refers to all users, even those that are unauthenticated. Users cannot be removed from this group, and this group cannot be removed from the database. 

This DN refers to any DN that has been authenticated by the directory. The method of authentication is not considered. 

Avoid the use of Alias Entries#

Alias entries require that Client Applications properly configure a Dereference Policy to perform any Search Request. The Dereference Policy may be difficult on off-the-shelf applications that "hide" the LDAP SDK or settings they are using.

More Information #

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-41) was last changed on 20-Dec-2016 11:17 by jim