With the release of NetIQ Identity Manager 4.0 Support Pack 1 (aka IDM 4.01) some bug fixes, and a few new features were added.

Specifically three partner provided drivers were included, an RSA Driver, a Blackboard driver, and a Google Apps driver.

I discussed some of the new features and bugs fixed in IDM 4.01 in this series of articles:

• New features in IDM 4 and 4.01 - Part 1

• New features in IDM 4 and 4.01 - Part 2

I have been working on a series of articles walking through driver configurations, policy by policy to try and understand what the driver is doing, under the covers.

You can see more of these walk throughs on a Wiki page I maintain to keep them all together: Detailed driver walk through collection.

For this article I would like to start looking at the Google Apps driver in IDM 4.01, that is provided by Consensus Consulting.

First off, this driver is Packaged instead of being a simple configuration, though as I recall since this will run on IDM 3.6 there is still a configuration file available for it.

Packages are the major new feature in Identity Manager 4 and while the end user will never see them, for the folks at the back end working on the drivers they are a huge step forward. Packages allow the developer to break the configuration up into chunks as small or as large as makes sense and to release versioned files for each Package. This way there can fix a minor typo in a Policy and distribute it as the 1.0.1 version of the Package without trying to write a convoluted TID explaining how to fix this minor error or issuing a new configuration file which requires all the customizations to be reapplied.

You can read more about Packages in this series of articles:

• Let's talk some more about Packages in Designer 4 - Part 1

• Let's talk some more about Packages in Designer 4 - Part 2

• Let's talk some more about Packages in Designer 4 - Part 3

• Let's talk some more about Packages in Designer 4 - Part 4

• Let's talk some more about Packages in Designer 4 - Part 5

• Let's talk some more about Packages in Designer 4 - Part 6

• Let's talk some more about Packages in Designer 4 - Part 7

• Let's talk some more about Packages in Designer 4 - Part 8

• Let's talk some more about Packages in Designer 4 - Part 9

The prefix for their package is NOVLGGL so most of their policy objects will begin with that prefix.

A base install includes a fair number of Packages:

