AD Driver hangs Creating an JSSEKmoFactory ServerSocket

[benjaminkelley]

I'm spinning up a new AD driver in my production environment(already done in test).
I have SSL enabled to the RL, but when the driver starts it hangs creating the ssl connection on the engine side. I don't see it connecting on the remoteloader side(I can telnet to the port on the RL from the server). This appears to be happening before it connects to the RL.

[07/19/18 19:58:12.639]:AD-MYDOMAIN ST:Remote Interface Driver: start getSchema()
[07/19/18 19:58:12.639]:AD-MYDOMAIN ST:Remote Interface Driver: Opening connection...
[07/19/18 19:58:12.639]:AD-MYDOMAIN ST:Remote Interface Driver: Client socket parameters: hostname = 'remoteloaderserver.mydomain.org' port = 8090 KMO = 'RemoteLoaderCert2018' SSL mode = server
[07/19/18 19:58:12.650]:AD-MYDOMAIN ST:Remote Interface Driver: Creating an JSSEKmoFactory ServerSocket
__Here it just hangs until you restart the engine__

This is what it looks like in my test environment
[07/20/18 10:47:49.531]:AD-MYDOMAIN -T PT:Remote Interface Driver: Opening connection...
[07/20/18 10:47:49.531]:AD-MYDOMAIN -T PT:Remote Interface Driver: Client socket parameters: hostname = 'remoteloaderserver.mydomaintst.org' port = 8090 KMO = 'RemoteLoaderCert201512' SSL mode = server
[07/20/18 10:47:49.536]:AD-MYDOMAIN -T PT:Remote Interface Driver: Creating an JSSEKmoFactory ServerSocket
[07/20/18 10:47:49.572]:AD-MYDOMAIN -T PT:Remote Interface Driver: JSSE Socket, cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 , peer host: 10.x.xx.xx
[07/20/18 10:47:49.572]:AD-MYDOMAIN -T PT:Remote Interface Driver: Connection established...
[07/20/18 10:47:49.573]:AD-MYDOMAIN -T PT:Remote Interface Driver: Sending...


Full section of the trace is https://paste.opensuse.org/795f03b4
Engine is 4.5.6.1 eDir is 8.8.8.11 RL is 4.5.6.1

[geoffc]

On 7/20/2018 11:54 AM, benjaminkelley wrote:
>
> I'm spinning up a new AD driver in my production environment(already
> done in test).
> I have SSL enabled to the RL, but when the driver starts it hangs
> creating the ssl connection on the engine side. I don't see it
> connecting on the remoteloader side(I can telnet to the port on the RL
> from the server). This appears to be happening before it connects to the
> RL.
>
> [07/19/18 19:58:12.639]:AD-MYDOMAIN ST:Remote Interface Driver: start
> getSchema()
> [07/19/18 19:58:12.639]:AD-MYDOMAIN ST:Remote Interface Driver: Opening
> connection...
> [07/19/18 19:58:12.639]:AD-MYDOMAIN ST:Remote Interface Driver: Client
> socket parameters: hostname = 'remoteloaderserver.mydomain.org' port =
> 8090 KMO = 'RemoteLoaderCert2018' SSL mode = server
> [07/19/18 19:58:12.650]:AD-MYDOMAIN ST:Remote Interface Driver: Creating
> an JSSEKmoFactory ServerSocket
> __Here it just hangs until you restart the engine__
>
> This is what it looks like in my test environment
> [07/20/18 10:47:49.531]:AD-MYDOMAIN -T PT:Remote Interface Driver:
> Opening connection...
> [07/20/18 10:47:49.531]:AD-MYDOMAIN -T PT:Remote Interface Driver:
> Client socket parameters: hostname =
> 'remoteloaderserver.mydomaintst.org' port = 8090 KMO =
> 'RemoteLoaderCert201512' SSL mode = server
> [07/20/18 10:47:49.536]:AD-MYDOMAIN -T PT:Remote Interface Driver:
> Creating an JSSEKmoFactory ServerSocket
> [07/20/18 10:47:49.572]:AD-MYDOMAIN -T PT:Remote Interface Driver: JSSE
> Socket, cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 , peer host:
> 10.x.xx.xx
> [07/20/18 10:47:49.572]:AD-MYDOMAIN -T PT:Remote Interface Driver:
> Connection established...
> [07/20/18 10:47:49.573]:AD-MYDOMAIN -T PT:Remote Interface Driver:
> Sending...
>
>
> Full section of the trace is https://paste.opensuse.org/795f03b4
> Engine is 4.5.6.1 eDir is 8.8.8.11 RL is 4.5.6.1

Aaron made a good point. While on the one hand the versioning of the
Engine and RL matter in terms of SSL connections, the actual JVM in use
is also part of it.

Now each engine/RL patch comes with a distinct JVM build, but it is
possible you have a JVM mismatch.

Be worth considering the versions you have installed on both sides.

[benjaminkelley]

geoffc;2484451 wrote:


Aaron made a good point. While on the one hand the versioning of the
Engine and RL matter in terms of SSL connections, the actual JVM in use
is also part of it.

Now each engine/RL patch comes with a distinct JVM build, but it is
possible you have a JVM mismatch.

Be worth considering the versions you have installed on both sides.

Both the version in the remote loader directory and in nds-modules on the engine server display java version "1.8.0_131".

[aburgemeister]

Do you have any other TLS-using connections to Remote Loaders on this
production box? Do they still work properly?

Also, just as an unrelated note, you have the following set in a way you
almost certainly do not want:

<enable-incremental-values display-name="Enable DirSync Incremental
Values">no</enable-incremental-values>

If you are not dealing with groups it may not matter, but it really,
REALLY should default the other way by now; surely nobody still runs a
windows 2000 functional level domain these days.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

[benjaminkelley]

The only other driver I have using a remote loader on this system hasn't been converted to using TLS yet.

Good catch on the incremental values. I forgot to toggle it on this new driver. Tho, we won't be syncing groups for a while on it. Thanks.

[benjaminkelley]

Just a follow up on this. I never found a resolution. I ended up moving the driver to another server in the driver set and it starts up fine. I'm assuming its something environmental specific to this server, but don't know what.
The server its on is one of our oldest and has the old large dib slow start problem, so I'm just gonna chalk it up to that unless I happen to see anyone else having a similar problem in the future.