November 5th, 2004

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).

Author

0 comments

Discussion are closed.