[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Aliasing entries with reserved characters

Christian Manal wrote:
Am 15.02.2011 08:04, schrieb MJ Hughes:

I'm an LDAP newbie who has inherited the maintenance of an LDAP system, and
am learning on the fly.  Until now I've been able to puzzle out all the
issues I've faced, but finally my google fu has failed me, so I'm seeking
more human assistance.

My problem is with reserved characters, such as , (comma).  The system
wasn't coping with RDNs that contained these characters, but this was easy
enough to fix by simply escaping these characters with a backslash.

My problem now involves trying to alias entries that contain these escaped
characters - I am consistently getting "Invalid DN syntax".  This is what
the code to add the alias looks like:

$operationDN = "aliasedObjectName=" . $this->aliasSafe($aliasDN) . "," .

$aliasParameterArray = array(

"objectClass" => "alias",

"aliasedObjectName" => $aliasDN


$result = ldap_add($this->LDAPcon, $operationDN, $aliasParameterArray);

The aliasSafe() function converts "=" => "\3D" and "," => "\," (unless the
commas have already been escaped).

This produces DNs that have the following (hypothetical) format:

$aliasDN: cn=Tomorrow\, When The War Began,cn=books,dc=library,dc=com

$operationDN: cn\3DTomorrow\, When The War

I've tried every encoding of the comma (in the book name) that I can think
of (eg, a single backslash, a double backslash, a triple backslash, and even
'\2C') but everything I've tried so far has given me the "Invalid DN syntax"
error.  Could someone please help me with the syntax and encoding these DNs
should have?




have a look at RFC 1485 section 2.2:


Double quotes around the RDN will solve your problem.

From <http://www.rfc-editor.org/>:

Number 	More Info (Obs&Upd) 		Status
RFC1485	Obsoleted by RFC1779, RFC3494  	HISTORIC

then there is a long list of obsolescence up to RFC4510, RFC4514 which are the current specs for DN representation; I note that RFC4514 does no longer mention quoting as allowed. The fact that OpenLDAP accepts it is a matter of being friendly to obsolete, istoric clients. Perpetuating that behavior is a Bad Thing. The problem lies somewhere else, I suspect in some inconsistent escaping handling of the language used.