I think digging in and seeing what is new in releases of Identity Manager is a useful thing. The high level What's New that the vendor provides is helpful, but rarely covers the level of detail I am interested in.

With IDM 4.5 there is a TID https://www.novell.com/support/kb/doc.php?id=7016414 that lists all the bugs tagged as fixed in IDM 4.5. I thought it would be interesting to pick out ones I wanted to talk about and discuss what the issue is for each. This way you can get a better feel for what is new in this release.

880874 Engine-Functionality Association migration utility is not fanout aware

One of the new features in the 4.5 release is the use of non-reference association values. The attribute DirXML-Associations uses a syntax known as Path. It was meant to describe a file system object in the directory. It has three components:

- nameSpace
- volume
- path or path.xml

On Netware, and in OES on legacy or NSS file systems, you can grant set a Home Directory attribute to a spot on a file server. The nameSpace component allows you to specify whether this is a Mac, Long name space, DOS, or other file system reference, so that it matches the value in path properly. Now it turns out the valid values were 0-5 or so, but it is actually a 32 bit integer.

Volume allows you to specify the DN of a volume object in the directory. Which is also really a 32 bit integer which references an eDirectory object ID.

Path then gives you space to enter the path on that volume to the file. There is an interesting extra version of this where path.xml is the name of the component, and if used, requires an XML nodeset. It is tricky to work with in that mode but it is useful.

Well this syntax is very handy for many things. (DirXML-EntitlementRef, nrfEntitlementRef). You get a DN, an integer, and a string. What more could you ask for? DirXML-Associations uses 0,1, and 3 in the nameSpace for ignore, associated, migrate states. The volume is the DN of the Driver this association is meant for, and finally the path contains the association value. This way, one attribute can contain everything you need.

However, when you get into epic scale IDM implementations, like in the tens or hundreds of millions of objects, there is a penalty for maintaining all the DN references. For some large customers there was a request for a way to do associations without the DN reference.

Thus in IDM 4.5 for large scale implementations, there is reference-less association mode. It uses an attribute DirXML-AssociationLite, and uses the string based representation that looks like if you had exported it in an LDAP browser. The fields are # (pound/hash) separated. But use the backslash format for the DN (unlike LDAP's reporting in LDAP format) then Path, then namespace, like this:

# qqquser001, data
dn: cn=qqquser001,o=data
DirXML-AssociationsLite: \ACMETREE\novell\DirXML\Driver\DriverSet\LDAPSun#cn=qqquser003,o=novell1#1

This can be enabled per driver in dxcmd, and you can migrate the associations from one format to another. (Which is helpful). However in order to see the menu options in dxcmd, you have to load it with the -u switch to unhide the hidden menu. Then it becomes item 8 on the main menu and gives you the needed options.

Anyway, the fanout drivers use multiple associations to one driver, which was only getting one converted, which was a problem and was fixed. Now it seems that the conversion tool (which is part of dxcmd in case you were looking for it. I should do an article on all the new features in dxcmd.) is fixed to properly convert all of them.

One thing to realize with the DirXML-AssociationsLite is that you lose the benefits of a DN based attribute. Things like a move of the driver set, a rename of the driver or any container along the path will mean you have to go out and fix all your Lite associations yourself. Though I suppose if you had the time you could convert them back to DN based associations, move or rename what is changing, then convert them back.

However, if you are in a hundreds of millions of associated object to need this feature, that seems like an intensely bad idea across the board.

Realize also that if you deleted a driver in the past, all the associations would go poof in a cloud of smoke. Being DN references based, if the DN that is referenced gets deleted, eDirectory cleans up all references to it. Unlike other products (***cough*** Notes ***cough***) I could name. Now that is a bad thing, if you delete an object with 100 million other attributes referencing it, your ndsd process is going to sit at 100% for a long long time cleaning up. However, in smaller implementations this can be a quick and dirty way to clean up a driver and its associations.

You know, I wonder if they updated the LMS (Licensing tool) they use during audits to support this? I hope not! That would be great. Upgrade to 4.5, convert the associations, run the license tool, and look ma, no associations!

888855 Driver-SalesForce - Config All driver packages that use notification panel will need to be updated for 4.5

This is kind of a silly bug. With the move from 4.02 to 4.5, they want the page when you import a package that shows some warning text to mention the specific 4.02 and 4.5 patch level required. I noticed in my series on the PCRS driver config that they use the &ltr;header> nodes to get the text to show on the Prompts screen. That explains why it looks so funny.

I do wish they had a comment style tag you could use instead of having to use inappropriate tags to fake the results.

