How to use CA Directory OOTB LDAP client tools to do certificate authentication w/o a third-party LDAP Client?
search cancel

How to use CA Directory OOTB LDAP client tools to do certificate authentication w/o a third-party LDAP Client?

book

Article ID: 379136

calendar_today

Updated On:

Products

CA Directory

Issue/Introduction

Even though the KB "How to configure a CA Directory DSA that only accepts certificate authentication?" shows how to use the commonly used OpenLDAP Client ldapsearch to authenticate with a CA Directory DSA using a certificate. Having to install the client could be an extra burden. Does CA Directory OOTB have any LDAP client that can be used to accomplish the same tasks?

Environment

CA Directory Linux

Resolution

 

First, follow the KB "How to configure a CA Directory DSA that only accepts certificate authentication?" to prepare the test system. So that we have a democorp DSA that only accepts certificate authentication and also the certificate to use for the testing.

dxsearch does not support client-side certificate authentication.

To allow dxsearch to connect to the democorp DSA through ldaps, we need to reference KB "Symantec Directory : post-SP3 upgrade, DXtools over SSL does not work with existing certificate" where we can modify the $DXHOME/config/ssld/dxldap.conf file to have the following content

TLS_CACERT  /opt/CA/Directory/dxserver/config/ssld/trusted.pem
TLS_REQCERT never

Here, the key is TLS_REQCERT set to never. This setting is required because the more recent changes to the SSL/TLS requires the ldaps connection needs to be made to made to a host name that is included in the SAN (Subject Alterative Name) on the certificate which at CA Directory 14.1/sp5 tends not to be the case. From the KB "How to configure a CA Directory DSA that only accepts certificate authentication?", then we may think if we use similar setting as we saw in the .ldaprc to modify the dxldap.conf or use the environment variables, then it may work too. However, it seems that the dxsearch does not seem to take the certificate setting similar to ldapsearch.

ldua example

The ldua under the samples/ldua is a text-based Directory User Agent (DUA) that runs over LDAP. For a list of DUA commands, see the following documentation link:

DUA Commands

Working examples can be found under the samples/ssl, samples/ldua, samples/dua, and samples/test. For the purpose of this article, the basic flow is to 
    1. config the schema used by the democorp DSA
    2. optionally setup tracing level
    3. bind to the democorp using marco_drew's certificate
    4. perform a search
    5. unbind

The ldua command uses "source filename;" to read a prepared file as part of its execution, therefore if we first go to the subdirectory examples/ssl after we have followed through "How to configure a CA Directory DSA that only accepts certificate authentication?", Then we can prepare the following in a file named "mytest" under the samples/ssl. Note that you need to replace the "<<yourhostname>>" with the host where the democorp DSA is running.

# Read the samples Schema prepared for democorp DSA
source "../../config/schema/samples.dxg";

# Set the trace level.
set trace = ldap;

# Prepare ssl configuration
# use certificate stored under the current directory

set ssl = {
    cert-dir = "."
    ca-file = "../../config/ssld/trusted.pem"
    protocol = tls
};

# Bind to the democorp DSA using marco_drew certificate

bind-req
    ssl-auth personality = "marco_drew"
  remote-addr = { nsap = ip "<<yourhosstname>>" port 19389};
wait;

# Perform a sub-tree search under DemoCorp for all entries beginning with y.
search-req base-object=<c AU><o DemoCorp> whole-subtree
    filter = { attr = commonName substrings [ initial y ] };
wait;

# Unbind
unbind-req;
wait;

# Quit
quit;

and issue the command

../ldua/ldua mytest

to see the ldap client search using a certificate.

Additional Information

While following the KB "How to configure a CA Directory DSA that only accepts certificate authentication?", it created the trusted.pem and the marco_drew.pem that can be used for our testing. The reason why the democorp DSA accepts the marco_drew.pem was because of the same trusted.pem was used by the democorp DSA and allowed it to accept the marco_drew.pem certificate. Also, the identity established was the Subject DN that is on the marco_drew certificate. This can be verified through

openssl x509 -in marco_drew.pem -text -noout

This can be further proved by removing the usage of 

LDAPTLS_CACERT=/opt/CA/Directory/dxserver/config/ssld/trusted.pem

and 

TLS_CACERT /opt/CA/Directory/dxserver/config/ssld/trusted.pem

in the original KB as these are the client-side settings.

Also note that marco_drew's certificate does not need to be stored on the democorp DSA at all. The trust is simply the trusted CAs stored in the trusted.pem.