(archived from my old blog from my pre-MS days)
Active Directory is funny.
Or should I say "permissions in Active Directory are funny."
I find that whenever I'm "stuck" on a problem for a good chunk of the day (AD or not) , about 80% of the time it's a permissions issue. A couple of days ago I was stuck on an issue that I knew was a permissions issue, but I couldn't figure out why. I mean, here I was, supposedly something of an development expert in directory services, but I couldn't get my DirectoryServices code to delete a simple AD object. I could create objects, but I couldn't delete them.
Now, at this particular client they've tightened down the screws in their environment substantially, so simply increasing my permissions willy-nilly was out of the question. No domain admin privileges here. I'm not even sure any of the developers on this project even use Active Directory Users & Computers, they seem to only use home-grown LDAP tools for examining AD. They are able to delete items with one particular home-grown tool, but it was written in VB - in all it's COM, late-binding, who-knows-what's-really-lurking-under-this-IUnknown-interface glory.
Has anyone ever tried to peer into the ObjectSecurity class? It's not for the faint of heart. And it wasn't something that I was going to be able to decipher in an afternoon. So I downloaded the old Windows 2003 admin pack, installed it on my XP development box, and went into all the gory details that are AD ACLs.
The question was, why could the old VB code delete the object when my DirectoryServices code not do it? According to AD Users & Computers, the credentials I was using did not have "delete" permission on the object. I knew that. That's what "access denied" usually means. How could I explain this to the fellow who was successfully deleting with the VB code and expected me to do the same? DirectoryEntry.DeleteTree() simply would not work.
However, upon further examination, I could see that the OU that I was dealing with did allow my credentials to create and delete child objects. Hmm... One more quick test confirmed it. Although DirectoryEntry.DeleteTree() failed, with the OU I could do DirectoryEntry.Children.Remove(objectInQuestion). That's just crazy. Boggles the mind. But it works.
Of course, if the AD admins want to save another developer further grief (and there's no reason to believe they would - I know some sadistic infrastructure folks), then they'll just add the delete permission and avoid further confusion.