Some examples of why they do this, is that in IDM 4.02 patch 3 I think, they added two new Policy sets. The Startup and Shutdown policy sets. Objects in these are processed once during the shutdown or startup events of the shim. The PCRS code uses these to manage a Job object and make sure it has sufficient rights. But if you are on an older version of the shim, then you get an Index of bounds error as I discussed in this article:

Bidirectional eDirectory driver – Dealing with a strange error

Thus these packages should be updated to note that IDM 4.5 meets the requirements as well.

809211 Engine-DirXML Script Start Workflow action does not allow to send multiple values to a PRD field

One of the painful things in starting a workflow from policy has been when you need to send multi valued data. The workaround had been to delimit the data somehow, and in your workflow pick it apart as it comes in. This of course means if you had a UI you would have to have Form scripts that took the otherwise normal multi-valued data and concatenate it together so the that the Form sends in the right data to start with. This was kind of painful and needlessly complex. One of the new features in IDM 4.5 is that you can now send in multi valued attribute to a data field that can take multi valued data. I have not personally worked on this, but I was told it is mostly concatenating the data for you as it is sent. This at least takes out a step, but I need to look into this one some more when I have some free time.

768117 Engine-Filters When IDM is running on an eDirectory server, LDAP adds/deletes/modifies slow down drastically

I recall a friend finding this issue that if you had IDM on a server, then LDAP operations could be much slower. If you pointed at a replica in the tree without IDM installed, then it was much faster. This one is marked as resolved which is good, but I am not sure what the resolution actually was. I would be curious to find out what the root cause of this issue was related too. The obvious thing to blame is dxevent and writing events to the TAO file on LDAP operations. There seems to be some kind of interactions with lots of events coming in all at once. Not a lot of details on this one, but hopefully this means they figured out the cause and fixed it.

862465 Engine-Functionality Engine Optimization Issue

This was a bit of a strange issue. A friend of mine reported it and discussed it with me. The engine was looking for a bunch of attributes, around 20, and was supposed to remember it had queried them just a moment ago in the same policy. Instead of remembering that, it was issuing a second query back to eDirectory. This is a serious performance hit, since queries are 'slow' in the world of IDM, better to look at the memory cache. This cache is only meant to persist for the duration of the Policy object, so if you need the same piece of data from an object 4 times, you could store it in a variable yourself, or rely on the engine to do it for you, so that each time you use a Source Attribute token the engine is smart enough to not query again for it.

However in this case they managed to provoke the engine into asking again and again.

One other confusing feature of the engine that this appears to have been related to is the look ahead caching it does. If the engine analyzes the policy and sees that you are likely going to query for several attributes on the current object, then it will actually do a single query at first for all the attributes it thinks you are about to ask for. This way, the one query returns with all the overhead of a query, with all the data you might ask for later. There is not much of a performance difference in returning 2 or 4 attributes of an object. The overhead is in finding the object in the first place. Then the caching will remember the values so that when you get to needing them, they are available faster in memory.

891226 Engine-Functionality Removed engine code that auto config telemetry job

The Telemetry job is deprecated in IDM 4.5 It was a cute idea, build a way to gather stats on the Identity Manager implementation and if permitted send the data back to the mother ship. This would be a good way to gather stats on how the product is being used. With some bad licensing experiences in hand, most people I know were afraid to let it send back data thinking this was a way for the licensing team to identify who to audit. I discussed this with some people at NetIQ and that was not the case, nonetheless the bad taste remained. With 4.5 they gave up on the idea and suggest you delete it during an upgrade from 4.02 that might have it. This bug was specifically about removing the code that created it during the install.

I also checked and was informed that while the Telemetry job is recommended to be deleted, it does not cause problems if you do not. It is just a clean up check since it is no longer used.


816288 Engine-Other Identity Manager engine should upgrade Rhino for current functionality

The JavaScript or ECMAScript interpreter in IDM is actually an implementation of an open source project known as Rhino from the Mozilla guys I believe. Like the updates to Jetty, and JDBM/MapDB libraries discussed in some of the other bugs earlier in this series, this is an update to get the latest classes into the IDM installation. Again this is a good thing. Gets us the latest code, bug fixes, patches, and new features in new releases. I would like to see them document which rev of Rhino is included so we can understand features and limitations, but I did not search for that to see if they are documenting the version.

This is why sometimes your ECMAScript looks good as written, but does not 100% perform as expected in the IDM engine. The Rhino implementation was falling out of date with each release. Now that it is up to date again that should be helpful. These are pretty rare edge cases but worth resolving.

That is about it for this chunk of new features from the list. As I went through, some bugs I initially added to my list were really boring or meaningless, so I ditched them. Some I just could not find out any more information, so I had to let them pass, alas. I still have plenty more to write about so stayed tuned for more in this series.