Add memberOf to Global Catalog

[Guest]

I need your help.

I have an application that connects to AD for user information. More specific, the application reads user information like displayName (and a few other attributes) upon login and then checks the group membership based on the user attribute memberOf

This is all fine when the application connects to AD using LDAP/389. In this specific scenario, the application should connect to Global Catalog. And as memberOf isn't available in Global Catalog for the user object, my application can't find any groups for a specific user

Can somebody tell me about the impacts of adding memberOf to Global Catalog

The network is a global AD implementation. It has 30 domains, and 120+ sites all over the world. Some of these sites has pretty small WAN links. Currently, it's a Windows 2000 Native implementation. It will be upgraded in the next few months to Windows 2003.

Will the upgrade change anything in this case

Regards
Mikael

 

[Dmitry Korolyov [MVP]]

memberOf is a calculated attribute, as far as I recall. I'm afraid there may
be problems (wich extra caching of these attribute) if you add it to global
catalog. Looks like we need a AD dev/tech to answer.

--
Dmitry Korolyov [[email protected]]
MVP: Windows Server - Active Directory


I need your help.

I have an application that connects to AD for user information. More
specific, the application reads user information like displayName (and a few
other attributes) upon login and then checks the group membership based on
the user attribute memberOf.

This is all fine when the application connects to AD using LDAP/389. In
this specific scenario, the application should connect to Global Catalog.
And as memberOf isn't available in Global Catalog for the user object, my
application can't find any groups for a specific user.

Can somebody tell me about the impacts of adding memberOf to Global
Catalog?

The network is a global AD implementation. It has 30 domains, and 120+
sites all over the world. Some of these sites has pretty small WAN links.
Currently, it's a Windows 2000 Native implementation. It will be upgraded in
the next few months to Windows 2003.

Will the upgrade change anything in this case?

Regards,
Mikael

 

[Jimmy Andersson [MVP]]

If memory serves (on top of my head), the memberOf attribute is linked to
the member attribute on the group. AD uses the linkId value of two
attributeSchema definitions to calculate the memberOf attribute on the user.

A forward-link attribute on a source object references a target object by
its DN. The back-link attribute on the target object is automatically
calculated and populated with the DN of the source object.
Forward-link and back-link pairs are identified by their linkID property
values. Forward-links have the linkID set to an even number (n) and the
corresponding back-link has its linkID set to n+1 which is always odd.

Regards,
/Jimmy

 

[Guest]

Thank you both for your replies.

After researching the whole day, let me refrase my question

I have now used an LDAP browser (from Softerra) and found the following

- Connect to dc.domainA.company.com:3268 (a sub domain
The memberOf attribute is there, and my application works

- Connect to dc.company.com:3268 (the top domain
No memberOf attribute is there, and my application fails

Of course I need to connect to the top domain to include ALL users in the company

So why is memberOf there in the first case, but not in the second? Can I put it there somehow? How does this relate to the forward/backlink thing for the attribute

Regards
Mikael

 

[Joe Richards [MVP]]

Group membership is handled in a special way, you can not change the
functionality that you currently see.

The guys were correct in that memberof is computed, i.e. flagging it as part of
the PAS will do no good, it isn't information that is replicated around and is
completely dependent on what it links back to, which is the member attribute of
groups. Now that attribute is already part of the PAS but is handled in a
special way as well.

Universal group membership is fully replicated around to all GCs of the forest.
Domain Local Group and Global Group membership isn't. However, since the info
for those groups is available on domain controllers for the domain they exist in
if you query a GC that is a member of the domain where the group lives, the
group will show up in the memberof attributes of any users who are in that group
when quering 3268.

There is no easy way in a multidomain environment to ascertain all group
memberships. The fastest way would be to ask for the tokengroups property of the
user on a GC in every domain. Now take all of the SIDS and convert them to group
names using standard SID to names processes.

The less fast way but doesn't require SID translations is to use the memberof
attribute on a GC from every domain. However, you now have to chase through
group nesting as well (where one group is nested in another there by making the
user by indirection a member of multiple groups). You won't get the primary
group this way though at all. The only way to get that is to grab the
primarygroupid on the userobject. Take the primary group ID which is a RID and
build a complete SID out of that by taking the domain SID and appending the RID.
Now convert that SID to a group name.

 

[Guest]

Thanks for the info, I have learned a lot

Based on this info, I will post a new thread with new questions..

Regards
Mikael