Directory Programming .NET

The new Account Management classes in .net 3.5 appeared to simplify my code, but an issue arises when I user foreach to iterate over the GetAuthorizationGroups method.  My suspicion is that the class retrieves the tokenGroups constructed attribute under the covers which includes sids in the sidhistory of the user and groups.  As my active directory includes many users and groups migrated from three separate NT4 domains, it appears that the GetAuthorizationGroups meathed assumes all sids belong to the AD domain and crashes when I hit a sid that is from the old domain(s) via sidhistory.

Attempts to trap the errors seem to fail.  I would be satisfied if I could detect the condition and continue the enumeration, but instead, the iteration just appears to stop at that point.  Am I crazy or is there an issue with the GetAuthorizationGroups method where the error is not thrown properly to allow my Try/Catch to detect it and continue?  I tried also to check for the Principal object in my iteration to be nothing, but it appears that it is trying to create a Principal object and it does not cover the condition where a bad sid is involved (eg. it can not get a valid NT style name for the sid?)

Am I doing something wrong or is there an issue that Account Management Classes need to address.  I am getting around the issue by using the DS classes (and more code), but the account management classes would simplifiy things if this issue did not exist.

 

Under the hood, GetAuthorizationGroups actually uses the Windows Authz APIs to get the user's group membership instead of doing an LDAP query for tokenGroups.  The API in question uses RPC instead of LDAP, although it DOES actually end up reading tokenGroupsGlobalAndUniversal out of the directory (needs the same permissions that you would need via LDAP).

My guess is that there probably is a fix that could be done for the error you are experiencing, but it would need to be factored in to the AccountManagement API itself.  The first thing would be to try to make sure they understand the problem and can reproduce it.  After that, you might be able to get a patch.  As to whether that would be practical for you to use from a deployment standpoint would be up to you.

I've seen a number of other people report issues with this API as well for different reasons, so it looks as if it could use some additional tuning and testing in other environments than what the testers originally applied to it.  I still like the idea, but it is clearly somewhat fragile and hard to recommend as a result.

We came across the same problem when using that method also. It was sometimes triggered when using newly created users, sometimes also existing users.

We swiched to using GetGroups instead and haven't had any problems.

From memory the MS chaps said the error details we were getting was related to sid or object identifier. We would have had to replicate it further to give MS something to look at but didn't have time plus we still had a working solution with GetGroups..

It would be nice to know what the problem was though :)

Seeing something similar from AzMan APIs where sidhistory is involved. InitialiseClientContextFromName appears to thow an exception when tokenGroups contains sidhistories. Appears that code is attempting an LDAP lookup and GC returns an LDAP error.

I think they use the same underlying API call in Windows, so this is not surprising. 

Perhaps this could get fixed in a Windows service pack instead of requiring a fix to .NET?  Who knows.

Thank you all for your comments.  I will post to MS to see what happens.  By the way Mr. Kaplan, I use your book so much the the spine broke.