sma2006 Outstanding Contributor.
Outstanding Contributor.
624 views

Failure to setup SSL with IBM OS/400 midrange driver

Hi,
I'm currently setting up the IDM 4.6 driver for As/400 and I have a problem to setup the SSL for the remote loader.


Normally the SSL is setup during installation of the driver-shim on the AS/400 or can be configured afterword with the i5OSDRV menu:

1. Start the I5OSDRV Driver Shim
2. Stop the I5OSDRV Driver Shim
3. Modify the I5OSDRV configuration file
4. Secure the I5OSDRV using SSL and trusted certificates
5. Set the remote loader and driver object passwords
6. Uninstall the I5OSDRV Driver Shim

When using option 4, you are supposed to enter the identity vault DNS name & the ldaps port (636) and the system get the CA public key from edir.

Unfortunately, I get an error "unable to resolve DNS name" and nothing is imported.

DNS resolution works fine with a ping from the AS/400 system and telnet on port 636 also can connect , as seen on tcpdump on the metadirectory server.

When tcpdump is active, no activity is shown on port 636 when using option 4.

Does anyone has any expertise with this driver ?

(I opened a case with NetIQ support).

Thanks

Sylvain
Labels (1)
0 Likes
9 Replies
Knowledge Partner
Knowledge Partner

Re: Failure to setup SSL with IBM OS/400 midrange driver

On 11/21/2018 03:34 AM, sma wrote:
>
> Normally the SSL is setup during installation of the driver-shim on the
> AS/400 or can be configured afterword with the i5OSDRV menu:


Which AS/400 driver are you using? I think there are both fan-out and
bidirectional options, but maybe I'm confusing this with others. Either
way, has this been setup in the past in another environment successfully,
e.g. in a Test environment or something?

Do you have a link to the documentation you are following to setup this on
the IDM side?

> When using option 4, you are supposed to enter the identity vault DNS
> name & the ldaps port (636) and the system get the CA public key from
> edir.
>
> Unfortunately, I get an error "unable to resolve DNS name" and nothing
> is imported.


That looks like a pretty specific error code.

> DNS resolution works fine with a ping from the AS/400 system and telnet
> on port 636 also can connect , as seen on tcpdump on the metadirectory
> server.


Have you tried tracing the DNS traffic during the failed attempt to see if
it is actually coming back successfully? Perhaps ping and telnet are
looking for A records while the IDM piece is asking for an AAAA record, or
vice versa.

> When tcpdump is active, no activity is shown on port 636 when using
> option 4.


That makes sense, as the error indicates the problem is with the DNS
lookup, which would happen to find the IP address to use in order to make
the TCP connection over 636, so if you cannot resolve the IP address,
you'll never try a TCP 636 connection.


--
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.
0 Likes
sma2006 Outstanding Contributor.
Outstanding Contributor.

Re: Failure to setup SSL with IBM OS/400 midrange driver

I'm using the Bi-Directionnal driver.

https://www.netiq.com/documentation/idm45drivers/bi_impl_mid-i/data/b3xehpq.html

The IDM Engine side looks ok, as it works without SSL, but the problem is when I try to get SSL on the remote loader side.

Checking the DNS query is a very good suggestion, I will try that. (hopefully we can dump packet on the AS/400)
0 Likes
Knowledge Partner
Knowledge Partner

Re: Failure to setup SSL with IBM OS/400 midrange driver

On 11/21/2018 05:54 AM, sma wrote:
>
> Checking the DNS query is a very good suggestion, I will try that.
> (hopefully we can dump packet on the AS/400)


There are two perspectives to any connection; you could also potentially
dump traffic from the DNS server:


sudo /usr/sbin/tcpdump -n -s 0 -i any -v port 53


--
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.
0 Likes
Jeff Bate Absent Member.
Absent Member.

Re: Failure to setup SSL with IBM OS/400 midrange driver

I don't know why DNS resolution is not working, but why not just put in the IP address of the eDirectory server instead? The input will accept that fine.
0 Likes
sma2006 Outstanding Contributor.
Outstanding Contributor.

Re: Failure to setup SSL with IBM OS/400 midrange driver

jeffbate;2491299 wrote:
I don't know why DNS resolution is not working, but why not just put in the IP address of the eDirectory server instead? The input will accept that fine.


Unfortunately, using the IP address return the same error...
0 Likes
Jeff Bate Absent Member.
Absent Member.

Re: Failure to setup SSL with IBM OS/400 midrange driver

That's interesting. A trace from the shim side may help us understand what's going on. Choose option 3 on the menu and add:
-tracefile /tmp/trace.txt
-trace 10

Do option 4 again to setup SSL and then check the trace.
0 Likes
sma2006 Outstanding Contributor.
Outstanding Contributor.

Re: Failure to setup SSL with IBM OS/400 midrange driver

Finally it works now.

What I did :

1) Ask for a new certificate for the remote loader from the Windows PKI

2) Import the certificate in eDir and configure it for the remote loader

3) Convert the PFX certificate to PEM/CER format and check the whole certificate chain is included

4) Copie the certificate.pem to /usr/local/i5osdrv/keys on the AS/400

5) Restart the remote loader on the AS/400 and the driver on the engine side.

I think the main problem was that the SSL configuration option during installation and afterwork did not work for me here.

Then I had to setup the proper certificat.

Thanks to all contributors.
0 Likes
sma2006 Outstanding Contributor.
Outstanding Contributor.

Re: Failure to setup SSL with IBM OS/400 midrange driver

Yes, we checked on the dns side and we don't see any query from the AS/400
0 Likes
Knowledge Partner
Knowledge Partner

Re: Failure to setup SSL with IBM OS/400 midrange driver

> Normally the SSL is setup during installation of the driver-shim on the
> AS/400 or can be configured afterword with the i5OSDRV menu:
>
> 1. Start the I5OSDRV Driver Shim
> 2. Stop the I5OSDRV Driver Shim
> 3. Modify the I5OSDRV configuration file
> 4. Secure the I5OSDRV using SSL and trusted certificates
> 5. Set the remote loader and driver object passwords
> 6. Uninstall the I5OSDRV Driver Shim
>
> When using option 4, you are supposed to enter the identity vault DNS
> name & the ldaps port (636) and the system get the CA public key from
> edir.
>
> Unfortunately, I get an error "unable to resolve DNS name" and nothing
> is imported.


So aside from AS400 specific DNS issues that might be happening, what
the RL is doing under the covers (and only the OMnibond ones do this,
not the MF/NetIQ ones, even though there has been a Bugzilla requesting
this functionality for probably 10 years now) is making an LDAPS
connection to ANY server in the IDV.

All those servers are assumed to use certs signed by the tree CA.
Therefore if they import the tree CA returned by the LDAPS connection,
you have the same tree CA that almost certainly signed the SSL cert used
for the RL.

So it does not matter which server in the tree you get to, so long as
you can get to any of them. Even if it is IP address and not DNS name,
it should not matter.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.