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.

824398 Engine-Other Trace file permissions forced to 600 on Linux.

A friend of mine opened this bug, and I remember the discussions we had around it. When you enable tracing to a file in IDM, you specify a file name and path. This obviously differs depending on your platform. On NetWare the format was SYS:\logs\addriver.log. On Windows c:\logs\addriver.log and on Unix variants, /var/log/idm/addriver.log.

What is amusing is if you move a driver over to run on a server of a different platform, say Windows to Linux, you get a log file created in the eDirectory DIB directory named c:\logs\addriver.log.

Anyway, on Unix and Linux variants the file permissions default to 600, which is not really useful as it means only root has permission. The requester wanted them to be 640, which would allow the user who owns it to read as well. Alas instead of making this a configuration value, it looks like they just changed it to a hard coded value of 640. That seems a little shortsighted to me. You can see the engine enforcing this, when it says something like this in trace:

[07/09/13 04:00:38.959]:Alumni Email :Restricting file Permission for /var/log/idm/addriver.log

Interestingly enough it often appears in the wrong trace file. That is DriverA's log file is mentioned being restricted in file permissions in the log file of DriverB. More than a little bit odd, but only cosmetic and mostly harmless.

848384 Engine-Other The do-add-role and do-remove-role IDM actions do not support all entities

This was an interesting problem. There are a series of tokens that are really wrappers for SOAP calls. There is the Start Workflow, Add Role, Add Resource, Remove Role, and Remove Resource tokens. These require the URL of the SOAP endpoint, which is of course the base DN of your User App instance. The DN, in LDAP format of your admin user who has permissions in User App, often known as the uaadmin user, and the password.

