{"id":108,"date":"2008-03-25T10:43:17","date_gmt":"2008-03-25T10:43:17","guid":{"rendered":"https:\/\/www.wapshere.com\/missmiis\/?p=108"},"modified":"2023-01-16T20:10:02","modified_gmt":"2023-01-16T20:10:02","slug":"group-members-and-other-multivalued-attributes","status":"publish","type":"post","link":"https:\/\/www.wapshere.com\/missmiis\/group-members-and-other-multivalued-attributes","title":{"rendered":"AD Group members"},"content":{"rendered":"

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<\/em> values. So I am now re-releasing the post, with a focus just on member.<\/p>\n

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.<\/p>\n

<\/p>\n

Members are Reference DN values<\/h4>\n

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

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

You can only populate member and not memberOf<\/h4>\n

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.<\/p>\n

You can, however, write to the “member” attribute of group objects, and this is the way you have to do it.<\/p>\n

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.<\/p>\n

You can’t modify reference DN attributes in extension code<\/h4>\n

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.<\/p>\n

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

To emphasise the point: you must generate your membership lists outside<\/em> of ILM, and then sync them directly through<\/em> ILM.<\/p>\n

When Dynamic Groups are not enough<\/h4>\n

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.<\/p>\n

Exchange 2003 brought us dynamic groups – but only for distribution lists, and not security. Pathetic.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Generate the members in SQL<\/h4>\n

Here’s how you might generate the membership lists in SQL:<\/p>\n

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

    For more explanation on how to configure the tables to import group memberships see this post<\/a>.<\/p>\n

    Use Delta tables<\/h4>\n

    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.<\/p>\n

    The basic method is as follows:<\/p>\n

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

      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<\/a>.<\/p>\n

      In Summary<\/h4>\n

      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<\/a>, 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.<\/p>\n

      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.<\/p>\n","protected":false},"excerpt":{"rendered":"

      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…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":[]},"categories":[24,22,34,28,19,5],"tags":[],"class_list":["post-108","post","type-post","status-publish","format-standard","hentry","category-ad","category-groups","category-ilm2007","category-miis2003","category-newbie","category-sql"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pkp1o-1K","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts\/108","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/comments?post=108"}],"version-history":[{"count":3,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts\/108\/revisions"}],"predecessor-version":[{"id":3386,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts\/108\/revisions\/3386"}],"wp:attachment":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/media?parent=108"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/categories?post=108"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/tags?post=108"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}