eDirectory Remote Loader Basics

Recently I worked with a client who was attempting to connect to multiple Active Directory servers using remote loaders.  The client had experienced some issues getting the remote loaders to work properly.  After working through the issues we were able to successfully get the remote loaders working.  The issues varied for each remote loader and in talking with the client we discovered there was some misunderstanding about some of the documentation that lead to the issues encountered.  The information that follows is a quick reference of what a remote loader does, what is needed for common implementations and some common issues faced.


Q: What is a remote loader?

A: In a nutshell, a remote loader is a small application that is installed on a non-eDirectory server (i.e. remote) that allows for secure, encrypted transactions between eDirectory and target applications/servers.

Remote loaders are most commonly used when connecting eDirectory to Active Directory or databases that store sensitive data.


Q: Does a remote loader have to be installed on the target application server?

A: No.  Remote loaders can be installed on any non-eDirectory server that has network access to the target server.  Typically remote loaders are installed on the target application server to reduce the overall complexity and networking requirements but it is not required.

However, it is never recommended that a remote loader be installed on the same server where eDirectory is installed.

The primary purpose of a remote loader is to create a secure line of communication between eDirectory and a target application/server so if the remote loader is installed on an eDirectory server it essentially renders the remote loader useless.


Q: Does the remote loader require a specific port?

A: Yes.  Each driver that is configured to use a remote loader must be configured to use a unique port.  This port must match the port specified in the remote loader configuration.  For example, if you have two Active Directory drivers in your eDirectory “driver set” and both drivers use remote loaders one driver and remote loader would use port 8090 and the other driver and remote loader would use port 8091.

Port 8090 is the default port for remote loaders and it is typically recommended that each remote loader beyond the first uses the next port in sequence.


Q: Can I have more than one remote loader installed on a single server?

A: Yes.  The remote loader installation application only installs a remote loader administration console.  It is within this console that the actual remote loaders are created and configured.  This means that you can create and configure multiple remote loaders on a single server and multiple remote loaders can run at the same time; provided that each active remote loader is running on a unique port.  No two remote loaders may use the same port.


Q: Is the traffic between an eDirectory driver and a remote loader automatically encrypted?

A: No.  Technically you can use remote loaders without encrypting the data but if unsecured, unencrypted communication is desired then a remote loader is often unnecessary.  To create a secure connection between your driver and the remote loader you must provide the driver and remote loader with the proper eDirectory issued certificates.

This is the part where those unfamiliar with certificates and/or eDirectory have trouble.  While there is documentation provided by Novell/NetIQ regarding how to create secure connections between drivers and remote loaders it is not always clear that this process requires TWO (2) certificates within eDirectory.


Q: How do I create a secure connection between eDirectory and my remote loader?

A: The first step to securing the data between eDirectory and a remote loader is to create a server certificate through iManager.  This is done by logging into iManager, clicking Novell Certificate Server then Create Server Certificate and following the prompts.  Where it asks for the certificate “Nickname” you can enter whatever you choose but do not use a nickname that includes spaces.

Note: The important thing to remember here is that when creating this server certificate it must be for the same server that the driver will be running on.  For example, if you have multiple instances of eDirectory in your environment and Driver A will be running on Server 2 then be sure to select Server 2 when creating the certificate.

This certificate will be used in the driver configuration for it’s connection to the remote loader and will be specified in the KMO parameter of the driver’s remote connection parameters.  If you are configuring the remote loader connection in iManager the connection will look like this: hostname=<remote loader server name/IP> port=<remote loader port> kmo='<server certificate nickname>’.  Take note of the single quotes (‘) that surround the KMO certificate name.  This is required to properly define the certificate name and excluding these may result in issues resolving the certificate name during the driver startup sequence.

Note: If you plan on running multiple drivers that use remote loaders from a single eDirectory server the same server certificate created above can be used for those drivers.  Again, only drivers running on the same server that the certificate was created for can use that certificate.  If you have drivers running on other eDirectory servers those servers will have to have their own server certificates created in iManager.

After creating the server certificate to be used with the driver the next step is to export a self-signed certificate from iManager that contains the eDirectory’s public encryption key to be used with the remote loader.  This is not an export of the server certificate created above.

To do this log into iManager, click eDirectory Administration, then click Modify Object and select the Certificate Authority object in the Security container.  From here click the Certificates tab, select Self-Signed Certificate and then click Export.  An Export Certificate Wizard should appear.  Deselect the option to Export private key, set the Export Format to BASE64 and click the Next button.  Save the exported certificate to the local file system using the link provided in iManager.