These tokens under the covers make SOAP calls and implement some functionality that is useful. Personally I would love a more free-form do-soap-action style token, so we can specify the endpoint, the user, the password, and then a SOAP body. Let us build the SOAP body in Argument Builder so that all the cool stuff in IDM is available. If you use IDM Validator for testing (if not, why aren't you? It is neither perfect nor provides 100% coverage of test cases, but it is just about the best thing out there) then you will know that they provide a SOAP event that allows you to build a SOAP document and send it to an endpoint. This way you can handle arbitrary SOAP. They also have a User App connector that knows how to do the usual Start Workflow, Add Role, Add Resource, stuff. But also do SOAP for anything else.

But these tokens are nothing like that. Rather they are very specific to the functions available, and only do what is built into them. Now specifically with the Add Role and Remove Role the token worked fine for assigning a Role (or removing it) from a User. However RBPM supports assigning Roles to more than just Users, it can also support Group and Containers. But to do that, you need to specify a value for a Request Category Type. It happened in 4.02 and earlier that the Add Role token did not expose that option in the SOAP document so all Add Role events were sent with a category type of ROLE_TO_USER_ADD, and there was no way to specify ROLE_TO_GROUP_ADD or ROLE_TO_CONTAINER_ADD.

Quite confidently, if you open the WSDL file, this just happens to be right at the top, as the file defines the RequestCategoryType. My SOAPui instance decided to die on me as I tried to open my User App project for the Roles endpoint to go get the values for this field, so I fell back to the source and looked at the WSDL itself. I figured I would have to search long and hard to find it, but I ended up finding it right at the top.

In 4.5 the Add Role token now adds an option to select if this is to a Group, User, or Container. A nice enhancement. I suppose I should spend the time and figure out if there are any other optional fields in the add role SOAP call that would be useful to have exposed and ask for them, but I am just too busy to bother. What we do when we run into issues like this is make a PRD (Workflow) that calls an Integration Activity where we import the SOAP API we need from the WSDL and define all our fields there and we can call that with a Start Workflow token. You can read about this approach where I discuss setting up a Terminate Workflow approach to match the Start Workflow token.

Using SOAP to terminate a running workflow – Part 1
Using SOAP to terminate a running workflow – Part 2

There was an early bug in 4.5 that did not properly handle this that my boss ran into but it is since fixed I believe in one of the engine patches. What I remember about that is that the error mentioned something like {4} being invalid, which is a dead giveaway that one of the parameters they expected is not properly being provided or processed.


708991 Engine-Reporting Add the trace level setting value to the trace screen (list it every time the engine version is listed)

The request here is to report the trace level for the driver when the version of the driver is shown. It is unclear how they implemented that. I have seen, when a driver restarts that one of the first lines looks like this:

[04/21/15 15:52:19.284]:Notes :Trace Level: 3

This is helpful as it tells you how this driver started at a trace level, but of course it is very easy to change the trace level on the fly. Heck, if you wanted to you could change it via policy. There is an attribute DirXML-TraceLevel on every driver and driver set object. You can easily get the DN of the driver object via the built in GCV dirxml.auto.driverdn, and then read or write back to the driver. You could read it the same way, but that is not entirely effective since the DriverSet value could be set, and if the driver is set to -1, then it inherits from the driver set and you need to do another step. Someone recently showed me a clever way of calling the Java function that the engine uses to return the trace level in policy. That is probably the simpler if more obscure way to do it.

Anyway, it is nice to have so that when you start a driver up, you know what trace level it started with, but since it can change without notice it is not too reliable. This is especially helpful to support, when they know they need to see a level 5 trace, and they get given a level 3 trace, it can be tricky to infer if the things they are looking for a properly missing or missing because of a low trace level. Still easy to fake it out, just change it on the fly, but this is a step in the right direction.

757212 Plugins-DirXML Administration Plugins should not display alert when editing a driver configuration

With the advent of Packages, the IDM plug ins for iManager started warning you every time you touched an object that was packaged that because of packages, you should not do that. It was a good idea in the first release as people got used to packages and how to use them. Now it turns out to be incredibly annoying.

With this release of iManager and the IDM plug ins they changed it so that in each window where you edit content of this type, there is a warning at the top, but not a popup you must click to make go away. This nicely solves the issue of reminding people not to make changes here, while also not getting too in their face.

Designer had a similar bug. I was working with an engineer on a memory leak problem, and it required you to open about 25 Policy objects to generate the leak in a visible way. I told the engineer, that it would faster for him to implement a "Do not ask me again" setting for this, so he could then actually reproduce my bug. I do not know if that is why it showed up in Designer 4.x in an Auto Update, but I like to think that is the reason. Allow me my hubris please.

833516 Plugins-User Password Management Documenting password-length limitations

This one came as a surprise to me. It is a bit of an edge case, but still interesting. It turns out that the LDAP RFC only allows 128 character passwords. NLDAP, the eDirectory module that provides LDAP services to eDirectory properly implements the RFC. NCP allows longer passwords, up to 256 characters, but you cannot use them to login via LDAP. The request in this bug is just to document this issue, since there is no fixing it. The RFC says do LDAP this way, NetIQ does LDAP this way.

This reminds me of other examples of properly following the RFC. There is a Schema syntax called Printable String, which is distinguished from a regular string by basically the disallowing of the semi colon character. It is able to do A to Z, a to z, 0 to 9 and most other characters, but the primary difference is no semi-colons. We had a customer moving from a Sun Directory server to eDirectory and they used a well known attribute that uses this syntax, per the RFC. But Sun did not bother to implement this silly schema syntax that almost nothing uses, instead they just mapped it as Directory String. Close enough right?

Well eDirectory does actually implement it, and they liked to carry a payload of several values in a single string. Guess which delimiter they chose? Of course it would have to be a semi-colon. I have to admit, I spent a long time looking at what looks like a proper string throwing a -613 Syntax error before I figured this out. The solution was easy. New attribute with a less insane syntax, and use the LDAP servers mapping ability to map our new attribute to the old name. As we updated system to use the new attribute it became a non-issue. But that kind of thing can be a head scratcher. Sometimes following the RFC causes problems.

I do not know of a lot of reasonable use cases for a greater than 128 character password that is actually used, but I am sure someone can come up with one. I guess Secure Login, using Secret Store could be an example where only logins via Secure Login, which can read out a randomly generated super long password from the Secret Store for login would be a case. This way you deny access to login in directly not by locking or disabling the account but rather by setting an impossible to type or remember password. Whereas as Secure Login just pumps it in and all is good. But for that, 128 characters is probably plenty.

That is about it for this article. I have one more that is engine based, but I need to ask someone for some details since I know how the issue started, but not how it ended. I will see if I can get that one tracked down for the next article in this series.

But after that, the next sets of bugs referenced are in the RBPM / User Application / Identity Applications space. Followed by Designer bugs. The RBPM ones are much harder to track down information on, but I will see what I can do.

Stay tuned for the next article in this series.