User Management with Active Directory—Retrieving tokenGroups from ADAM

Microsoft .NET Framework, ASP.NET, Visual C# (CSharp, C Sharp, C-Sharp) Developer Training, Visual Studio

Retrieving tokenGroups from ADAM

So far, the techniques we have described have applied to Active Directory. However, we may wish to expand an ADAM user’s group membership as well. Additionally, if we are using ADAM in a pass-through authentication scenario where we are authenticating Windows users, we might like to know both their Windows and ADAM group memberships.

It turns out that ADAM also supports the tokenGroups attribute for ADAM users and bind proxy objects. We can use the same techniques we just described for them as well. The only caveat is that we cannot refer to ADAM groups by their sAMAccountName, as they do not have one. We also cannot use any Windows-based techniques for resolving SIDs into names, such as techniques #2 and #3 that we just described. We must use an LDAP search, as shown with technique #1.

ADAM has an additional trick up its sleeve, though. The RootDSE object supports the tokenGroups attribute as well and will provide both the Windows and ADAM group SIDs for the currently bound user. This is especially helpful with pass-through authentication, as there is no actual object representing the user in ADAM in this scenario. What object would we query to read the tokenGroups attribute? The code looks approximately like this:

DirectoryEntry entry = new DirectoryEntry(
  "GC://localhost:389", 
  null, 
  null, 
  AuthenticationTypes.Secure);
 
entry.RefreshCache(new string[] {"tokenGroups"});

We should instantly notice that something is strange here. We are using the GC provider with ADAM and specifying a port of 389 (our ADAM instance’s LDAP port in this case). What gives?

For some reason, the LDAP provider in ADSI cannot retrieve constructed attributes off of the RootDSE object, but the GC provider can. We also do not specify the RootDSE object name in the ADsPath in this case. We are uncertain of the reason, but we know this works.

At this point, the list of group SIDs we read from the tokenGroups attribute may contain both Windows and ADAM SIDs, so we may need to do two passes to resolve them into friendly names. However, we can still use techniques #1, #2, and #3 to do this.