When they released Identity Manager 4, I had a lot of fun working through all the new stuff and I wrote a couple of articles looking at what is new in IDM 4, and what came with previous releases.

• Series: What has changed between Identity Manager versions

• More on what's new in IDM 4

Those articles addressed some of the new things added at a somewhat higher level of detail.

One of the core new features in IDM 4 is support for something called Packages. These are a great new idea, and you can read more of my thoughts about them in this somewhat long series of articles:

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

These are so core to the IDM 4 project that in fact, there are literally almost no other new features added the engine, other than those needed to support Packages. The one exception that I am aware of is down below a little bit (the new GCV).

One of the other major high level features added was the Reporting module, which needs a couple of drivers to support the Reporting module in quite a bit of detail, in the following series of articles:

Data Collection Service:
Series: Data Collection Service Driver Walkthrough

Managed System Gateway:
Series: Trying to understand the Managed System Gateway driver in IDM 4


With the release of Identity Manager 4 Service Pack 1, there are also new drivers and bug fixes. I thought it would be useful to go through some of the more interesting ones.

Before I begin, there is one thing I wanted to note about the IDM 4 release. So far, beyond the addition of all the things needed to support Packages in IDM 4, there was very little in terms of new features added to the engine. Basically as far as I can tell, the addition of a single new automatic Global Configuration Variable (GCV) is about the sum total.

There is a new GCV which is just like the commonly used dirxml.auto.driverdn which returns the running drivers DN in backslash format (\TREE\o\OU\Driverset\DriverName), we now get dirxml.auto.localserverdn which returns the full DN of the server the driver is currently running on, in LDAP format (cn=DriverName, cn=Driverset, ou=ou, o=o). If you read my series on the Managed System Gateway and Data Collection servers, you will see that there is policy to use this GCV, to do a Source Attribute call to get back the Network Address attribute from the running server, to pick apart and infer the IP address of the server. It is useful if you want to write some self configuring code, such that you do not need to enter a server IP or the like but it can be derived by Policy. I remember lamenting not having this functionality back in the IDM 3.01 days, and I am glad to see it become available.

The service for IDM 4, SP 1 brings with it a couple of other new things as well. First off there are three new drivers for connected systems contributed by various Novell Partners. This is nice going outside the company to get mature drivers made more available.

