Just Another Odd Error

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.