Importing a Driver Export File Without Password Prompts


Novell Identity Manager is a complex system that can do as much as you can tell it to do.

As with most things, there are usually several approaches to any issue or problem. This even applies to managing the system. You can use iManager with the Identity Manager snapins or Designer for Identity Manager to manage the system.

Designer for Identity Manager is an Eclipse based IDE (Integrated Development Environment) that is Java based and mostly cross platform (there are some native libraries needed, that are not yet ported to all environments, but the rest of it usually works. Specifically missing are JClient, which allows NCP (Novell Core Protocol) access to the eDirectory tree. Thus Compare and Deploy functions will not work on a platform such as the Mac, if you were to run Designer on a Mac). Designer is great because you can work totally offline when you have no connection to the eDirectory tree that hosts the drivers. Recently they added version control via integration with SVN which makes working on a team much more secure. Each release keeps adding new features and gets better and better.

The Identity Manager plugins for iManager are surprisingly powerful for a web based application, and get better with each iteration that gets released. They are best for live changes, and with the latest release of the snapins have added some really great live monitoring abilities in the Driver Dashboard.

One thing lacking from both, is a tool set to help you work and develop your solution in a development lab tree, test it, stage it to a QA tree, and finally roll it out to production. Due to the lack of native tools that support this, everybody has come up with their own personal favorite approaches to handling the process.

There are a couple of basic approaches you can take.

You could use Designer's compare facility to try and push out the new driver set. Or even use it to overwrite the existing driver configurations. Depending on what your design is like, and your goals that can be sufficient.

If you want to take that approach what you would typically do is when you are ready, edit your project to point at the actual servers and trees in the QA or Production environment, instead of pointing at the Development lab servers.

