Slash character in AD object distinguishedName

Reading Time: 2 minutes

I was working lately on some code which utilizes Active Directory and I came across problem that trying to access some of objects raised an exception with E_ADS_BAD_PATHNAME message.

After short investigation I found out that this objects for which this exception was raised had slash character in distinguishedName. These objects were representing physical locations and address of those locations was reflected in its name. In result we had distinguishedNames similar to this:

CN=Post at 1/2,OU=Location1,OU=Employees,DC=w2k,DC=pl

Every time when DirectoryEntry object was created and accessed for such object following exception was raised:

Unhandled Exception: System.Runtime.InteropServices.COMException (0x80005000):

Unknown error (0x80005000)

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)

at System.DirectoryServices.DirectoryEntry.Bind()

At first look it may look a little strange, as slash isn't mentioned in MSDN article which deals with LDAP distinguished names and escaping special characters in it. Tools like LDP.EXE or ADSIEdit returned distinguishedName value without any escaping sequence, the same result was when I was reading those values from DirectorySearcher results.

As it turned out slash also has to be treated as special character and escaped in DN path with '\', and we have to deal with it in our scripts or code.

As simply workaround which will give us fail safe solution we can bind with GUID or use ADsPath property value to bind to an object. For object mentioned above ADsPath will contain following value:

LDAP://CN=Post at 1\/2,OU=Location1,OU=Employees,DC=w2k,DC=pl

As we can see all "dangerous" characters are safely escaped with '\'.

In fact I should be aware of this but as I've dealt with objects containing restricted characters before, I've never came across any which contained slash in DN.

So I hope this information will be helpful for beginners or anyone who will have to deal with such objects in future. Those who had to deal with it before probably had already figured it out already.