RSA by TriVir ( http://www.trivir.com )
Google Apps by Concencus ( https://www.concensus.com/ )
Blackboard by Omnibond ( http://www.omnibond.com/ )

You should check out their respective web sites, as TriVir has other drivers and specifically tools for IDM available. Specifically I mean their product IDMUnit which is a great tool for testing your IDM system. Being able to reliably test and validate your system is key to being comfortable with doing upgrades. I.e. If you cannot prove everything is working, how can you validate that your upgrade was successful?

Concensus has a number of other drivers (their Banner driver comes to mind, if you are an educational institute using Banner as your student information system, and they do the SIF Driver as well, in case you are a K to 12 school, and use a SIF complaint Student Information System. Hey they have you covered from K - Grad school at Concensus!). They have been working with this Google Apps driver for a number of iterations and it has matured nicely as it follows the various API changes coming from Google.

The Omnibond guys may seem less obvious, but a fairly impressive number of the built in drivers that have been around for many IDM releases. They already provide the Unix/Linux driver, the AS400 (midrange, i5os, i5 series, etc) driver, the Mainframe drivers (ACF2, Top Secret, and RACF variants), and the Scripting driver. They also have the bidirectional and fan out versions of their various drivers. One of the promised features to come later with IDM 4 was to be fan out versions of some of the existing drivers (like JDBC, and Active Directory) that we have yet to see. The Omnibond guys are the ones who made that a desirable thing! They have done a lot of great work with their drivers, and I am glad to see a new driver from this group. They have a really cool new 'thing' coming, called RaDD, the Rapid Driver Development tool, which is meant to replace the Silverstream Composer product that most IDM folk never saw.

The old Composer tool was basically a data mapping tool, that had a utterly horrendous user interface, but was meant to make it easy to map crazy things to XML documents. So it had a TN3270 screen scrapper to allow you to map things you would do on a green screen applications interface to an XML document and the reverse. Or to screen scrape an HTML web page. Their new tool is designed to replace the discontinued Composer product, since there is a real need for this sort of thing.

The SP1 release also brings the release of IDM 4 Standard Edition. The original release of IDM 4 was Advanced Edition only, which was basically a replacement for IDM 3.6.1 with Roles Based Provisioning Module (RBPM) 3.7. IDM 4 Advanced Edition includes the full RBPM support, whereas Standard Edition does not. It still needs pieces of the RBPM components, as the Reporting Module (as an example) uses the User Applications Roles model to determine who gets access to use Reporting. I.e. To use the Reporting tool, you need the Reporting Manager or Administrator Role. Reporting is still in Standard Edition, but it is stripped down. I have not yet had a chance to see if they stripped out functionality, or just did not include as many reports out of the box in order to accomplish this. My guess is they have something that looks at the license code applied, and determines what the interface will allow. Almost like a second level of permissions.

In addition, as with any new release there are all sorts of bug fixes. Luckily for us, Novell actually publishes a list of bug fixes in a TID (Knowledgebase article, Technical something or other, I have no idea what TID really stands for) and I happen to know some of the story behind a couple of these bugs (or at least what they affect), and thought it would be worth sharing.

The TID I refer to is TID 7008566. You can search at http://support.novell.com for the TID number, or you can try this ugly direct link. Sometimes a link like this will fail the first time, but work the second. I have no clue why that is.

Defects fixed in the IDM 4.0.1 release

I read through this list and picked the ones I thought were interesting.

I think I will work through the list one by one. The first number is the Bug number in Bugzilla (http://bugzilla.novell.com), Novell's bug tracking program. Most bugs are at least partially visible to everyone. (Obviously security bugs are hidden, and some comments and attachments that contain customer data have to kept private.)

671675 Engine-DirXML Script Status document generated thru policy not going back thru output transform

This was one a friend was interested in. You can use the do-status token in Policy to send a status event. One of the more interesting uses a college of mine used this for, was in a SOAP driver, where connections come in, should a bad password be attempted the driver sends a warning email, and then a Status event with a level of fatal. As you really do not want to fool around with bad incoming connections. Sure you have a firewall, but even so, this at least means someone knows before anything bad happens. However, you might want this to process through the output transform, in case you have some custom rules doing stuff there. A SOAP driver is a good example, as you might want to convert the Status event into a SOAP document to let the connected web service that either the event succeeded or failed. But if the status is not going back through that channel it won't work. Now regular Status events were making it through, but if your Policy called a do-status token, it did not. Glad to see it resolved.

659272 Engine-Functionality IDM Engine should provide a LDAP extension for getting the Named Password Value

Named Passwords are a great idea, that showed up in IDM 3.5 or so time frame. IDM already had functionality to store encrypted passwords. For example, the driver object password was actually a standard password attribute on the driver object. However the Remote and Application are encrypted values stored as attributes. Thus IDM has the ability to store and retrieve passwords securely, why not extend it to user specified passwords. Thus we got Named Passwords which can be of immense use. Interestingly enough, we also got a Global Configuration Variable type called password-ref, which is defined as the name of a Named Password for this driver, and when you go to the GCV properties pages, you end up setting the Named Password via the GCV. Well now that we have a mechanism for storing passwords in this fashion, it would be nice to be able to use them elsewhere. Perhaps in an external application? Perhaps in an ECMA function call in RBPM? Of course you could reimplement the IDM libraries in your code to get the password, but allowing an LDAP extension to get the Named Password value, much as there is an LDAP extension that allows retrieval of Universal Passwords (Password Policy allowing only of course) seems like a much nicer way to handle this. Now I need to nag Jim Willeke to add support to this to his Universal Password diagnostic tool. I.e. Make an option to get the Named Passwords from the IDM drivers. Not sure if he will go for it or not, but you never know. Personally I know I have forgotten what value was set in the Named Passwords, and need it for some reason.

655638 Engine-Other Identity Manager trace should show DN of object with existing association.

When you are using a Find Matching User token in the Matching Policy set in a driver, there are a couple of possible outcomes. No match found, and thus you proceed to the create Policy Set and so on. A single match found, in which case Creation and Placement Policy Sets are skipped and on to the Command Transform. There a couple of other possibilities if your matching criteria is not strong enough. It could be that more than one object matches. and there is a funny Unicode character returned as the matched user, so your driver can detect this case and do something in relation to this error case. There could be an existing object that meets the criteria, and is already associated. In that case, the driver returns a message that an object is found that is already associated.

Alas, it does not tell you WHICH object was found that was already associated. So in policy, if you wanted to deal with it somehow you would now have to go and query for it again. Or even if you just wanted to forward an error message on to say the Helpdesk to go take a look at it, you would have the same issue.

Now the driver will return the DN of the object in the error message.

DirXML Log Event -------------------
Driver: \RJ-RC4-RH64\system\driverset1\LDAP
Channel: Subscriber
Object: \RJ-RC4-RH64\data\users\pusery
Status: Error
Message: Code(-9063) Object matching policy found an object that is already associated: data\users\pusery.

I still have a bunch more interesting bugs to discuss so stay tuned for the next part of this series.