Kevin Won
Kevin Won

Reputation: 7186

LDAP query invalid characters

I'm getting stuck with formatting an LDAP query against my AD. It appears that the '+' character is messing up my life.

the following query works fine for me:

//C# AD lookup

DirectoryEntry group = new DirectoryEntry(
    "LDAP://mydomain/CN=group name that works,OU=Groups,DC=myDomain,DC=us");

but when I attempt to look up a group that has the '+' character in it:

//C# AD Lookup failure with '+' in CN

DirectoryEntry group = new DirectoryEntry(
    "LDAP://mydomain/CN=name+ thatFails,OU=Groups,DC=myDomain,DC=us");

I get a 'Invalid dn syntax has been specified' exception.

I've passed a bunch of valid group names with all sorts of 'special' chars suchas '_' and '&' which work. it appears that the '+' character is what is causing my grief. how do I format my CN correctly to make my query valid?

EDIT

as suggested, I escaped the '+' char. This unfortunately did not help. below is my current ldap format:

LDAP://mydomain/cn=_bigGroup\+ management office,OU=Groups,DC=myDomain,DC=us

Upvotes: 0

Views: 5539

Answers (2)

john
john

Reputation: 1

Connecting to LDAP is possible for specific users only , hence we need to specify the group of users that has access to the LDAP and define them in the Application Pool. When we are creating a new website add this app pool which has the access rights , Unless until u provide a correct application pool, we will get this type of errors.

Upvotes: -1

Mike Marshall
Mike Marshall

Reputation: 7850

Apparently you need to escape some characters with a backslash, see the list here

Update:

The backslash does in fact work. I created a new user object with cn='Escape+Test' in my local ADAM instance (hosted on port 9389). I wrote a small Windows Forms program with the following code:

using (DirectoryEntry entry = new DirectoryEntry("LDAP://localhost:9389/CN=Escape\\+Test,OU=MyUsers Users,DC=TEST,DC=LOCAL", "test", "xxxx", AuthenticationTypes.None))
{
     MessageBox.Show(entry.Properties["cn"][0].ToString());
}

The program displayed "Escape+Test" when I ran it.

Notice the double backslashes to represent an actual backslash and not an escape character. I would expect the same behavior on a full AD domain.

Just as a sanity check I replaced the backslash with %2B as mentioned by another answer and when I did I got a "no such object on the server" error when trying to access the entry's properties.

Upvotes: 3

Related Questions