Novell has several versions of Identity Manager available. There was DirXML that was not really available to purchase until version 1.1, there was Nsure Identity Manager 2.0, Identity Manager 3.0, 3,5, and now 3.6.

With each new release, new operating systems and connected systems come to be supported, but also at the same time, older operating systems and connected systems drop off the supported list.

We recently ran into an issue with a Windows 2000 server, that we wanted to install an Active Directory driver on, using Identity Manager 3.6.1.

Everything went well, and in fact the install of the Connected System server, basically the Remote Loader went really well.

However, that ended quickly when we got to configuring the Remote Loader to use the ADDriver.dll loader shim.

The Remote Loader interface would not let us click Ok, and add the service.

We tried a number of basic troubleshooting things, like making sure the Remote Loader and Command ports were available on the server (they were not in use), and making sure we were at the latest releases.

Officially Windows 2000 is not supported as a Remote Loader platform in Identity Manager 3.6.1 and we admittedly did not check that until after we had begun, as we had a number of clients running Identity Manager Active Directory drivers using Windows 2000 servers, but with older versions of Identity Manager. So we knew it ought to work.

Well I knew there were a bunch of command line options for the Remote Loader that I never could remember. Off to the docs! To the docks! No the documentation!

The Remote Loader docs are at this link: http://www.novell.com/documentation/idm36/idm_remoteloader/

The last chapter item in the docs is section A.0 Options for Configuring a Remote Loader.

I do not like linking directly to sections of the docs as I have had less than perfect luck with that, so suffice to say, the documentation site, the docs for Identity Manager 3.6.1, and the Remote loader docs, then the section Options for Configuring a Remote Loader.

This lists the various options that are legal in the remote loader configuration file (more on that later) and also some command line parameters. I knew that the Windows based Remote Loader, the Win32 version, is basically a wrapper for the same Remote Loader code used in all the remote loaders. For more information about the variety of remote loader possibilities, you can read my article:
The Many Faces of Remote Loaders in IDM

You can tell because the encryption files are the same in the Windows, simple Java, and Omnibond drivers and the configuration options are all basically the same, they just have different wrapper interfaces. Personally I like the Omnibond driver remote loaders the best. They write the Unix/Linux (NIS/NIS ), AS400 (i5os), Mainframe (RACF and TopSecret, I forget, do they do ACF2 as well?), NxSettings, and Scripting drivers.

If you have ever configured one of their drivers, in the fan out or bidirectional driver, you will see that they realized something very obvious. The hardest part of setting up a remote loader is to get the trusted root for the Certificate Authority of the eDirectory running Identity Manager. This is needed for SSL communications, and this step seems to get people in the most trouble.

The Windows and other Novell supplied drivers expect you to go get it, and move the file over to the server the remote loader is running on. The documentation explains this, but since so many people STILL get it wrong, it leaves you to wonder if maybe there is a better way.

The smart guys at Omnibond noted that the successor to SSL is known as TLS, and TLS you can connect on port 389 in clear text, and the issue a StartTLS command which starts up the encryption stack. Well it also allows for the request and retrieval of the trusted root certificate that signed the certificate used in the SSL Communications channel.

Thus they added an option to their wrapper interface where you enter the address (IP Name or IP number) of any server in the same tree as your Identity Manager server, that is running LDAP, and it starts a session, asks for the trusted root, stores it in the appropriate format and you are done.

No going to Console One, iManager, or some other tool. No manual work needed. All you need to know is the IP address of a single server in your tree and you are all set. As you can see that is pretty darn trivial for the end user, compared to the current process for the other drivers. There you have confusion, do I need Base64 encoded (aka PEM format) or do I need the binary version (DER format).

The Omnibond guys showed that this is basically all unnecessary sweat and bother. I wish the regular Novell Remote Loaders would incorporate this feature. I have a bug in Bugzilla for this, that has been sitting there for probably two years ago now. (I recall speaking with an Identity Manager Product Manager about it, he knew of the bug, and that was at Brainshare 2008!)

Ah well, live and learn. But what this did tell me was that the Remote Loader itself is not of vital importance in terms of versioning. What that means is, while it would be nice to use the 3.6.1 Remote Loader executable, it probably would not be necessary. I happened to know that the 3.6.1 remote loader worked on Windows 2000, since we had clients using it.

I have used the stripped down simple Java remote loader on AIX with good success, so I knew that the Remote Loader component was just a framework to load either a Java class or a native library. It would have been nice to get some of the new features of the 3.6.1 remote loader interface on Windows, which is basically an Advanced tab that lets you set some Java parameters like max heap size on the Java class used in the Remote loader, but since we were using the ADDriver.dll it was sort of academic.

Anyway, one of the command line options from the documentation is the -service switch, which would allow you to load dirxml_remote -service and specify the configuration file you are using to try and manually create the service. This would eliminate the GUI from the equation.

