I do not mean to offend, but I need to contrast the approach taken by
two distinct driver teams. Whomever wrote the standard Windows/Java
Remote Loader, and the guys who wrote the Mainframe/Midrange/Unix drivers.
If you have used any of the last set of drivers, they have their own
Remote loader code that is consistent across their set of drivers.
(Right or wrong). There is a great feature in it, that I think MUST be
added to the Windows/Java RC product!
When you configure the Linux-Unix driver's remote loader, one of the
steps is to tell it the IP address (name or number work as long as it is
there) and a secure LDAP port on the engine server. Pretty easy, you
should know that.
What is so nice, obvious, and I think really useful, is it then does a
TLS bind, grabs the Certificate that the TLS server is providing, and
uses that in the proper PKI way, to sign all communication over SSL.
So instead of for the AD driver, in which we currently go to iManager,
make sure you have the CertServ plugins, find the cert, (possibly mint a
new one), remember to export the Trusted Root key, in B64 format (not
DER), then copy it by hand to the RC server, then select it in the
filesystem. Then on the Driver load line, add hmo=NickName of cert
(don't add the full eDirectory object name, no that is too obvious and
won't work) we could have:
Tell me the IP name/number of the Engine server.
Tell me its port (provide the 636 default)
And now we have Certs configured. Woo Hoo! Done.
World of difference in my mind! Possibly sacrifices some minor
functionality, but I am betting few people can name what that is!
I really think an update to the Remote Loader piece to add this would be
very useful in simplifying deploying drivers!