eTrust Directory - DXtools support of SSL binding within the current release (r8.1). How do I get the DXtools set of utilities working in an SSL only Directory backbone? (DXmodify, DXsearch, DXdelete, DXrename)

Products

• CA Directory
• CA Security Command Center
• CA Data Protection (DataMinder)
• CA User Activity Reporting

Issue/Introduction

Configuring a "Local" LDAP Proxy

This paper describes how to configure a local LDAP proxy DSA for use with the non-SSL DXtools set of utilities and the Identity Management CA Directory implementation.

Background

Historically, the DXtools set of utilities have not been SSL enabled. This implies that if the entry points to the directory are locked down so that they will only allow SSL connections, the DXtools will no longer be able to connect to the directory.

This is the issue that faces some customers at the moment. However, if a customer locks down their directory entry points to "deny" all non-SSL connections. This effectively breaks any DXmodify, DXsearch, DXdelete, DXrename execution.

Solution

Long Term

CA have committed to adding SSL functionality into their DXtools set (where applicable) in the r12 release.

Short Term

DXtools support of SSL binding within the current release (r8.1) will not be possible, but a workaround has been developed by the Level 2 Development Support team that should be acceptable to customers in the interim until the r12 release has been released.

The workaround for the r8.1 release involves the creation of a "local" LDAP Proxy DSA. This DSA will be acting as an SSL gateway into the Directory backbone.

At a high level, the DXtools utilities, when run from the physical server (where the LDAP Proxy DSA is installed) will connect to the LDAP Proxy DSA, which only answers on the "localhost" IP address of 127.0.0.1. Once the connection to the LDAP Proxy has been made, using a non-SSL connection, the LDAP Proxy DSA will then route the connection to the Router DSA over SSL. From there on, the connection traffic will continue throughout the backbone exactly as it is currently.

This is viewed by CA support as being a suitable workaround for the r8.1 implementation at most customer sites where all connectivity to the main Router DSA is locked down the SSL Only.

The LDAP Proxy DSA is only configured to communicate on the localhost port of 127.0.0.1, which means that only DXtool commands run from the physical Directory server will be able to connect. Attempts to connect to the LDAP Proxy DSA from the "outside world" will not function, as the DSA is not listening on an external network address.

Please find the detailed implementation plan in the following section

Implementation of the Solution

Assumptions:

For illustrative purposes, the hostname being used for this document is ServerA
This means that all DSA?s will be referenced with a prefix of "ServerA-"

Pre-requisites:

The version and build of directory has to be r8.1.1000
The reason for this is that there is a fix that is mandatory for this workaround solution to function. This fix adds a new flag into the knowledge file parameters called "bind-address". This bind address parameter is being used by the LDAP Proxy DSA's knowledge file to ensure that all communications are transmitted on the 127.0.0.1 interface.

Create the LDAP Proxy Initialization File

Create a file in the "$DXHOME\config\servers" folder called "ServerA-ldapproxy.dxi".
Save the following into the "$DXHOME\config\servers\ServerA-ldapproxy.dxi" file:

# logging and tracing
close summary-log;
close trace-log;
source "../logging/default.dxc";

# LEGACY licence
# source "../licence/default.dxc";

# schema
lear schema;
source "../schema/default.dxg";

# access controls
clear access;
source "../access/default.dxc";

# knowledge
clear dsas;
source "../knowledge/Proxy-Knowledge.dxg";

# operational settings
source "../settings/default.dxc";

# service limits
source "../limits/default.dxc";

# replication agreements (rarely used)
# source "../replication/";

# multiwrite DISP recovery
# set multi-write-disp-recovery = false;

#cache configuration
#set max-cache-size = 10;
#set cache-index = organizationName;
#set cache-attrs = all-attributes;
#set lookup-cache = true;

This initialization file is based upon the existing Router DSA initialization file. The only change that has been made it to modify the knowledge group file that's being sourced. The sourcing of the Proxy-Knowledge group file restricts the LDAP Proxy to only having knowledge of the Router DSA. It doesn't have knowledge of the rest of the Directory backbone.

Define the LDAP Proxy Knowledge

Create a file in the "$DXHOME\config\knowlege" folder called "ServerA-ldapproxy.dxc".
Save the following into the "$DXHOME\config\knowlege\ServerA-ldapproxy.dxc" file:

set dsa ServerA-ldapproxy =
{
    prefix = <>
    dsa-name = <cn ServerA-ldapproxy>
    dsa-password = "secret"
    address = tcp "127.0.0.1" port 1234
    bind-address = "127.0.0.1"
    disp-psap = DISP
    cmip-psap = CMIP
    snmp-port = 1234
    console-port = 1235
    remote-console-port = 1236
    console-password = "Password01"
    ssld-port = 1112
    auth-levels = anonymous, clear-password, ssl-auth
    max-idle-time = 60
    dsa-flags = relay
    trust-flags = allow-check-password, trust-conveyed-originator, no-server-credentials
    link-flags = ssl-encryption, dsp-ldap
};

Please Note: The TCP ports that have been assigned in the above knowledge file are 1234 through to 1236. These can be changed to suit you specific environment if you wish, but the TCP port defined by the "Address" parameter is the port that the DXtools utilities will need to connect to during BAU.

Define the LDAP Proxy Knowledge Group File

Create a file in the "$DXHOME\config\knowlege" folder called " Proxy-Knowledge.dxg ".
Save the following into the "$DXHOME\config\knowlege\Proxy-Knowledge.dxg" file:

