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:
- Generate dynamic group memberships in a view by directly querying the mms_metaverse table (sample queries to follow in another post).
- Maintain another table for manually added group memberships (perhaps with a web front-end to manage them; groups can appear in both tables).
- Concatenate the table and view together.
- 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:
- Snapshot your import table/view;
- Do a Full import;
- Next time, take a new snapshot and compare it to the last one to make a Delta Table;
- Do a Delta Import;
- Once the Delta Import has completed successfully, clear out the Delta Table;
- 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.
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.
6 Replies to “AD Group members”
I was wondering (based on your knowledge on groups) if it is possible to use group membership (lets say AD groups) as a filter for projecting it’s corresponding members into my metaverse, without actually importing that group itself into the metaverse. I know that sounds a bit odd, but I want to provision a certain subset of users from one AD forest, into several other forests, based on their memberships to a certain group, I do not need the group itself, but I cannot see the “memberof” attribute. So I need to think of something else.
unfortunately there is no way to access the memberOf attribute with MIIS (it’s all to do with backlinks).
The only thing I can suggest is that you write a vbscript that populates some other AD attribute based on the group membership. MIIS will then be able to pick that up.
I have the exact same setup as far as the management agent but when I attempt a Full Import Full Synchronizations I have noticed that none of the person objects are set as person objects but as placeholders in the Connector Space. When we view the Account activity through the Activity Monitor on the SQL Server we see the status of Network IO or ASYN_Network_IO as the wait type. I’m watching the traffic being passed in Wireshark and it looks like the SQL server is sending out the data to fast for the ILM application to process. The question is does ILM begin performing joins on those objects immediately or does it wait until it receives all of the results from the database?
First – are we talking about a SQL or an AD MA here?
In either case you must import the user objects as well as the group objects. It sounds to me like you might be just importing groups, in which case the placeholders are created for the missing members.
After reading “Provisioning Based on Group Membership” it looks like the placeholders then joins on the person object is the expected behavior. This is an SQL MA that only manages (projects to mv) 6 of the default AD security groups i.e. Students, FacultyStaff, etc. The primary table lists all possible groups and users with a column called object type that determines if the object is a person or group. Groups are projected where as person objects are joined on their metaverse object. It looks like ILM for joins retrieves all the users, inserts into the Connector Space placeholders for those person objects, and then begins the joins so this behavior is expected. The network IO issue was because the client application (ILM) wasn’t processing the data fast enough for the remote sql server which kept sending the data no matter how many times the ILM server tried to slow it down. I dropped the tables on the local box, setup a DTS package to update them, and the Network IO issue has been resolved.
The question I have now is for the Delta Imports are you using just replacing the primary table with the Delta table/view or are you just using doing a Delta Synchronization?
Sorry for the big post and thanks for all the help,
You need to define a delta table and then you can do delta imports. See my other posts on delta tables, like this one: https://www.wapshere.com/missmiis/sql-2005-ma-export-and-delta-import
Comments are closed.