One Scenario Where the System.DirectoryServices. AccountManagement API Falls Down
About a year ago, I wrote a post about Directory Programming with System.DirectoryServices. AccountManagement. I’ve been using the AccountManagement API of the .NET 3.5 framework since then and I still like its simplicity over the raw API of the System.DirectoryServices namespace.
Over the past year, however, I’ve encountered one scenario where I was forced to go back to using the dreadful DirectoryEntry class. This scenario involved managing Active Directory groups for a user. Basic stuff you might say. Now, I want to add that everything works fine if your code is running on a machine that lives within the same domain as the domain controller, which is most of the cases.
However, when the server machine lives in another domain than the domain controller that accommodates the Active Directory you need to manage, then you’ve just stepped into a whole different ball game.
Still, you can be saved when a trust exists between these two domains. If not, then you’re out of luck (and so was I). In this particular scenario, whenever you want to add or remove a user from a group, then the following error is raised:
Information about the domain could not be retrieved (1355).
When you see this error message appearing on your screen, you have two options:
- Investigate whether a trust can be set up between the domain of your server and the other domain where the Active Directory server lives.
- If for security reasons a trust is not an option, then go back and use the old DirectoryServices API’s. They will handle this scenario perfectly, although the readability of your code will suffer.
I can only hope that this gets fixed in the next release of the .NET framework.