Recently Novell shipped Identity Manager 4.0 Advanced Edition. This is a great new release of Novell Identity Manager and has lots of fun new features.

The high level list of new stuff like a small list, but much of the functionality will have really powerful repercussions on how IDM is used in the future.

There are some high level things like two new drivers (well 4 actually, two are needed for the Reporting service) for Sharepoint and Salesforce,com. The Role Mapping Administrator tool is very useful and something that should be really interesting as it develops. The Reporting service will be a great help as well.

Of course there is a new and updated Designer, now at version 4. I started using Designer 4 on a new project I was working on (actually using IDM 3.6.1 since they are not yet licensed for IDM 4) and tried adding a feature that was not supported on a IDM 3.6.1 engine. A pop up box came up (which was a nice warning) with a link to some documentation on new features within IDM 4. You can find the HTML files in your Designer install (assuming you installed it to c:\Program Files\Novell\Designer) at:

file:///C:/Program Files/Novell/Designer4/plugins/com.novell.idm.doc_4.0.0.201009290717/html/app/appversions.html

What I found quite interesting though was this page:

file:///C:/Program Files/Novell/Designer4/plugins/com.novell.idm.doc_4.0.0.201009290717/html/app/appvkeydiffs.html

This listed the main new features added in the different IDM versions, starting with IDM 3.5, through 3.6 and on to 4.0. This I found quite interesting, as I often forget when a feature was added. This is most painful when I have to go back to IDM 3.0 installs and do work. This was so painful I wrote up a set of workarounds for some of the pain points I often encountered working in IDM 3 after using IDM 3.5 and higher in this article:

• Working in IDM 3.0.1 after using 3.5.1

I thought that the table of changed items was sufficiently interesting that it would be worth an article on the topic and take a trip down memory lane.

IDM 3.5 new features:

• New object types were added:
  
  • ECMAScript Objects
  
  
• Jobs

• Mapping Table Resource Objects

• Resource Libraries

• New Policy Linking capabilities where a policy can be in multiple lists

• Many new DirXML Script actions, conditions, tokens, and verbs

• Ability for DirXML Script to nest conditions

• Driver-scoped local variables in DirXML Script that let you refer to variables outside of the policy

IDM 3.6 new features:

• Support for 64-Bit operating systems

• New installation program

• New driver configuration files

• Driver health monitoring

• New ID Provider driver

• Reciprocal Attribute Mapping

• Additional DirXML Script elements

• Nested group support

• User Application

IDM 4 new features:

• Integrated installer

• Packages
  
  
  
  • Installation
  
  
• Management

• New Resource Objects
  
  
  
  • Global configuration resource objects
  
  
• Package prompt resource objects

• DS resource objects

• SharePoint driver

• Salesforce.com driver

• Identity Reporting Module

Lets talk about some of these features. In Part 1 ( What has changed between Identity Manager versions - Part 1 ) of this series, I covered IDM 3.5.

In this article, lets start working through the IDM 3.6 features. IDM 3.6 really was a minor upgrade, not at the same scope as IDM 3.5 was from IDM 3. For example IDM 3.5 added a number of new tokens, whereas in IDM 3.6 fewer were added, though many received subtle tweaks.

Support for 64 bit operating systems is a big boon for IDM. It turns out, that while eDirectory is pretty efficient, and can grow quite large before a 32 bit memory limit starts to be an actual problem, once you throw IDM into the mix, a 2 giga byte process space turns out to feel pretty cramped at times. The problem is that the IDM engine runs inside the eDirectory process space. What that means is that on a 32 bit OS, any single process is usually limited to 2 GB of RAM allocated. eDirectory needs some of that 2 GB for the binaries (which amusingly enough take up 15-20% more memory when running 64 bit, since all references to memory locations need to be twice as large) and usually we would use the rest for DIB cache. That is, a cache of the local directory information base (DIB). Obviously, querying the directory for information that is cached in memory will be faster than reading it off the disk. The good news is that unless your eDirectory tree is monstrous in size, 2 GB is plenty of space for caching. Of course those telecomms with multiple million object trees may find 2 GB quite cramped. Even a 100,000 object tree, can often fit in under 500 Megs of RAM, so you really do have a lot of room available until you get into the ludicrous sized trees.

However, IDM is a Java process, and the JVM, and the JVM's associated memory heap all fall into the eDirectory process space. So on top of the eDirectory binaries, you need to run the JVM. the IDM binaries, and then the remaining space is available for caching the DIB and for use within IDM. As you can imagine, the move to 64 bit platforms, and thus 64 bit memory spaces was a welcome change.

The amazing thing is how much IDM can do with very little memory! For example, the default JVM heap maximum size is 64 Megs, until you change it. Which is another feature in IDM 3.6. Previously you had to edit a file which differed based on your platform. (For Netware it was sys:\etc\java.cfg, Windows it was an environment variable, Unix platforms, it was usually the initialization script to start eDirectory (/etc/init.d/ndsd)). Now it is an option on the driver set, stored in eDirectory, so that when the server running the driver set starts up its JVM, it reads the configuration parameter out of the directory.