We got an error in a dialog that was displayed:

The procedure entry point WTSQueryUserToken could not be located in the dynamic link library WTSAPI32.dll

The API is documented here:
http://msdn.microsoft.com/en-us/library/aa383840(VS.85).aspx

It first appears in WXP/W2K3. So this is definitely not supported on 2000.

Ok so looks like more than just the minor UI changes happened in the Windows Remote Loader for 3.6.1.

Thus we dropped back and punted? Is that the right metaphor? Whatever, I am Canadian and not a big football fan, so we went to a Remote Loader install from Identity Manager 3.5.1 and that worked fine.

The ADDriver.dll is the same between Identity Manager 3.5 and 3.6 so no real loss of functionality should there be (Shades of Yoda!). In fact the latest patch to 3.6.1 is noted to work with 3.5.1 as well.

We started the driver up after that, and saw this error:

<nds dtdversion="3.5" ndsversion="8.x">
  <input>
    <status event-id="report status" level="fatal">Premature return from PublicationShim->start()</status>
  </input>
</nds>
[11/11/09 10:32:32.884]:Moab PT:Applying schema mapping policies to input.
[11/11/09 10:32:32.884]:Moab PT:Applying policy: % CC[ACME] AD-SchemaMapping%-C.
[11/11/09 10:32:32.885]:Moab PT:Applying policy: % CC[ACME] AD-Generic Map Override%-C.
[11/11/09 10:32:32.885]:Moab PT:Resolving association references.
[11/11/09 10:32:32.885]:Moab PT:
DirXML Log Event -------------------
     Driver:   \ACME-IDV\ACME\Drivers\IDM\Moab
     Channel:  Publisher
     Status:   Fatal
     Message:  Premature return from PublicationShim->start()
[11/11/09 10:32:32.886]:Moab PT:
DirXML Log Event -------------------
     Driver:   \ACME-IDV\ACME\Drivers\IDM\Moab
     Channel:  Publisher
     Status:   Fatal
     Message:  Code(-9005) The driver returned a "fatal" status indicating that the driver should be shut down. Detail from driver: Premature return from PublicationShim->start()<application>DirXML</application>
<module>Moab</module>
<object-dn></object-dn>
<component>Publisher</component>
[11/11/09 10:32:32.887]:Moab PT:Killing driver from publisher thread; after PublicationShim.start().
[11/11/09 10:32:32.887]:Moab PT:Requesting termination.
[11/11/09 10:32:32.890]:Moab PT:Ending publisher thread.
[11/11/09 10:32:32.988]:Moab ST:Leaving event loop.
[11/11/09 10:32:32.988]:Moab ST:Shutting down DirXML driver \ACME-IDV\ACME\Drivers\IDM\Moab.
[11/11/09 10:32:32.989]:Moab ST:Remote Interface Publisher: Received shutdown.
[11/11/09 10:32:32.989]:Moab ST:Remote Interface Subscriber: Received shutdown.
[11/11/09 10:32:32.989]:Moab ST:DriverShim.shutdown() returned:

Now this particular error is actually a new one for me, Premature return from PublicationShim -> start() and that is not really informative, other than to tell me to go look in further depth for any other hints.

I looked a bit further and there earlier in the log I found the driver startup and connection event in the logs:

[11/11/09 10:30:40.978]:Moab ST:
<top>
  <driver-init>
    <nds dtdversion="3.5" ndsversion="8.x">
      <source>
        <product version="3.6.0.4294">DirXML</product>
        <contact>Novell, Inc.</contact>
      </source>
      <input>
        <init-params src-dn="\ACME-IDV\ACME\Drivers\IDM\Moab">
          <authentication-info>
            <user>FLOWMATIC/idm</user>
            <password><!-- content suppressed --></password>
          </authentication-info>
          <driver-options>
            <auth-options display-name="Show authentication options">show</auth-options>
            <auth-method display-name="Authentication Method">Negotiate</auth-method>
            <signing display-name="Digitally sign communications">yes</signing>
            <sealing display-name="Digitally sign and seal communications">yes</sealing>
            <use-ssl display-name="Use SSL for encryption">no</use-ssl>
            <impersonation display-name="Logon and impersonate">yes</impersonation>
            <xchg-options display-name="Show Microsoft Exchange options">hide</xchg-options>
            <exch-api-type display-name="Exchange Management interface type (use-cdoexm/use-post-cdoexm)">default</exch-api-type>
            <exch-move display-name="Allow Exchange mailbox move (yes/no)">no</exch-move>
            <exch-delete display-name="Allow Exchange mailbox delete (yes/no)">no</exch-delete>
            <access-options display-name="Show access options">show</access-options>
            <pollingInterval display-name="Driver Polling Interval">0</pollingInterval>
            <pub-heartbeat-interval display-name="Publisher heartbeat interval">0</pub-heartbeat-interval>
            <pub-password-expire-time display-name="Password Sync Timeout (minutes)">5</pub-password-expire-time>
            <search-domain-scope display-name="Search domain scope">yes</search-domain-scope>
            <retry-ldap-auth-unknown display-name="Retry LDAP Auth unknown error">no</retry-ldap-auth-unknown>
            <enable-incremental-values display-name="Enable DirSync Incremental Values">yes</enable-incremental-values>
          </driver-options>
          <publisher-state>
            <cookie>INITIALIZE_COOKIE</cookie>
          </publisher-state>
        </init-params>
      </input>
    </nds>
  </driver-init>