source "ServerA-ldapproxy.dxc";
source "ServerA-Router.dxc";

Edit the Router DSA's Knowledge Group File

Edit the file in the "$DXHOME\config\knowlege" folder called "Global-Knowledge.dxg"
Save the following into the "$DXHOME\config\knowlege\Global-Knowledge.dxg" file, just before the "ServerA-Router" entry:

source "ServerA-ldapproxy.dxc";

So that the EDS-Knowledge.dxg file looks like the following:

source "ServerA-ldapproxy.dxc";
source "ServerA-Router.dxc";
source "ServerA-DXCache.dxc";
source "ServerA-Update.dxc";

Generate LDAP Proxy PEM Certificate

An X.509 PEM certificate will need to be created to facilitate the SSL interconnectivity between the LDAP Proxy DSA and the SERVERA-Router DSA. This certificate will need to be stored where the other DSA PEM certificates are stored, and it will need to be signed by the same certificate authority as the other certificates. Once the certificate has been generated, save it to the same location as the other certificates.

Stop and Start DXservers and SSL Daemons

Once all the above steps have been performed and the files saved in their correct locations, please stop and start the SSL Daemons and the DSA's for them to pick up the new configuration and certificate.

Stop the DSA's:

dxserver stop all

Start the DSA's:

dxserver start all

Stop the SSL Daemon:

ssld stop all

Start the SSL Daemon:

ssld start all

Testing of Solution

The ideal way to test that this works is to have:

• One command shell open with a dxmodify command ready to execut
• Two DXconsole sessions running. Connecting to the LDAP Proxy and Router DSA's respectively.

Command Example

dxmodify -a -h 127.0.0.1 -p 1234 -D "{ Bind-DN }" -w { password } -f { filename.ldif }

You can see that the command is the stock standard Dxmodify. There's no SSL parameters defining keystores and keystore passwords.

Trace from the Router DSA

For document size purposes, the trace from the Router DSA will be displayed.

<- #0 (SSL) DSP BIND-REQ 
    invoke-id = 0 credit = 1 
  User: 
    <commonName "ServerA-ldapproxy"> 
  Password: (masked) 
  Remote address: 
    ssap = "" tsap = "" 
    sap = 
0x020010C97F00000100000000000000000000000000000000000000000 
000000" 
    flags = IDU_FLAGS_USE_SSL 

In the above operation, the LDAP proxy is sending a BIND request to the Router DSA over an SSL connection.

-> #0 (SSL) [ServerA-ldapproxy] DSP BIND-CONFIRM 
     invoke-id = 0 credit = -100 
  User: 
     <commonName "ServerA-tdsldap1r0"> 
  Password: (masked)

In the above operation, the Router DSA confirms the bind, over an SSL connection.

<- #0 (SSL) [ServerA-ldapproxy] DSP COMPARE-REQ 
    invoke-id = 2 credit = 99 
  Entry: 
    <organizationName "CompanyA"> 
    <organizationalUnitName "OrgUnit"> 
    <organizationalUnitName "SubOrgUnit"> 
    <organizationalUnitName "Super Users"> 
    <cosineUserid "ADMIN"> 
  Assertion = userPassword (masked)  

In the above operation, the LDAP proxy is sending a compare request to the Router DSA for the user that was supplied in the Dxmodify command. This is over an SSL connection.

(Remote) -> #1 [ServerA-DXcache] DSP BIND-REQ 
invoke-id = 1 credit = -25 
   User: 
      <commonName "ServerA-Router"> 
   Password: (masked) 

Connecting to TCP aaa.bbb.ccc.ddd:12345 
remoteSendRequest: bind sent to DSA 'ServerA-DXcache' 

(Remote) <- #1 [ServerA-DXcache] DSP BIND-CONFIRM 
     invoke-id = 0 credit = 24 
   User: 
     <organizationName "CompanyA"> 
     <organizationalUnitName "OrgUnit"> 
     <commonName "ServerA-DXcache"> 
   Password: (masked) 

(Remote) -> #1 [ServerA-DXcache] DSP COMPARE-REQ 
    invoke-id = 2 credit = 1 
  Entry: 
     <organizationName "CompanyA"> 
     <organizationalUnitName "OrgUnit"> 
     <organizationalUnitName "SubOrgUnit"> 
     <organizationalUnitName "Super Users"> 
     <cosineUserid "ADMIN"> 
  Assertion = userPassword (masked) 

(Remote) <- #1 [ServerA-DXcache] DSP COMPARE-CONFIRM 
   invoke-id = 2 credit = 24 
  Assertion TRUE 
  Entry: 
     <organizationName "CompanyA"> 
     <organizationalUnitName "OrgUnit"> 
     <organizationalUnitName "Staff"> 
     <cosineUserid "ADMIN"> 
   Alias dereferenced 

-> #0 (SSL) [ServerA-ldapproxy] DSP COMPARE-CONFIRM 
    invoke-id = 2 credit = 1 
  Assertion TRUE 
  Entry: 
    <organizationName "CompanyA"> 
    <organizationalUnitName "OrgUnit"> 
    <organizationalUnitName "Staff"> 
    <cosineUserid "ADMIN"> 
  Alias dereferenced 

In the above operations, the Router DSA has to chain the compare onto the data DSA DXCACHE for actioning. The data DSA then confirms the bind credentials. This is not over an SSL connection

Lastly the Router DSA confirms the bind back to the LDAP Proxy DSA. This is over an SSL connection.

Environment

Release:
Component: ETRDIR