Just Another Odd Error

Published 09-06-2018 06:13 PM 802 Views
First published on CloudBlogs on May, 08 2008

We get a lot of “huh?” type questions…things that seem so obvious and straightforward that the instant instinctive thought is “well, yeah, of course that won’t work…”

Case in point.

One of my colleagues received a call where a customer was wanting to specify an arbitrary service principal name (SPN) on a service account, but when he tried to do so he got an error.  When using setspn.exe the error was “ Ldap_search_s failed: Invalid DN syntax ”.

Now, SPNs can be in a lot of different formats.  These formats are basically dictated by the developer of the Kerberized application and, when placed in the serviceprincipalname multi valued  attribute in order to advertise that particular server hosts that service.

At any rate, in this case it wasn’t the SPN being specified which was a problem, rather it looked like the error was coming from the DN of the object itself, not the SPN we were trying to add to it.  This reasoning came about since we had a mildly vague reference in a document that said an engineer had once ran into a similar error and the reason was an extra comma used in the distinguished name.

Sure enough, there was one in this case as well.  Picture it like this:

CN= Smith, Billy Bob ,OU=Accounting,OU=Users,DC=Silliness,DC=com

It’s that extra comma in the middle there that was getting us.  A check of our source code showed, sure enough, that a comma or a semicolon in the middle of the relative identifier string is prohibited.  We have a specific check for them.  Simply altering the relative identifier to remove that additional comma using LDIFDE.EXE or a similar tool resolves this problem.

But why on earth would we do that?  I can only speculate that the reason derives from the LDAP RFCs and a bit of programmatic common sense.

The RFC aspect comes from the reference in RFC 4512 put there to disallow semicolons in order to make things consistent in the character usages (paraphrased).

The programmatic common sense portion is that if we are using commas as an accepted character within a relative identifier and we are also using commas as the separator in the distinguished name then we will have to use extra logic to parse the string.  Extra logic or code to do something can sometimes affect performance.  In other words, we have to figure out which comma is a separator and which is not, otherwise we’ll tokenize the string incorrectly.

When it comes down to it there really very little random behavior in Active Directory-just like in the rest of real life, there’s a reason for everything if we simply have cause to dig in deep enough.

1 Comment
Occasional Visitor

But in this case, this is common practice that you need to ESCAPE the comma if that is part the relative identifier, like CN of the object.


So the example of:
CN= Smith, Billy Bob ,OU=Accounting,OU=Users,DC=Silliness,DC=com  


Would look like this escaped:
CN= Smith\, Billy Bob ,OU=Accounting,OU=Users,DC=Silliness,DC=com

And now we would no longer get any Invalid DN Syntax, as this works for just about any application that s using LDAP to access the object.
So this is nothing new or strange behavior.
The really sad part here is, that if you already have code to identify this comma in the relative identifier part, ie like in this example, the CN part, then you are almost done, just escape that comma! And we would not have this problem...

I try to avoid to use SETSPN because of this.

Version history
Last update:
‎Sep 06 2018 06:13 PM
Updated by: