Programming Active Directory

[Peter Bradley]

Does anyone here know about programming Active Directory?

We have a problem trying to update Active Directory entries. Let me
give you some background and a scenario.

The distinguishedName for a Student user is of the form:

CN=surname forename (userid),OU=Student,OU=User
Accounts,DC=ourserver,DC=ourdomain,DC=ourcountry

Or something very like that anyway. And no, it wasn't me who designed it.

Let's now say that a student changes surname (gets married or adopted or
something). This is fine for some attributes. But it's not fine for
attributes like cn or distinguishedName. So we can't do (assuming we've
bound to the directory entry above, and created a DirectoryEntry object
called directoryentry):

directoryentry["distinguishedName"] = "CN=newsurname forename
(userid),OU=Student,OU=User Accounts, etc etc";

This gives a COM error saying "Constraint violation" (or sometimes, for
reasons I don't understand, "The server was unwilling to process the
request").

Now, I guess the problem is that if you've connected to the directory
via one distinguished name, trying then to alter it (or the cn) is a bit
like sawing off the branch that you're sat on. However it works in the
VB scripts that we currently have, and there must be a way of doing it.
I can't find it though, and I've Googled my fingers to the bone and read
at least 3 books on AD in an attempt to work out what I need to do.

Is there anyone out there who has any experience of this, or can shed
some light on the problem.

Thanks in advance,

Peter

[Wraith]

I have a great deal of experience with programming for Active
Directory, it's pretty much all I've done for the past three years.

1. I'm currently writing an article to post on CodeProject.com.
Hopefully it'll be done within the week so I'll post it here as well.
It'll contain many useful methods for handling Users/Groups.

2. Some fields are read only, such as the CommonName (cn) and the
DistinguishedName.
If you must edit the CommonName, you must use the method
DirectoryEntry.Rename().

deUser.Rename("CN=newcnName");
deUser.SaveChanges();

For DistinguishedName, it's a little tougher. DistinguishedName
is actually just a calculated path, much like a folder's path in
windows. To change the physical Location of a DirectoryEntry, first
you must initialize a DirectoryEntry pointing to the new location,
then use the DirectoryEntry.MoveTo() method.

using (DirectoryEntry deNewLocation = new DirectoryEntry("LDAP://
CN=OU=Student,OU=User Accounts..."))
{
deUser.MoveTo(deNewLocation);
}

Always close every DirectoryEntry after SaveChanges() to properly
release the underlying COM objects.

Lemme know if you have any other questions.

[Peter Bradley]

Ysgrifennodd Wraith:

> I have a great deal of experience with programming for Active
> Directory, it's pretty much all I've done for the past three years.
>
> 1. I'm currently writing an article to post on CodeProject.com.
> Hopefully it'll be done within the week so I'll post it here as well.
> It'll contain many useful methods for handling Users/Groups.
>
> 2. Some fields are read only, such as the CommonName (cn) and the
> DistinguishedName.
> If you must edit the CommonName, you must use the method
> DirectoryEntry.Rename().
>
> deUser.Rename("CN=newcnName");
> deUser.SaveChanges();
>
> For DistinguishedName, it's a little tougher. DistinguishedName
> is actually just a calculated path, much like a folder's path in
> windows. To change the physical Location of a DirectoryEntry, first
> you must initialize a DirectoryEntry pointing to the new location,
> then use the DirectoryEntry.MoveTo() method.
>
> using (DirectoryEntry deNewLocation = new DirectoryEntry("LDAP://
> CN=OU=Student,OU=User Accounts..."))
> {
> deUser.MoveTo(deNewLocation);
> }
>
> Always close every DirectoryEntry after SaveChanges() to properly
> release the underlying COM objects.
>
> Lemme know if you have any other questions.
>
>
>

Wraith,

That is a great answer. Thanks a lot. I'm sure we now have what we
need to push on - a little further at any rate.

I'm not in work this week (until 2007-04-10, in fact), so I'm copying
your reply to my colleague, Debesh, and I've suggested to him that he
subscribes to the list. I'm sure he'll post if he meets any further
problems,

Our grateful thanks.

Peter