December 16, 2009

Setting AD Properties using the new AccountManagement API

So I'm currently programming a lightweight utility to manage LDAP objects and I came to use the new AccountManagement API introduced in .NET 3.5 because it's way easier and more object-oriented than DirectoryServices.

This new namespace, as I see it, is just provided as a friendlier way to query an LDAP server and is actually built on top of the plain DirectoryServices bits. And it shows... For example you have to dispose all objects performing a search (FindIdentity) or as Gary Caldwell puts it:

This call has an unmanaged memory leak because the underlying implemenation uses DirectorySearcher and SearchResultsCollection but does not call dispose on the SearchResultsCollection as the document describes.

Also, because AccountManagement is not as close to the metal as DirectoryServices you can only control whatever Microsoft chose to expose in the API.

However a fantastic feature of AccountManagement is the ability to fall back on a DirectoryServices object whenever you need to because the underlying object of any Principal is exposed through GetUnderlyingObject().

With that much power in our hands we can now use this to set some properties unexposed by AccountManagement. Here's a generic method I made to set LDAP properties on any Principal (users, groups, computers):

Use it like this:

Being user-friendly while keeping control? I'm starting to like that little guy.

UPDATE: As an anonymous commenter pointed out, there's a way to actually map an AD attribute to a property of a class inheriting UserPrincipal. The technique consists of decorating the property with the attribute DirectoryProperty and the field name as parameter (as seen here).

NOTE: code indentation is messy in the examples. I need to fix something in my snippet tool.

Shout it
kick it on


  1. I found good resources of c#. Check this out

  2. Please see figure 13 on This is the correct way of doing this.

  3. I was not aware of those attribute-based extensible metadata.

    Though I would use it only for standard attributes not for custom ones because hard coded attributes could change in the ActiveDirectory.

    I'll update this post and quote you anonymously ;)