</top>
[11/11/09 10:30:40.983]:Moab ST:Remote Interface Driver: Document sent.
[11/11/09 10:30:40.984]:Moab :Remote Interface Driver: Waiting for receive...
[11/11/09 10:30:41.101]:Moab :Remote Interface Driver: Received.
[11/11/09 10:30:41.101]:Moab 
<nds dtdversion="1.1" ndsversion="8.7">
  <source>
    <product asn1id="" build="20070823_095000" instance="" version="3.5.1">AD</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <status level="error" type="driver-general">
      <message>Unable to enable signing on LDAP connection</message>
      <ldap-err ldap-rc="89" ldap-rc-name="LDAP_PARAM_ERROR"/>
    </status>
  </output>
</nds>
[11/11/09 10:30:41.105]:Moab ST:
DirXML Log Event -------------------
     Driver:   \ACME-IDV\ACME\Drivers\IDM\Moab
     Status:   Error
     Message:  <message>Unable to enable signing on LDAP connection</message>
<ldap-err ldap-rc="89" ldap-rc-name="LDAP_PARAM_ERROR"/>

You can see several things from this snippet of trace. First off, the obvious one is an LDAP error return code (rc) 89. Unable to enable signing on LDAP connection. Well the document that is sent with the <driver-options> node has a setting call <sealing> which is set to yes, and an option <signing> which is also set to yes. These are Active Directory bind functions that allow for securing the connection.

The <use-ssl> setting is actually for a different case than most people think, and gets a lot of people confused when first configuring the driver. After all, we want to SSL encrypt our traffic, such that the passwords are not transmitted in clear text right?

Well for Remote Loaders on Active Directory, there are two places you could use SSL. Between the Identity Manager engine (where eDirectory is running) and the Remote Loader is the most common. This is where in the Remote Loader configuration you provide the trusted root certificate for your tree as a B64 encoded file. That secures the engine to Remote Loader communication.

Now the next option for SSL, the one we see above refers to the case where the addriver.dll needs to communicate with Active Directory to monitor it. If you run the driver shim (the DLL) on a Remote Loader on a domain controller, then you do not need to enable this, as the traffic never leaves the server.

However, if you are not allowed to install it onto a Domain Controller, due to say, uptight Active Directory or Windows Admins and you need to install it on a member server, then you would want to secure the traffic between the Remote Loader on the member server and which ever Domain Controller it decides to talk too.

In that case, the Windows admins need to install and enable the Windows Certificate Authority, so that it can enable LDAP over SSL, and then the Remote Loader can talk SSL to the Domain Controller. Thus this is generally not needed, and not generally the case for an Active Directory driver.

There are also some additional settings there worth mentioning, when it comes to Exchange provisioning. With the addition of support for Exchange 2007 mailboxes, the model for creating Exchange accounts changes from using CDO to using a PowerShell script run from a service. In order to add that support to an existing driver, you need to add a parameter for the exchange-api-type value.

<exch-api-type display-name="Exchange Management interface type (use-cdoexm/use-post-cdoexm)">default</exch-api-type>

The docs for the latest patch try to explain how to update to it, but are not the greatest. Basically you need to select the option of use-post-cdoexm to enable it. Some earlier driver configurations do not have that option and you have to edit the XML in the configuration to add a nice option to select. There was some bit of confusion on how you could correctly edit the XML to do this. But the latest configs have it correctly, and you can just import a sample new driver into Designer, copy and paste the correct XML from the new driver into your old driver, and then delete the freshly imported driver to clean up your workspace.

However, back to this specific error example, it seems that Signing and Sealing (they seem to go together as a pair) are not working on Windows 2000 servers running Active Directory. Well easy enough. Back to either Designer or iManager, properties of the driver, Configuration options and in the Subscriber channel section there are widgets to select yes/no for Signing and for Sealing. Flip them over to No, and try again.

That time it worked. Always nice, when an error code shows you exactly what you are looking for. Even better when the suspect setting is shown right above it as it did in that trace sample above. Does it get cleaner than that? One can dream...

Here's hoping this is helpful to anyone else who happens to run into this situation, and if you find an additional twist, feel free to comment and I can update the article with any additional information.