Note:  This is the part that usually causes the most confusion.  Often times people think they need to export the server certificate created in the steps above and end up exporting the wrong certificate.  Exporting the server certificate instead of the CA certificate will result in certificate errors that will prevent the driver and remote loader from successfully communicating.

With the self-signed certificate exported all that is left to do is copy the BASE64 export to the server where the remote loader is running and point the remote loader configuration to the exported certificate’s location.


Q: Why are the certificates only used to secure communication between eDirectory and the remote loader?  What about the communication between the remote loader and the target application/service?

A: Typically the remote loader is installed on the same server as the target application/service.  So for example when connecting to Active Directory the remote loader is generally installed on a domain controller (DC).  The purpose of the certificates and secure connection is to encrypt and protect data that is transmitted over the network from one server to another.  This means that when the remote loader is installed on the same server as the target application/service that the only communication that needs to be secured is that communication that is between eDirectory and the remote loader.  In that scenario the communication between the remote loader and the target application/service is all done locally and not over the network so encryption is not required.

In the event that the remote loader is not installed on the target server but a remote server that will act as a go between between the source and target servers communication can be secured between the remote loader and the target application/service.  The communication between these two points can be configured to use SSL but it requires a certificate authority (CA) that can issue certificates for the server running the target application/service.  Most implementations do not use this method as it requires additional requirements for certificates, routing/firewalls and hardware but it is available and discussed in the Novell/NetIQ remote loader documentation.


Q: What are some common issues when using remote loaders?

A: Because remote loaders exist outside of the eDirectory instance and generally leverage certificates and passwords to create secure communication between system a variety of issues may occur.  Below are the most common:

  1. Network traffic is blocked
    1. In most professional/corporate networks there are firewall and routing rules in place that provide secure access to resources to connections that need them and block others.  Most often the ports required for the remote loader connections are closed in these environments because they are not commonly used ports.  For remote loader connections to work properly you will need bi-directional traffic on the specified port between the eDirectory server(s) and the target server hosting the remote loader for TCP.  You can easily test this connection by attempting to establish a telnet session from the eDirectory server to the target remote loader server over the specified port.
  2. Account password changed
    1. The eDirectory driver connection details typically contains a username and password that is used to authenticate to the target server/application/service (i.e. Active Directory, MSSQL, etc.).  Often times corporate policies will require these passwords to be changed at some point for security purposes.  If the account password is changed in the target application/service then the password will need to be updated in the driver configuration and the driver will need to be restarted.  The driver authenticates for every transaction so as soon as the password is changed in the target application/service all transactions processed through that driver will fail until the driver is updated and restarted.
  3. Bad driver/remote loader password
    1. As an additional security measure drivers and remote loaders can be configured with their own passwords that must be exchanged between the driver and remote loader during communication to ensure the information received is coming from a valid source.  Both values are stored in the driver configuration and the remote loader configuration so if either value is changed in either location communication between the driver and remote loader will fail.  This is commonly caused when driver changes are migrated to an environment and the driver configuration is updated with incorrect or outdated information, generally from a developer’s Designer workspace.
  4. Expired certificate
    1. The certificates used for the driver and remote loader do have expiration dates associated with them.  The expiration dates can be found in iManager when viewing the certificate.  Typically the certificates are issued for 3 years before expiring.  Once a certificate expires the communication between the driver and remote loader will fail until the certificate/s is/are renewed.
  5. DNS resolution failure
    1. Another common corporate network practice is to restrict visibility of servers from the network.  This can be done by not including a server in the corporate DNS.  It is generally recommended that when configuring connections to servers that you use the server name and not the server IP address.  This means that if a server is not included in the corporate DNS that any attempts to navigate to the target server name will fail because that name cannot be found in the DNS to determine the IP address for traffic to be routed towards.  Attempting to create a telnet session or attempting to “ping” the target server name should reveal this problem as it will return an “unable to resolve” type error.  For security reasons the target server may not be able to be added to the corporate DNS but you can add a HOST file entry for the target server by adding the appropriate information to the HOST file on the eDirectory server where the driver will be running.
  6. Windows 2012 server firewall
    1. The latest version of Microsoft’s server OS does things a little differently than it has in the past.  With Windows 2012 Server the Windows Firewall is automatically enabled now.  This by default will block the traffic commonly used for the remote loader ports (8090 and up).  If the remote loader is installed on a Windows 2012 server someone with administrator rights for that server will either need to disable the firewall or add new traffic rules to the server’s firewall to allow traffic on the remote loader ports between eDirectory and that server.


Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.