How Can I Work with a CN that Has a Comma in It?

Hey, Scripting Guy! Question

Hey, Scripting Guy! My user accounts have commas in their CN attributes; for example, Myer, Ken. How do I bind to those user accounts using a script? I always get the error message “An invalid dn syntax has been specified.”

-- GT

SpacerHey, Scripting Guy! Answer

Hey, GT. For those of you who don’t know, the CN attribute is the attribute that uniquely identifies a user account within an OU or other Active Directory container. (You can have more than one Myer, Ken in your domain, but you can have only a single Myer, Ken in, say, the Accounting OU.) The CN attribute is also the attribute used to display user names in Active Directory Users and Computers. When you add a user from within Active Directory Users and Computers, one of the fields you typically fill out is labeled Full Name (and then, for some reason, when you later view the user account properties, this same field gets re-labeled Display Name). Administrators like to specify CNs (full names) using the last name, first name syntax; that way, when they look at an OU all the users are arranged in alphabetical order by last name. (If you specified Ken Myer as the full name, users will be arranged in alphabetical order by first name.)

In other words, it’s very common for users to have CNs similar to Myer, Ken. That’s great when you’re working in Active Directory Users and Computers, but not so great when you’re trying to manage these users with ADSI scripts. For example, this script - which attempts to bind to the Myer, Ken user account - will fail with an invalid syntax error:

Set objUser = GetObject(LDAP://CN=Myer, Ken,OU=Accounting,DC=fabrikam,DC=com)
Wscript.Echo objUser.CN

So what’s the problem here? Well, it’s not with the user’s CN; Myer, Ken is perfectly valid. The problem is that when you write a binding string in ADSI the comma is used to separate the individual values within the ADsPath. When we write CN=Myer, Ken,OU=Accounting, our script thinks CN=Myer is the first value, and Ken is the second value. That’s because of the comma between Myer and Ken. And because Ken by itself doesn’t make any sense within an ADsPath, the script blows up.

So what do you about that? As it turns out, the comma is a reserved character when it comes to Active Directory paths. (Other reserved characters include the semicolon, the plus sign, the backslash, and the left and right angle brackets. For a complete list, see the Lightweight Access Directory Protocol documentation on MSDN.)

For most reserved characters, you can use them in binding strings simply by placing a backslash (\) in front of the characters. This script will successfully bind to the Myer, Ken user account and report back the user’s CN:

Set objUser = GetObject(LDAP://CN=Myer\, Ken,OU=Accounting,DC=fabrikam,DC=com)
Wscript.Echo objUser.CN

Again, note how the user CN is specified: CN=Myer\, Ken,OU. After Myer we place a backslash and a comma, then we continue with the rest of the path (including the blank space that separates Myer, and Ken).

Comments (8)

  1. Anonymous says:

    Even worse is when a sys admin uses characters that are valid in some DirectoryEntry fields but not others, e.g. "&" in the group name "Business & Finance". Aspirin required.

  2. Curtis Hotzinger says:

    Wouldn't it be easier to just set the AD display name to LastName comma space FirstName and leave the cn and or LDAP DN alone? You are going to have nothing but binding problems with every ldap server out there and whole bunch of extra code in your scripts.  By having your cn compatible with LDAP standards all you have to do to convert from one to the other is add the prefix LDAP:// to the front of your cn for authentication.  (See the warning on pg 14 of the DOT.NET Developers Guide to Directory Services Programming. author: kaplan,j)  Every AD user interface that I have seen displays the AD displayname, NOT the cn or LDAP name. Users don't see them, just developers.  (Be kind to animals, they write your code!)

  3. Joe Abdall says:

    Thanks… I was going crazy trying to fig out what was going on till I found your post…. Thanks so much

  4. Ed Wilson says:

    @Joe Abdall yes, this is one of those things that can drive one crazy. I generally try to avoid using speces or anything that can "mess" things up. But at least there is a solution.

  5. karthik says:

    I would need to set First Name and Last through variables. Also would need to CN to be in the format of Last_Name, First_Name, but the below code is giving correct result.

    $strUserName = "CN=" + $Last_Name +", "+ $First_Name

    $objADSI = [ADSI]"LDAP://OU=OU1,OU=OU2,DC=abc,DC=def,DC=gh,DC=com"

    $objUser = $objADSI.Create($Class, $strUserName)

    $objUser.Put(“sAMAccountName", $LogOn_Name)


  6. Luis Mendez says:

    This post helped me out, thank you Scripting guy!

  7. Vikram Singh Saini says:

    I got stuck for same in C# code too.

    Fixed as follow –

    // Replace string which contain CN name to fix issue ‘A device attached to system is not functioning’
    strVal = strVal.Replace(",", @",");

    // Rename the user (entry is DirectoryEntry here)
    entry.Rename(string.Format("CN={0}", strVal));

Skip to main content