Updating Name Field on UserPrincipal

Question

When I try to update the Name field (corresponds to the CN) on UserPrincipal (Principal, really), I get an error "The server is unwilling to process the request" on the call to UserPrincipal.Save().

I've checked to make sure there isn't another object in the same OU with the same Name (CN).

The PrincipalContext I'm operating at is the domain root (not exactly at the OU level where the user account exists).

What reason might there be for this error? Is it something that might be security policy related (even though I'm able to update all the other fields)?

using (var context = new PrincipalContext(ContextType.Domain, ConfigurationManager.AppSettings["domain"], ConfigurationManager.AppSettings["rootDN"], ContextOptions.Negotiate, ConfigurationManager.AppSettings["username"], ConfigurationManager.AppSettings["password"])) {
    var user = UserPrincipal.FindByIdentity(context, IdentityType.Sid, "..."); // SID abbreviated

    user.Name = "Name, Test";

    user.Save();
}

The user I am using to create the PrincipalContext has the security rights to modify AD objects. If I update any other of the other fields (e.g. Surname, GivenName), everything works fine.

EDIT:

I've been able to accomplish what I need to do (using ADSI), but I have to run the following code under impersonation. The impersonation code is ugly, and the code below breaks away from the other way I'm updating AD data (using DirectoryServices.AccountManagement), so I'd like to get a better solution.

using (var companyOU = new DirectoryEntry("LDAP://" + company.UserAccountOU)) {
    companyOU.Invoke("MoveHere", "LDAP://" + user.DistinguishedName, "cn=Name\, Test");
}

please show some code... another point: are the permissions you use to sufficient ? — Yahia, Sep 13 '11 at 21:30
The code is fairly simple. I've posted some, nonetheless. The user has enough permissions to make edits to AD objects. — Chris, Sep 13 '11 at 21:49
Thanks - Does this problem come up every time you try it? I am thinking along the line - what if this specific user is currently logged on ? — Yahia, Sep 13 '11 at 21:54
Yes, it happens every time. No, the user is not logged in. In fact, just now I was able to accomplish what I need to, but in an ugly way - using DirectoryEntry instead and calling Invoke("MoveHere", ....). But I want to wait to see if anyone has a cleaner solution. — Chris, Sep 13 '11 at 22:05
try it without any special character like `user.Name = "TestUserName";`... — Yahia, Sep 13 '11 at 22:10
That doesn't matter. UserPrincipal.Name corresponds to the CN attribute - which can have symbols like commas, as long as you escape them. Actually all of the existing user accounts have CNs formatted Last\, First. — Chris, Sep 13 '11 at 22:33
Yes, the text happens to be the same text that is Display Name. But, the CN can be that too. — Chris, Sep 20 '11 at 20:13

Anonymous · Answer 1 · 2014-08-05T11:47:50.177

18

This is a cleaner way

using (var context = new PrincipalContext(ContextType.Domain))
{
    var group = GroupPrincipal.FindByIdentity(context, groupName);
    group.SamAccountName = newGroupName;
    group.DisplayName = newGroupName;
    group.Save();

    var dirEntry = (DirectoryEntry)group.GetUnderlyingObject();    
    dirEntry.Rename("CN=" + newGroupName);
    dirEntry.CommitChanges();
}

edited Aug 05 '14 at 11:47

answered Jan 09 '14 at 12:19

Anonymous

1,015
1
10
14

This is definitely the way a CN change should be done. Cleaner, clearer, and more intuitive. – Onion-Knight Jul 25 '14 at 14:11

score 3 · Accepted Answer · answered Sep 29 '11 at 18:49

3

The only way I've found to do this is in the EDIT section in my question. Basically, you cannot use the UserPrincipal class. There is something special about the CN attribute, and you need to drop down a level and use DirectoryEntry, an LDAP string, and invoke the "MoveHere" ADSI command to rename the user account.

answered Sep 29 '11 at 18:49

Chris

2,959
1
30
46

1

This is true, and the AD snap-in actually hints at why - you can't change the CN in the property sheet, you have to do an explicit "rename". I believe it's because the CN is part of the DN and a lot of routines rely on the DN being stable. An explicit "Move" (or "MoveHere" for rename) is an explicit signal that the DN is about to change. Think of how several rev control systems don't know how to detect renames. It's annoying, but there you have it. It's best just not to bother changing the CN at all, just change the displayName, sAMAccountName, and userPrincipalName. – Aaronaught Nov 10 '11 at 19:11
Well, it's really best to not have the CN based on the person's actual name. If I only had a time machine. :) – Chris Nov 10 '11 at 21:28

Updating Name Field on UserPrincipal

2 Answers2

Linked