Conklin Technology Group, LLC IT Architecture. Identity Management. Unix Administration


Microsoft’s Next Generation Active Directory is reporting that Microsoft has announced a new technology that they're calling "Next Generation Active Directory".  It's a "clip-on" -- whatever that means -- that allows directory data to be stored in a SQL database and allows developers to query that data for complex relationships that would normally be difficult, if not impossible, to pull from AD (more accurately, via LDAP queries). 

I'd have to read some more about the new software, and how they're proposing to update the underlying directory data through this "clip-on".  But part of the advantage of LDAP-based directories is that they're *not* relational databases...  It will be interesting to see how Microsoft plans to marry these two technologies and what the real benefit  is for end-users and developers.


Combining dynamic and static groups

After my previous post, I've been trying to figure out some solutions to the scenario I presented (a dynamic email group with opt-in/opt-out capabilities). I got some good suggestions from Matt Flynn and will have a subsequent post with some commercial tools that provide end-user self-service for things like distribution list management in AD or LDAP.

My bigger concern, though, was trying to prove out my little quasi-code example in Sun Directory Server. While the software supports dynamic groups, defined with an LDAP search URL, it seems to be client-specific as to whether those dynamic URLs in the group definition are actually followed (meaning, the users matching the URL filter are returned to the client). I was unable to get a command-line ldapsearch query to successfully return all the members of a dynamic group (suggestions, anyone?). However, by using a combination of managed and filtered roles, instead of groups, it was quite easy to accomplish this.

First, you can define a managed (static) role and manually assign users in. This could be your "opt-in" group -- those users who would like to receive an email newsletter, for example, but would not normally be included automatically based on degree or major or what have you. With a self-service tool, users could add themselves into this managed role as a sort of 'subscribe' functionality.

Secondly, if needed, you could assign an attribute for the opt-out capability. Unfortunately, you can't use the 'nsRole' calculated attribute as part of the filter in the definition of another role. But there are certainly ways around this limitation (extend the schema to include an attribute called 'optout' with the value of the list name, or just use an existing attribute like 'memberof' with a value of your choice). You also can't use the 'isMemberOf' attribute (which is used to return all the static group memberships for a particular user), because, again, this is a calculated attribute.

For reference purposes, here is the filtered role definition I used for testing my example:
nsRoleFilter: (&(sn=Black)(!(memberof=optout_dllist)))

(All users with a last name of "Black", EXCEPT for those who have a memberof attribute set to "optout_dllist")

Once the filtered role is defined, you can then create a nested role with the managed (static) role you created for 'opt-ins', along with the filtered role with users matching a particular criteria (and optionally, excluding those who may have opted out) After the nested role has been defined, you can simply query a given user for the 'nsrole' attribute to see which roles they belong to, or search directly against the 'nsrole=nested_role_dn' to show all the members of the role. Note that you must explicitly ask for the nsrole attribute in an ldapsearch command -- just doing a normal search against a user's attributes will not show their role memberships.

And to save you some of the same headaches that I went through, since a role is defined as a subentry, it is not returned in a normal ldapsearch command. You must specifically ask for them using a search filter like :

For additional information about Roles in SUN DSEE 6.3, the documentation is here.


Open Atrium

As I was searching around the Internet the other day for news about one of my favorite CMS packages (Drupal), I found this interesting project called Open Atrium, from a company called Development Seed.

It looks like they've put a tremendous amount of effort into making an out-of-the-box Intranet solution, based on the Drupal CMS.  I will certainly be installing this, and post back with my thoughts on how it all works.

Filed under: All, Intranets Comments Off

Another use case for good IdM workflows?

While I'm sure UC San Diego will learn all sorts of valuable lessons from this situation, what it should teach everyone else is the importance of establishing proper approval chains for workflows (such as sending out acceptance letters), and a strong business case for some sort of distribution list management tool...


Those crazy rock hounds

I got a great response from Deborah Volk at Identigral regarding my little thought exercise on dynamic opt-in/opt-out mailing lists. In this case, a mailing list for Geology majors, as well as anyone else interested in the occasional spelunking field trip.

Her approach is perfectly valid (and truthfully, makes more sense than what I was trying to do...). Basically, her suggestion is to use the various provisioning mechanisms of an identity management package, like OIM, to maintain the membership of a particular mailing list or group. People could be automatically provisioned into a group at time of account creation, or be event-based, such as someone switching majors. By providing other workflows, such as opt-in or opt-out, users could also add or remove themselves from that static group ad hoc.

What I was trying to accomplish was to put the logic of list membership into the list definition itself. Meaning, if I wanted to send out this week's Geologic Times newsletter, the group membership would be dynamically determined as soon as I hit the "Send" button. Anyone, at that point in time, who was either a Geology major, or had opted in to the list, would then be sent the email.

In summary...

The IdM-centric approach:
IdM workflows provision users into a static group for mailing list membership. The triggers for adding users into this group could be event-driven, such as at time of account creation, or manual, such as an end-user opting in or out of the list. The 'dynamic' part of the list is handled by the IdM software.

The mailing list logic approach:
Using advanced LDAP filters, create a mailing list that would dynamically determine membership at the point in time an email was sent to the list. This would most likely be driven off of attributes or roles assigned to the user objects in a directory store, such as Sun Directory Server or Active Directory. There is no 'group' per se -- it is the LDAP query filter that determines list membership.

Like I said earlier, Deborah's approach makes much more sense, if you have the IdM workflow engine already. However, true dynamic opt-in/opt-out lists are still possible without an IdM solution, but would be more difficult to create and maintain.