AD Group members

This is a repost of an article which was originally about multivalue attributes in general, but with a focus on group members. I realised I had made some generalisations about multivalue attributes which actually specifically apply only to attributes like member, which contain reference DN values. So I am now re-releasing the post, with a focus just on member.

Group population is not the simplest thing to automate, however it is often a time-consuming manual task, and something high up on the priority list for an ILM project. Here are a few points which may help you on your way.

Members are Reference DN values

Groups are populated with links to the member objects, not a text list of names. To manage group memberships in ILM all involved objects must be present in ILM.

So, to put this plainly, if you’re trying to manage a particular group in AD then ILM must know about all its members. It is not possibly to partially manage a group.

You can only populate member and not memberOf

You can’t write to the “memberOf” attribute on user objects. It is something called a “backlinked” attribute, and AD is in charge of maintaining it.

You can, however, write to the “member” attribute of group objects, and this is the way you have to do it.

So it is not possible to manage group memberships by only considering the person (or user or contact) object – you need to manage the group objects as well.

You can’t modify reference DN attributes in extension code

ILM won’t let you write advanced flow rules for reference DN attributes – all you can do is flow them direct from one connector space, via the metaverse, to another.

(Actually I’ve never quite understood why this is, but there you go, we have to live with it.)

To emphasise the point: you must generate your membership lists outside of ILM, and then sync them directly through ILM.

When Dynamic Groups are not enough

Dynamic groups are those ones you want to change based on members’ attributes. Perhaps the group should contain everyone in a particular department, or a building, or with the same manager.

Exchange 2003 brought us dynamic groups – but only for distribution lists, and not security. Pathetic.

Besides, you’re most likely going to need some manually populated groups as well – not everything can be worked out from attribute values. You may also want some groups where most of the members are dynamic, and a couple which are static.

If you’re using SunOne LDAP you can do all this natively… but with AD the membership of all security groups are static, and you need something else to help automate things.

Generate the members in SQL

Here’s how you might generate the membership lists in SQL:

1. Generate dynamic group memberships in a view by directly querying the mms_metaverse table (sample queries to follow in another post).
2. Maintain another table for manually added group memberships (perhaps with a web front-end to manage them; groups can appear in both tables).
3. Concatenate the table and view together.
4. Import using the multivalue function of the SQL MA.

For more explanation on how to configure the tables to import group memberships see this post.

Use Delta tables

You may quickly find that full imports from multivalued tables are too slow – for this reason it is essential that you use delta imports, ie., only import changes.

The basic method is as follows:

1. Snapshot your import table/view;
2. Do a Full import;
3. Next time, take a new snapshot and compare it to the last one to make a Delta Table;
4. Do a Delta Import;
5. Once the Delta Import has completed successfully, clear out the Delta Table;
6. Repeat steps 3-5 ad nauseum.

There is (naturally) a fair bit more to it when you start bringing multivalued attributes into the mix. I’ve written a few posts on the subject in the past, and the best place to start is with this one.

In Summary

I once set up a system that had 6,000 groups and 40,000 users. The group memberships changed continuously – particularly the self-subscriber ones that were updated through the user portal. For efficiency, I separated the multivalued and single valued attributes into seperate MAs, and the multivalued Full Import still took about 5 hours. But by running regular delta imports (every 15 minutes) the list of changes each time was short, and the imports took only a matter of moments.

So while group population and synchronisation with ILM is fiddly, and does use a number of advanced techniques, it is certainly possible to achieve a result that is both effective and efficient.