But with 64 Megs, most environments run fine. Now as it happens I like doing silly things in IDM. For example, I wrote a series of articles about toolkit rules you could write in IDM:

• Toolkit Rules in Identity Manager Part 1

• Toolkit Rules in Identity Manager Part 2

• Toolkit Rules in Identity Manager Part 3

• Toolkit Rules in Identity Manager Part 4

• Example of a Use for a Toolkit Rule in Identity Manager

• Another Toolkit Rule Use Example, Bad Attribute Value Cleanup

These query for all objects, and end up holding large node sets in memory, which will eat up the available heap space very quickly. But they can be darn useful.

What is a little problematic is that while 64 megs might be enough RAM for running two dozen drivers for day to day transactions, a single migrate event might use up most of the space and cause you a problem.

Thus the ability to trivially set it higher was very much welcomed.

The new installation program was really ho hum for me. Yes, it looks different, but I spend most of my time working in an installed system, instead of installing new systems. I am sure it made all sorts of things better, but I have a hard time getting excited about it. Now as it turns out, in IDM 4 they re-did the installation process yet again, but in a very positive fashion. They split up the install and configuration pieces, and made them scriptable via properties files. This means it is really easy to do scripted installs of IDM 4, which is needed in a cloud like world, where you might want to spin up a new instance for something on the fly. Otherwise it is still pretty hum drum, but useful.

The new driver configuration files are always of interest to me. I think the best way to learn the IDM product is to look at someone elses work and learn from that. I have said it often before that Lothar Haeger's Password Notification Driver should be required reading for anyone learning IDM. You can find it at:

• IDM 3.5 Password Notification Service Driver

• http://www.brummelhook.com/dirxml.html

If you have never looked at it, import it into your Designer, and walk through the policy. You will learn a whole stack of new tricks. As elegant as using an LDAP search function in ECMA Script, which is easy to modify into an LDAP Modify script as well, to the subtle but cool approach to NOT providing admin credentials for that LDAP function. (Short answer: Read Security Equals from the driver, then read that objects nspmDistributionPassword and you have a DN and password that probably has sufficient rights to do whatever is needed in LDAP).

The Resource Kit and Compliance Management Platform (CMP) configuration files also fed into this. Work was done on both those projects, and much of what was learned was passed back to the general configuration files.

Driver health monitoring is a great new feature, that I honestly do not use as much as I ought too. It allows the driver to notice things that are worth doing something about. Like growing TAO files (Suggesting a stuck event, or else more events coming in than can be processed) or driver start/stop events. There is a fair bit you can do with this, and I expect more functionality to get added. If you happen to be running IDM 3.6 and not 3.6.1 please be sure to upgrade, as there was a memory leak fixed in 3.6.1 that will bring the system down very quickly if you enable health monitoring.

The ID Provider driver is another of those features that looks like it came from the CMP project work, and is useful to globally assign ID's throughout your system. In general though I have yet to find a customer needing this directly. Usually we can suffice with simple code to handle it. I probably should spend more time looking at it to see if there are better ways to use it.

Reciprocal attribute mappings are a great addition! If you were not aware, eDirectory has a number of attributes that are sort of paired up. Like how Group membership is handled. It is actually 2 pairs of reciprocal attributes. There is Member written to the Group, (pointing at the User) and Group Membership on the User (pointing at the group). There is also Equivalent To Me on the Group, and Security Equals on the User. Well the engine has been fixing those paired attributes up silently, if you happen to set just one, which is very helpful. With IDM 3.6 they generalized it, and allowed you to define any attribute pairing you want, and the engine will process it for you.

As it turns out, it appears to be quite slow, as it has to do queries in the background after the Command transform in order to fix up the attribute pairs. However, at the time you are setting one of the values, you often know the values needed for the other half of the pair, and adding an Action to set it is quite simple and fast, since there is no additional querying needed. However it is still a useful feature, because it removes the need to be concerned all the time with both halves. Just be sure to manage the one you can easiest and the other will follow in the background.

Next item is additional tokens, but I am not sure which ones were added in IDM 3.6. I do know that structured GCV's were added, and boy are they fun to use. I now look for any excuse to use them in a project since they are so neat! You can read more about them in this article:
http://www.novell.com/communities/node/11480/structured-global-configuration-values-idm

If you are interested in more information about the various GCV types you can read about them in this series:

• Explaining GCVs - Part 1

• Explaining GCVs - Part 2

Nested group support is something I have not really played with either, but I know that you can now get the effective membership list of a nested set of groups, which is quite helpful if you are using it. This would be very helpful in a Lotus Notes/Domino driver where nested groups are commonly used on the Domino side.

Finally they add User Application, as an added feature in IDM 3.6, which is a bit weird since User Application and provisioning have been around since IDM 3.0, growing better and more powerful in each release. I guess they must be referring to the Roles Based Provisioning Module (RBPM) version of User Application, which differs fairly heavily from the previous User Applications of the past.

That looks to be it for IDM 3.6, stay tuned for part 3 where can start looking at IDM 4 new features!