• Account Tracking Common (from NetIQ's general package set)

• Google Apps Account Tracking

• Google Apps Base

• Google Apps Configuration

• Google Apps Contact Package

• Google Apps Entitlements

• Google Apps Groups Package

• Google Apps Managed System Settings (like Account tracking mostly from NetIQ, but has a minor customization)

• Google Apps Organizational Units Package

• Google Apps Password Settings

• Google Apps User Package

• Password Synchronization Common

Looks like quite the handful, but in reality by breaking it up this way it allows for a simpler driver. For example, if you want to synchronize Contacts, Users, Org Units, and Groups to Google, then you need all the above Packages. But you can ignore the ones you do not intend to sync and then there is no need to modify the filter, the absence of the Package is enough. (Either you removed it or did not install it in the first place).

You can also see five Packages related to basic functionality common to all drivers.

• Account Tracking Common

• Google Apps Account Tracking

• Google Apps Managed System Settings

• Google Apps Password Settings

• Password Synchronization Common

For both Account Tracking and Password Synchronization it looks like the default NetIQ provided Packages have almost enough, but still there is some minor tweak required in both cases necessitating the Google Apps Package version of each.

The benefit to using the NetIQ provided packages is that when a bug is found and a fixed Package is released (which has already happened for the Password Synchronization package since the release of IDM 4) you can easily upgrade the NetIQ provided content instead of having to wait for Consensus to figure it out and back port it into their Package.

This is a great approach, and I am glad to see it working. In fact as I looked at the Password Synchronization, I was convinced that this included the Command Transform rules (both channels, and a rule it each of the Input and Output Transform policy sets), a filter extension, and I assumed the Global Configuration Variables needed. But in fact when I looked at the GCV settings, there are Google Apps specific ones, and it looks like the NetIQ package expects the GCV's to come from a driver specific package. Again this is a clever approach, segmenting the packages as makes sense.

In the case of Account Tracking, this is the stuff that sends Identity stuff into Sentinel for Identity Injection, which is very cool. Sentinel is an event collector and correlator which if you add enough data sources can be amazingly powerful. What the Account Tracking adds is information in Sentinel about what other accounts you have. So if your system detects a packet through the firewall that is a bit suspicious but is targeting a particular system, and then you see a suspicious event on that system, with a specific account, then maybe it would be best to know what other systems might be vulnerable if the password is compromised. Well now Sentinel knows about all your accounts, basically by setting the DirXML-Accounts attribute in the Identity Vault which is synchronized to Sentinel via a driver. For reporting this can be useful to decide how vulnerable a compromised account might be and so on, as you might imagine. However you use it, it adds useful additional information to the Sentinel system.

Anyway you can see that they use the standard Account Tracking Common package from NetIQ but add on additional things needed in their own Package. This is the embrace and extend approach, which is probably the best way to go. The other option would be to include all the NetIQ content in your single package, but as mentioned in the case of the Password Synchronization Package that would mean if NetIQ releases an updated Package then they need to reverse engineer the fix and apply it to theirs.

When you go to create a new driver from a Package for Google Apps, you select the base package. This then shows you the available packages you can choose from.

• Google Apps Account Tracking

• Google Apps Contact Package

• Google Apps Groups Package

• Google Apps Managed System Settings

• Google Apps Organizational Units Package

• Google Apps User Package

Interestingly, the way they include the Account Tracking Common package is via a Dependency in their Google Apps Account Tracking package. Same for Google Apps Configuration, included due to dependency.

The Groups package requires the Entitlements package, the User Package requires the Password Sync (common and Google Apps provided).

As you continue with the import you get asked some basic connection information, in terms of Remote Loader, Administrative Google Apps User name and password, Account Tracking realm, User Placement in Google, Managed Systems info, Password settings, and Entitlement settings.

The driver configuration has basically two settings, one for the Publisher heartbeat and one for password hashing into Google.

This is basically an Subscriber only driver, since there is no event system to get events out of Google at this time. (Who knows what the big G will do in the future). Thus this driver pushes users, groups, organizational units, and passwords in Google and that's about it.

Lets start with the Subscriber channel and the Event Transformation policy set.

There are three policy objects, all from different packages, acting as scoping rules, one for Contacts, Users, and Groups.

• NOVLGGLECNTC-ScopingPolicy

• NOVLGGLEGRPS-ScopyingPolicy

• NOVLGGLEUSER-sub-etp_ScopingPolicy

NOVLGGLECNTC-ScopingPolicy

For the first policy, it scopes to DirXML-GAContact objects. This pattern is repeated throughout, where the first rule breaks if the class is not the one of interest.

This implies that Contact objects to sync to Google is basically a class of its own. I imagine, if you wanted to use other object classes you would have to go modify the driver a fair bit to have this happen. I find it interesting they chose their own class instead of just leveraging the contact class or something already existing. That would be interesting to hear the reasoning.

This is scoped with an if source DN not in subtree \$dirxml.auto.treename$\$idv.dit.data.users$ which uses the Tree Name GCV and the Users container GCV. It turns out that the tree name part is not needed. The way backslash notation works in Identity Manager is that if you start with a leading back slash, then you need the Tree name. Otherwise it is ok to ignore it.

I.e.

\TREE\DC\O\OU\OU\user is the same path as DC\O\OU\OU\user

It is interesting that the Contacts are expected to be in the User container. Good news is that changing this a bit is pretty easy.

NOVLGGLEGRPS-ScopyingPolicy

This is the same as the Contact example, just using the idv.dit.data.groups GCV instead of the users one and focused on Group objects.

NOVLGGLEUSER-sub-etp_ScopingPolicy

Users are the same as the Contact rule, since the Contacts are expected to be in the User container, based on the GCV.

What is additionally interesting is what is NOT excluded or scoped here. Did you notice? Took me a couple of looks before I noticed. The Organizational Unit object class is not scoped here. Interesting.

• NOVLGGLECNTC-MatchingRule

• NOVLGGLEGRPS-MatchingRule

• NOVLGGLEORGU-MatchingRule

• NOVLGGLEUSER-sub-mp_MatchingRule

NOVLGGLECNTC-MatchingRule

First up is break in not a DirXML-GAContact, then repeat the scoping rule from the Sub-Event. This ought to be handled by the Event Transform already so I wonder why the second instance of this rule.

Then a match is attempted by Email address, (which is Internet EMail Address (EM in EMail is not a typo in the policy, its a decades old typo in schema that has never been fixed. Email Address is a different attribute in Schema). It kind of makes sense that email be used, since from Google's perspective, email is everything.

NOVLGGLEGRPS-MatchingRule

Groups follow the same pattern, break if not a group, scope it to the Group container by the GCV, and then something different!

The rule, Prevent Groups without a Google Create Group Entitlement. tests to see if we need to require Entitlements.

There are several GCVs involved:

gcv.NOVLGGLEGRPS.RequireCreateGroupEntitlement
gcv.NOVLGGLEGRPS.MatchGroupsWithoutGroupCreateEntitlement

This is a nice level of control, since creating and matching existing users are two slightly different things, and there are times where you want to block new creates, but if they somehow already exist you have to accept the fait accompli and live with it. In which case it is better to match and control it, then to leave it alone.

Then if the entitlement for Google Apps groups, NOVLGGLEGRPS-GroupProvisioning is not available then veto.

The "if entitlement available" condition is an interesting one, as this is actually the equivalent of the Attribute token, as it has the combined features of Operation Attribute and Source Attribute. You can read more about the various Attribute tokens in these articles:

• The different attribute options in Identity Manager

• The various Attribute tokens in IDM Policy

And more about Entitlements in this series of articles:

• Talking about Entitlements - Part 1

• Talking about Entitlements - Part 2

• Talking about Entitlements - Part 3

• Talking about Entitlements - Part 4

Basically if the Entitlement is being granted in the operation document that is good enough. If not, it queries back to the source to see if a Granted entitlement exists there already. It is worth noting that a revoked Entitlement is a Path syntax attribute with a nameSpace component set to 0, vs 1 for Granted. Thus this is a smidgen more subtle of a test that the standard 'available' test. That is, you could have the attribute, for the right entitlement, but the state is 0 not 1, and therefore that is not 'available' in the Entitlement context.

Finally the last rule matches for any object whose CN value matches. I suspect that Google may not handle Object Classes as well as eDirectory does, in the context of this IDM driver.

That gets us through the Matching Policy set and in the next article I will start working on the Create policy set. Stay tuned for the next articles in this series.