If you have been using Identity Manager for any length of time, you will have been spending a lot of time using Designer for Identity Manager. Designer is a big improvement over using iManager for everything in some ways, and has some weaknesses in other areas. That is life I guess, nothing is ever perfect.
One neat thing about Designer is that is an Eclipse based application, (Called an RCP (Rich Client Platform) project) that is really Eclipse, slightly repackaged to allow it to run as a standalone application. If you have been using Designer long enough you will remember that it began as an add on to Eclipse and each time there was a new release you would have to install Eclipse and install the plugins on top of that. I forget when they switched to an RCP app, but I suspect it was probably around version 3 something or other.
At that point, it was easy to forget it was Eclipse based. However some people never forgot.
There are a number of plugins people have written for Designer, which are really just Eclipse plugins, specific to Designer.
I thought it would be interesting to review some of them in case people were not aware of them. (My experience is that most IDM folk are NOT aware of these plugins). Some are very useful and some only have minor use cases (though very useful minor use cases).
First up is by a guy whose name I cannot spell properly, so excuse the likely typo, Stefaan Van Cauwenberge.
I highly recommend you go there and look. He has his Generic File Driver, which is just plain excellent and miles better than the NetIQ Delimited text driver. All the pain points in the NetIQ Delimited Text driver are addressed and made much easier and more flexible.
He has a Package Unlocker which is very useful if you have 'lost' ownership of a Package and need to make a new version. He has an association editor which replaces the functionality of DAModifier as a plugin to Designer. There is an Enhanced Trace plugin that I discussed in another article.
The Package Unlocker is worth talking about since it is a fairly simple add on, but one that can be very useful when you really need it.
I am a huge fan of Packages. There is lots of great stuff in them. They are not 100% in coverage of the problem space, but that is ok, they are pretty close. I would say they are pretty close to 95% though, yet that last 5% sure is annoying. As is said, they are good enough for government work.
A subtle and confusing thing about packaging, post Designer 4.01, is that the version string changed from 4.01 to 4.02 and is of the form: 18.104.22.16851108054512
To parse that: 1.0.0 is major version 1, minor version 0, even more minor version 0. This is great since I THINK those are all 32 bit integers so you can have 4 billion times 4 billion times 4 billion versions. In IDM 4.01 that was all you had, just 3 elements of the package version number. Sure it is a large space, but there could be a problem, that once you start working with packages you will understand. If you build a package and release it, it is important that it be unique and there never be a second exact same version of that. To ensure that uniqueness they added in the date and timestamp and it has seconds level resolution.
Where this causes pain, is that if you work with a package, the timestamp is set to the moment you 'created' the package in the catalog. When you deploy, the DirXML-pkGUID will have a string that had the current version number in it.
However, if you finish it, and build it into a JAR, and tick the Release box, you will end up with the current timestamp written to the version. Now if you compare you driver to the tree, you will see that every DirXML-pkgGUID needs to be updated with the new version.
However, once you release a package and hand it to someone else, in a different Designer project, they cannot make a new version, since they do not own it. They do not have Ownership. Now all is not lost, since if you can get a Designer project export and import it into your workspace then you can right click and Request Ownership. Designer then searches the workspace to see if any of the projects claims to own that package. If so, it allows the current project to have ownership and then you can make new versions.
But what if even that is not an option? This is where Stefaan's excellent plugin comes to the rescue. As it turns out, Stefaan noticed that in fact the way that Designer tells who owns a package is somewhat non-obvious. If you look at the properties of a Package you will see a little status box that tells you some info about the Package.
As you can see in the image, this is the JDBC Common package from NetIQ and everything is ghosted out, since when you look at the bottom you can see the "Released" setting is Yes. You can see when it was created, and when it is built and those two differ, and the Built date is what the version string is using up above.
But the clever bit Stefaan figured out is that the Imported setting is actually really important. It turns out Imported means, this came in via Check for Package Updates, or else you imported the JAR file into your catalog. Which makes sense, the Imported flag indicates it was imported.
Ok, so all the packages you imported are flagged as imported. When is it not imported? Turns out that is how Designer knows you own it, since you did not import it, you must have created it here, ergo you own it. Thus all his plugin seems to do is change that one flag, from Yes to No.
Suddenly you now own the package and can make your own new versions of it. Now to be clear, I call this stealing ownership, since it is funnier, but in reality, it does not steal it, since you cannot modify existing packages. You can only make a new version, which you could also do by Copy Package, and rename it. The main benefit of doing it this way is that your new version will show as an Update to the current package. Which is very useful.
This is great when you are working on a team, and you have made a bunch of packages but forgot to make sure someone owns them all in one project and you find yourself otherwise locked out of the Package ownership. Just grab it back.
Very simple, only really adds one menu item but boy is it useful when you need it.
Another neat plugin that he has is the Association Modifier plugin. You may have seen the Windows based tool DAModifier, which was great, but only ran on Windows, needs Client32 for NCP access and is no longer supported.
Stefaan has ported the functionality into a Designer plugin which is quite nice to add to your set of tools.
The trick here is that DirXML-Associations is Path syntax in eDirectory. That means it has three components to each instance of the attribute. The three components are: nameSpace volume path
The component nameSpace is a 32 bit integer, that is meant to represent the file system name space (like MAC, OS2, LONG, NSS, etc) but here a 0 means ignore, 1 means associated, and 4 means migrate.
The component volume is DN syntax and is the DN of the driver for which the association belongs. (Ironically under the covers eDirectory stores this as a 32 bit integer, the EID of the object in the database).
What the actual value is does not matter for this conversation, but it is sometimes useful to export all these values, muck about with them, and re-import them. For example if you needed to move 100,000 users from AD-Driver1 to AD-Driver2 which is pointing at the same Active Directory, it would be painful to re-migrate 100,000 users through a driver. Or you could export the 100,000 association values with the User DNs, into a text file and do a search and replace and change the DN of the volume component. Then re-import the values.
Well this is the tool for you. Select the driver you are interested in managing. That is because this is a per driver thing. The volume component is specific to one driver. When designing such a tool you could do like DAModifier which lets you specify the tree, finds all the DirXMl-Driver objects, and then lets you select the driver from a list. Or you could use the fact that Designer has a per driver layout already in place and just use that. Stefaan chose the latter. I possibly would disagree, but since he did the actual work, I go with his model.
Thus on the driver you want to manipulate associations go to the Live operations menu, where you would restart the driver, compare it, or set security. There is a new entry in the Live submenu for Association Editor. Assuming the connection is live, and it can read the connection info from the Designer project, then you see the box shown above.
You get three choices at the top: Export Associations Import Associations Modify Associations
Alas, I was surprised, there is no delete association, however do not give up hope, Stefaan is quite good at this stuff! Try the Modify Associations option and suddenly the UI changes to look more like this image.
Now you can say, change the State 1 (associated) to Remove the association. Thus this modify is a delete operation. But that also means you could bulk change users from a state of 1 to 0 (ignore) or possibly 4 (migrate).
This is more useful than just deleting. In all cases you get a filename to specify for input or export of the data, and in the case of modify for a log file. Now it turns out you cannot specify to change a set of associations you exported, alas, from one state to another. You will have to use the specified LDAP Filter to control whom it applies too. This is a bit weaker than the old DAModifier approach.
But of course if you needed to remove them all you could just modify, and from state 1 to Remove Association, and then you could import them on the new driver. If you try an export, the CSV looks like this:
Thus you can see that the User DN is listed in LDAP format, the state, and the value (Which in this driver was a student ID, since I think 42 is funny, and this was my third test user) so when you import it, it does not care about what driver it came from, rather it is a value and state as they apply to a user.
Importing is much the same, the UI changes again when you select Import Associations.
Here you specify a file, and since the file includes the state, no need to offer that as an option. If you want to make a pattern of that, edit the file to include the pattern you want.
Again you get to write out a log file which is nice for tracking what happened. What is even nicer is the Validate only tick box where you can try a dry run of what it is going to write, before it writes it out. As you can imagine that would be really nice to have.
In the Export case, you can filter by LDAP, and then after you are done exporting, you can edit the file and apply whatever additional filtering you need. Of course being CSV you can even do it in Excel if you so desired. Once you are done you could import that back into another driver, or even the same driver. This would allow for quick bulk modifying of associations.
Under the covers what this is doing is using the fact that the DirXML-Associations value in LDAP looks something like the following: cn=BB-SOAP,cn=DriverSet,ou=idm,dc=mydomain,dc=net#1#42424245
That might be easier to read if I split it up a bit. cn=BB-SOAP,cn=DriverSet,ou=idm,dc=mydomain,dc=net # 1 # 42424245
That gets parsed as, the BB-SOAP driver, (with that specific DN) as the volume component, the # sign is a delimiter, a state/nameSpace of 1, and a path component of 42424245. If you are good with taking those values and filtering, processing, and manipulating them, you can do all this in LDAP very straightforwardly. But it is actually a pain to do by hand and very nice when someone does it for you in a tool.
There are other tools that do this, Console2 by Alekz (which he has withdrawn from the market alas) has the same functionality built in.
As you can see this is a pretty neat tool, nicely added into Designer, in the same interface and UI, consistent with the model. Well done Stefaan. Very well done.
I still have two more to talk about so this series will continue. If you have any plugins for Designer, as you might guess, I quite enjoy them, send me a copy and I would love to review it for you.