Then you can compare, if you want to walk through the changes one by one, or deploy if you just want to overwrite. On a side note, I have submitted an enhancement request to Designer that when you use the Compare tool, to allow an export in some format of the results, so that you can more easily examine it at your leisure and decided if you really want to push out that set of changes. We shall see if this gets prioritized and added, time will tell. If you are not aware, anyone can submit an enhancement request, or a bug report via the Novell Bugzilla ( you just need a Novell account to submit (the same account you need to download software from Novell, so you probably have one already).

The Identity Manager and Designer teams are very keen on staying on top of these reports, so please take advantage of that fact and send them the good stuff that you find (bugs) or think of (enhancements).

If you use the Support Forums (Web interface at and News reader interface (NNTP) at nntp:// you will notice that often if you report and discuss a bug, someone is watching to add it to Bugzilla. This is a great support feedback loop, since you can easily get things that you find broken, reported, and often fixed.

The other basic approach is to use either Designer or iManager to export the driver or driver set configuration to an XML configuration file. This is very useful, since you can read through it to find things to edit, perhaps to fix references to contexts that differ between trees. I personally try to use a Global Configuration Value to store all implementation specific references. You can see an example of how to approach that in a driver, in the two articles I wrote about GCV'ing an Active Directory driver.

If you follow that approach, all you have to do is change the values of the GCV's to match and you are mostly good to go.

If you are upgrading an existing environment there are some other issues to consider. The association values are the biggest thing to worry about. The DirXML-Association attribute is of syntax Path. Path is a structured attribute, originally used to describe file system references. As such, it has three parts. The first is nameSpace, which stores a small integer (I never actually checked if it is limited in value, but it typically takes a number from 1-4 to represent the various name spaces (DOS, NFS, MAC, OS2, remember those from the Netware days?)). Then we have the volume value, which is a distinguished name (DN) syntax attribute. DN is a really neat syntax, since it survives move and rename events. (See this article Making Sure Your Work Orders Work! where someone tries to solve the problem that moves and renames cause, rather than use a DN syntax attribute which would solve it for him.) This is meant to reference the volume object in eDirectory. This is why in the olden days, before Netware 6 when you deleted a volume object, all trustees got lost. That was because the reference to the volume was by DN, and when you delete the object, all DN references to the object, get cleaned up automatically in the background.

This is a truly excellent feature of eDirectory. Annoying in this case, yes, but trust me, when you do not have this feature in a directory like system, it is beyond annoying in its absence. For example, Lotus Notes (Domino is the server, Notes is the client, so I suppose I should say Lotus Domino, but everyone knows it by the name Lotus Notes) suffers miserably from this issue.

If you add a member to a group in Lotus Notes, and then delete the User, (This never happens in the real world, right?) the reference to user remains! That means you have all sorts of invalid references to objects that do not exist all over the place. The solution in Lotus Notes is to run an administrative process on a regular basis to dredge the system to clean up these invalid references. Clearly not the most optimal solution, but workable. Alas, one of the most common cases of thousands of DN references is of course DirXML-Associations. Groups with very large membership lists, if you delete the Group might be another common case. Probably good to whittle down the size of the reference list before you delete the object, should you run into this issue in your environment.

The way eDirectory handles it is much cleaner. You delete the references object, and every reference to it disappears. I was recently informed in the forums by Father Ramon that there is an issue in eDirectory, if you do this for 10,000 references or so. There is some sort of deadlock condition that can happen at that point. Ten thousand seems like a reasonable limit, considering it not quite usual to have that many DN references in usual circumstances. However, worth knowing about.

If anyone knows if the SAP HR system has a similar concept for the way it stores Organizational structure, I would be greatly indebted. I am having trouble getting the information out of the SAP local folk to this question. In SAP HR, there are all sorts of references by Object ID to other objects. Who is a manager, who is managed, what Organization manages this other Organization, and what Positions or Jobs belong or report to whichever Organization. It is very unclear whether these references are ever cleared up or not, as People objects get removed and organization structures get updated. If you would happen to know, I would greatly appreciate it!

Finally the last value is path, which is a text string to represent the path to the file, on the volume.

DirXML-Associations use this attribute to store the association state (0, 1, 2, 3, or 4) in the nameSpace component, the DN of the Driver object to which this object is associated in the volume component, and the association value (See Open Call - IDM Association Values for eDirectory Objects).

Thus since the reference to the Driver object itself is a DN reference in all the existing DirXML-Association values, if you were to delete the existing object, and recreate it, even with the same name, all would be lost!

If the changes you have made to the drivers that you are trying to update are sufficiently complex, it may be that using either of the above suggested approaches may not be enough to get everything you need done correctly.

In that case, you could consider exporting the driver configuration as XML exports, and then delete all the CONTENTS of a Driver object, but not the driver object itself. When you import it again from the export files, you will get back all the rules and object that you need, but you will not loose the all important DirXML-Association values.

One of the annoying things about doing this import is that you will get prompted for all the passwords. Application, Remote Loader, and possibly Named passwords. However they are already encrypted and stored on the existing Driver object that you did not actually delete yet.

Often times, the current system has been running nicely and the original folk who designed it are long long gone, and who knows what the current passwords are. The drivers are all running, and why go through the hassle of fixing everything again if there is no need.

But when you import you will get prompted to enter the passwords, which will over write the current values, if you enter them. So if you do not know them, or worse, no one really knows them, it can be a huge pain to resolve. (Doable, but a pain).

The good news is, the export file has references to all the prompts that come up for passwords, and if you are confident they are not needed as you re-import, it is trivial to find them, delete them in the XML file before you import them, and save your self a lot of time and pain.

What you want to look for in the export file, are nodes that look like this:

<named-password-query display-name="Test Password" name="TestPassword"/>

The first, driver-password-query is for the driver object password, and the second shim-auth-password-query is the Remote Loader password. and finally the named-password-query node is for each instance of a named password that your driver includes.

Just edit the file, delete these lines, and try the import. You should be good to go!

I ran into this where we were upgrading a system with 30 drivers, that had changed a huge amount between revisions that we deployed, and re-entering the password for 30 drivers was a truly serious problem. Particularly since we wanted to practice in our QA lab, before we did this in production, and each time we started to run through the process, it added a large amount of time to the process that we did not want to waste.

Editing out these lines as one of the changes we made in the export file, before importing made a huge difference. We also edited the file to change the GCV's at the same time.

Hopefully pointing this issue out will help someone in a similar situation and save them a bunch of time!


How To-Best Practice
Comment List
  • This has worked well for me with password query prompts However if you remove the query tag associated with prompting for job scopes (to avoid being re-prompted for the scope of the job) - the import succeeds but the resulting job object doesn't seem to be valid and can't be edited in Designer 4.02.
  • Hey, geoffc, This is an excellent article - It's saved me quite a bit of time with my 10 drivers in a customers environment. Now - I'd like to find a the same solution for drivers while importing into designer - if you remove the query tags, Designer simply imports the driver as a brandnew driver, and I want to force it to overlay an already existing driver without asking for anything. I need the customer to be able to update the drivers without messing anything up.

    Any thoughts? I've tried everything I can think of . . I'd love to hear more!!