Setting the Notes ID Password in IDM 3.5


The IDM 3.5 driver shim for Lotus Notes/Domino adds a great new feature, the ability to set the password on the Notes ID file. This is a very sought after feature, and the developer, Perry Nuffer wrote a great description of what it takes to get it to work.

If you are interested in this feature, it is a must read at:

A point he discusses but does not expand on is the fact that the driver requires the ability to get at the Notes ID file via file system access. He states "No special code is incorporated into the NotesDriverShim to manage or maintain mapped drives, file shares, or network access. The
NotesDriverShim assumes that the files referenced will be available, and if not, errors will be reported."

Access Procedure

Using a Netware 6.5 target server for storing the ID files (and acting as the Identity Vault and Meta Directory engine), we were able to reference the file via a UNC path, both via NCP and via CIFS.

Here are the steps we followed:

1. Install Client32 on the Windows 2003 Notes driver shim box.

2. Create an account in Active Directory with the same username and password as an account in eDirectory.

3. Grant the eDirectory account file system access to the location of all the ID files.

4. Set the default context in Client32 to allow it to login.

5. In the Services MMC snapin (services.msc), edit the DirXML Remote Loader service and change it to use the credentails for the accounts you created, instead of using a system account.

6. Restart the driver shim via the remote loader.

7. Use a mapping table to specify a context code and a path to the ID files. This is due to a funny structure at this site, but it simplified the pathing issues, since the mapping table held the correct path information for each context a user might be in.

8. Enable CIFS on the Netware server in local mode, which means the CIFS authentication is passed through to eDirectory for testing credentails. This saves you from having to create another account elsewhere, and it quickly allows you to validate CIFS access as well as NCP access without having to move files around again.

9. Change the Mapping table from




so you can test both cases.

We thought of another option but did not test it: it would be to mount a CIFS mount point to a local drive on the Remote Loader box and reference it via a drive letter. We expect that would work just as well, but we did not test it.

If you get the path wrong, expect a 6402 error. If you get the old-password wrong, expect a 6408 error. This error is a problematic one, and I think I have a solution - but that is a topic for another day.


How To-Best Practice
Comment List
Related Discussions