Novell Identity Manager has a large number of pre configured drivers, for the various systems that it can connect together.
However, there are several parts to each 'driver'. There is always a driver configuration file, a driver shim of some kind, and sometimes local services or scripts.
Let's walk through that backwards. The local services or scripts depend on the driver.
For example in one of the simplest cases, the LDAP driver for SunOne requires a plug in to the SunOne Directory server, so that passwords change events can be caught and passed on to Identity Manager engine before they are encrypted and irretrievable. This is similar to how the password filters for Active Directory work.
A more complex example would be the family of drivers from Omnibond that support AS400 (IBM midrange servers. sometimes known as iSeries or i5os), mainframes (RACF, Top Secret, ACF2) and Linux/Unix servers. These use a series of native scripts, (REXX in the case of the AS400, which should be familiar to any die hard Amiga fans! (Amiga REXX or AREXX was the built in scripting language on that platform), shell scripts for Linux Unix driver, and so on).
As an example of a native file, the Notes driver happens to have a Notes database and a replication service (ndsrep) that need to be installed locally.
Second up is the driver shim itself. This has basic functionality responsible for communication with the remote system, via whatever API set it is using. Sometimes this does most of the work, like the addriver.dll shim for Active Directory, and other times, as in the case of the Omnibond drivers, it really just forwards events on to the Remote Loader, which is really doing all the work in native scripts.
Finally we have the driver configurations themselves. There are probably the most complex as they have the most moving parts. For better or for worse, the driver shims are basically black boxes that XML documents flow into, magic happens here, and something flows out. The driver configurations have significantly more touch points for customization, and for doing smart or foolish things.
You can see a great reference to all the things a default configuration can do by reading David Gersic truly excellent series that walks through the flow of policies:
Between versions of Identity Manager, some of the default driver configurations get tweaked, sometimes they get radically changed. From the number of moving parts, it becomes obvious that wrapping your head around everything that is going on can be confusing. Then consider what is involved in an upgrade to a new driver configuration! Without a thorough understanding of what is happening in each version, it is next to impossible to intelligently upgrade. Thus we see older implementations running the newest shims with the bare minimum of changes to the driver configuration. This is a testament to the flexibility of the Identity Manager system, that this works, but it sometimes means new functionality or better approaches are discarded due to the difficulty in upgrading.
Worse than that, the documentation does not address the internal workings of the driver configurations at all. This I see as a serious shortcoming of the documentation, though even as I say that, I acknowledge that writing documentation for this would be very difficult.
Nonetheless this has finally annoyed me to the point where I think it is time we, the community, do something about this lack of documentation.
There is a Wiki page up now:
http://wiki.novell.com/index.php/Detailed_driver_walk_through_collection
I am trying to solicit contributions from others to volunteer to write up an entire driver configuration or a segment of a driver. You can pick to walk through just a single channel, say the Publisher or Subscriber from a driver you are familiar with, or even just one policy set, say the Publisher Command Transform.
I have linked in all the articles I have written or know about with this basic kind of information and would love to get help from others in writing more content to get up there.
Whatever driver you are most familiar with, please, consider writing up even a single policy object that is complex and interesting. The key here is to capture the WHY of the rules. The WHAT of the rules is important, but most people familiar with Identity Manager can figure that out by looking at the code, and maybe some trace. What is equally important is to explain WHY the driver is doing that.
However much or however focused on one minor detail you would like to be, please contribute something. If you have figured out why a particular rule does something that might be otherwise inexplicable, please write it up and submit it. Truly a case of the more the merrier.
There is so much ground to cover (close to two dozen drivers in total, and multiple versions of them floating around, any help is greatly appreciated.
The simplest example I know of that illustrates the WHY is in the Active Directory driver, in the Subscriber Create rules, there is a place with DirXML-ADAliasName is set (this is mapped to the sAMAccountName in Active Directory usually, unless you are using the V5 configuration which for some inexplicable reasons swapped the mapping to userPrincipalName. Well there is an entire topic for someone to write up! Why would you want to do it either way? Pros and Cons?) and it does a replace all on this long line of values. Well it is obvious what it is doing, it is replacing any of these special characters with nothing, (i.e. stripping them out) most likely because they are illegal in a NetBIOS compliant name,
<do-set-dest-attr-value name="DirXML-ADAliasName">
<arg-value type="string">
<token-substring length="20">
<token-replace-all regex="^a-zA-Z0-9\x21\x23-\x29\x2d\x2e\x40\x5e-\x60\x7b\x7d\x7e\xc0-\xf6\xf8-\xff\x410-\x44f" replace-with="">
<token-src-name/>
</token-replace-all>
</token-substring>
</arg-value>
</do-set-dest-attr-value>
Thus the WHAT is pretty clear. The WHY would be, what exactly are the various things being stripped out. Would be nice to have a list of the actual characters in a more readable form that are being removed. This is the sort of thing you need when troubleshooting, that is just plain not written down anywhere I know of.
Another example might be, what are the consequences of a decision made in the driver. Let's use the example of DirXML-ADAliasName mapped to userPrinicpalName versus mapped to sAMAccountName. An overview of where all the differences in the driver configuration would be really handy. This is not a simple, lets just change the Schema Map for User objects, this has cascading affects all through out the driver configuration.
Those who may have read my stuff before will have noticed I complain a fair bit about the documentation, but I like to put my money where my mouth is, thus you can see my contributions of articles at: http://wiki.novell.com/index.php/Geoffrey_Carman's_personal_collection
And now with the Driver walk through Wiki page:
http://wiki.novell.com/index.php/Detailed_driver_walk_through_collection
I hope to gather more such documentation together.
I am starting a series here, walking through one of the more complex drivers, the SAP HR driver. The SAP HR driver is designed to get user data out of the HR module in SAP, as users are hired, terminated, or just modified in the usual ways of an enterprise. Transfers, promotions, demotions, the usual. There is an additional driver, the SAP UM (User Management) driver that is designed to then synchronize those users that HR synchronized into eDirectory, back into the SAP modules they need access to login and use. Also new with the CMP is a new driver to handle the special user module case of the Netweaver portal, which is not compatible with the usual SAP user module approach.
Some other content about the driver so far is available at:
That was all aimed at the Identity Manager 3.5.x versions of the SAP HR driver, though some of the basic stuff still holds true.
With the release of Identity Manager 3.6, there are actually two totally different versions of the SAP HR driver now.
In this article I try to explain what is going on with all the new SAP drivers, that come as part of the Compliance Management Platform (CMP) package:
Basically, with the release of the CMP and Identity Manager 3.6 (since the CMP is IDM 3.6, Sentinel 6.1, Novell Access Manager 3.1.1 and configurations that ties it all together nicely) there are two drivers available for the SAP HR side.
I am working on an article of highlights of the standard SAP HR driver, but have not published it. This series is focused on the SAP HR driver from the CMP, and all the interesting things and changes that is has, over the traditional SAP HR driver. This driver works hand in hand with the SAP Business Logic driver, in order to manage relationships between positions, organizations, and jobs, that SAP HR stores internally, but are difficult to expose externally.
You can read more about this at:
SAP HR Driver and Organizational Management - Part 1
And David Van der Maas' approach to the issue at:
IDM Driver for SAP-HR, Getting the Manager from the OU Objects.
In other words, this is a complex issue, and the standard driver handles a subset of possible cases for managing relationships. The new CMP SAP HR driver, in conjunction with the CMP SAP Business Logic driver take a very different approach to the issue than the standard SAP HR driver did.
The plan is to get some articles out walking through the driver configurations, as they ship with the CMP versions, policy object by policy object in an attempt to get both a big picture (overall) and a detailed low level picture of what is going on. You need the big picture so you understand the planned behavior, and the low level so that when it comes time to trouble shoot an issue, you have an idea of where to look, or even begin looking.
This series will by necessity cover the CMP version of the SAP HR driver, and CMP SAP Business Logic drivers. I will try and get as much as I can in the near future.
Next up on the list will be the SAP UM (User Management) module, which handles synchronizing users in eDirectory, as users, into the various SAP modules they might need access too.
This one has changed quite a bit between Identity Manager 3.5.x and 3.6.x and in very good ways! Used to be in the 3.5 world, you would need one SAP UM driver for each module you wanted to synchronize users into. SAP has a module called CUA (Central User Administration) that can synchronize users between SAP modules, but alas it could not synchronize passwords, making it less useful.
The usual approach for this sort of implementation in the past had been to set up a single SAP UM module synching to the SAP CUA module, and then additional SAP UM drivers, one per module just to keep passwords synchronizing.
With the new 3.6 configurations (not even the CMP configurations) there is more of a fan out driver approach, that allows a single SAP UM driver implementation to handle multiple SAP modules, making it much easier to install and manage. There are actually a number of possible configurations for this new driver, making it much more flexible, but as always, adding to the complexity. The usual trade offs in life.
Stay tuned for the coming series walking through the drivers, and please, consider writing something up yourself and contributing it.
Support
Documentation
Learning Services
Partner Programs