Setting up Security for the CDS Server

Verify that the CDS test data is imported in to the directory server and slapd is running properly.

Use the saslpasswd2 command on the CDS server to create a test user named osmsusr by entering the following:

# /opt/symas/bin/saslpasswd2 -c osmsusr

At the prompt, enter abc123 for the password.

If no user domain is provided to saslpasswd2, the host name of the machine is used as the default domain. If the host name is master, then the user osmsusr@master is created. If you need to use a new domain instead of the default, enter the following command:

# /opt/symas/bin/saslpasswd2 -c osmsusr -u cds.test

After the password is entered, the user osmsusr@cds.test is created.

Run the sasldblistusers2 command to verify that the test user is successfully stored in the SASL sasldb database:

# /opt/symas/bin/sasldblistusers2

The following is displayed:

osmsusr@master: userPassword

On the CDS client machine, use the ldapsearch command with DIGEST-MD5 to query the directory server, on host master, by entering the following:

# /opt/symas/ldapsearch -Y digest-md5 -U osmsusr@master -h \

master -b 'dc=example,dc=com' -s base -LLL

For the user osmsusr@master, enter the test password abc123

The following is displayed:

SASL/DIGEST-MD5 authentication started
Please enter your password:
SASL username: osmsusr@master
SASL SSF: 128
SASL installing layers
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: example

Use the ldapadd command to add the following entry to the CDS server based on the test data:

# /opt/symas/bin/ldapadd -x -D rootdn -w rootpw -h cds_server

dn: uid=osmsusr,ou=people,dc=osm,dc=example,dc=com
objectClass: inetOrgPerson
uid: osmsusr
sn: osms user
cn: osms user
mail: osmsusr@example.com

Use the ldapwhoami command to check the current identity of osmsusr@master by entering the following:

# /opt/symas/bin/ldapwhoami -Y digest-md5 -U osmsusr@master -h master

At the prompt, enter the password. The following is displayed:

SASL/DIGEST-MD5 authentication started
Please enter your password:
SASL username: osmsusr@master
SASL SSF: 128
SASL installing layers
dn:uid=osmsusr@master,cn=digest-md5,cn=auth
Result: Success (0)

Currently the requested DN associated with osmsusr@master is uid=osmsusr@master,cn=digest-md5,cn=auth because the user is not mapped to any DN in the LDAP namespace.

Edit the slapd.conf in the CDS server by adding the following content:

authz-regexp uid="([^,]*)@master",cn=digest-md5,cn=auth
        uid=$1,ou=people,dc=osm,dc=example,dc=com

This regular expression maps all users with the domain of master to the DNs of uid=$1,ou=people,dc=osm,dc=example,dc=com.

Restart the CDS service and verify that no errors occurred by entering the following command:

# /etc/init.d/cdsserver restart

Use the ldapwhoami command to determine the identity of osmsusr@master by entering the following command:

# /opt/symas/bin/ldapwhoami -Y digest-md5 -U osmsusr@master -h master

The following is displayed:

SASL/DIGEST-MD5 authentication started
Please enter your password:
SASL username: osmsusr@master
SASL SSF: 128
SASL installing layers
dn:uid=osmsusr,ou=people,dc=osm,dc=example,dc=com
Result: Success (0)

Now the requested DN of osmsusr@master is uid=osmsusr,ou=people,dc=osm,dc=example,dc=com. Any privileges and restrictions on this DN cause the same effect on osmsusr@master.

To verify the cpksca package has been installed on the Certificate Authority (CA) server, which might be the same machine as the CDS server, enter the following command:

# rpm -qa|grep cpksca

If the cpksca package is not found, download the appropriate version for the cpksca package from the OSMS distribution and use the rpm command to install.

Edit the cds.conf file in the CDS server and make CDS listen on port 636 with the LDAPS protocol by entering the following command to replace the host name or IP address of the CDS server:

HOST_LIST="ldap://<CDS_SERVER_IP_OR_HOSTNAME>:389/ ldaps://<CDS_SERVER_IP_OR_HOSTNAME>:636/"

Create a new CA file on the CA server by entering the following command:

# /opt/symas/bin/CA.sh -newca

	NOTE: A CA is only valid for one year. All certificates signed by this CA become invalid on the date this CA expires.

Enter the full CA server name as Common Name at the appropriate prompts.

Document the PEM pass phrase because it is required when you try to sign a server certificate. By default, the CA file, cacert.pem, is created in /opt/symas/ssl/

Copy the CA file created in step 3 to both the CDS client and the CDS server. For both machines, place the file in the /opt/symas/ssl/ directory.

Edit the ldap.conf file on the CDS client by setting TLS_CACERT to the path of the CA file as follows:

TLS_CACERT /opt/symas/ssl/cacert.pem

Edit the slapd.conf file on the CDS server to set the value of TLSCACertificateFile as follows:

TLSCACertificateFile /opt/symas/ssl/cacert.pem

Generate a certificate for the CDS server by entering the following command:

# /opt/symas/bin/CA.sh -newreq

At the appropriate prompts, enter the fully qualified domain name of the CDS server as Common Name. By default, the certificate request and a private key are stored in a new file named newreq.pem.

Sign the certificate created in step 8 by entering the following command:

# /opt/symas/bin/CA.sh -signreq

When prompted for the the PEM pass phrase, enter the phrase from step 4. After two confirmations, a signed certificate is created in the file newcert.pem.

Copy the newreq.pem file created in step 9 and the newcert.pem file in step 10 to the CDS server, and put them in the /opt/symas/ssl/ directory. On the CDS server, rename the file newreq.pem to serverkey.pem and rename the file newcert.pem to servercert.pem

Add the paths of the server certificate file and key file to the slapd.conf file by setting the values as follows:

TLSCertificateFile /opt/symas/ssl/servercert.pem

TLSCertificateKeyFile /opt/symas/ssl/serverkey.pem

Restart the CDS server by entering the following command:

# /etc/init.d/cdsserver restart

On the CDS client, use the openssl command to verify that the CA file works by entering the following:

# /opt/symas/bin/openssl verify -CAfile /opt/symas/ssl/cacert.pem \

/opt/symas/ssl/cacert.pem

The following displays:

../ssl/cacert.pem: OK

The output might contain the following error message:

error 9 at 0 depth lookup:certificate is not yet valid

If this message is displayed, it means the date of the client machine is invalid for the CA file and you need to adjust the client date to a value later than the date of the CA server.

To verify that TLS is operating correctly, enter the following command on the CDS client:

# /opt/symas/bin/ldapsearch -x -D rootdn -w rootpw -h master \

-b 'dc=example,dc=com' -s base -ZZ -LLL

The option -ZZ instructs the command to start the TLS request.

The following is displayed:

dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: example

Verify that all the steps in “Configuring TLS for Network Encryption ” passed so that TLS is working correctly.

Create and sign the CDS client certificate on the CA server by repeating steps 8 through 10 in “Configuring TLS for Network Encryption ”.

The difference is that the full domain name of the CDS client should be entered as Common Name. Verify that the Email Address is osmsuser@cdsclient.test. If it is empty, enter this e-mail address. Also, verify that the key and the signed certificate are stored in the newreq.pem and newcert.pem files, respectively.

Copy the files newreq.pem and newcert.pem, which were created in step 2, to the CDS client and move them to the /opt/symas/ssl/ directory. Rename the file newreq.pem to clientkey.pem and the file newcert.pem to clientcert.pem.

Set the environment variables by running the following commands:

# export LDAPCONF=home_directory

# export LDAPRC=ldap.rc

The ldap.rc file should be created in the home_directory. If the current login name on the CDS client is root, and the home directory for root is /root, then the commands are as follows:

# export LDAPCONF=/root

# export LDAPRC=ldap.rc

Edit the ldap.rc file by adding the following contents:

Where CDS_SERVER is the host name or IP address of the CDS server.

Add the following directive to the slapd.conf file:

TLSVerifyClient demand

This directive tells the CDS client to provide a valid certificate. If no certificate is provided or the certificate is invalid, the session is terminated immediately.

Restart the CDS server.

Use the ldapsearch command on the CDS client to verify that the EXTERNAL authentication mechanism is working by entering the following command:

# /opt/symas/bin/ldapsearch -b 'dc=osm,dc=example,dc=com' \

-s base -LLL

The following displays:

SASL/EXTERNAL authentication started
SASL username: emailAddress=osmsuser@cdsclient.test,
CN=cdsclient.test,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
SASL SSF: 0
dn: dc=osm,dc=example,dc=com
objectClass: dcObject
objectClass: organizationalUnit
dc: osm

Use the ldapwhoami command to check the DN for the user by entering the following:

# /opt/symas/bin/ldapwhoami

The following is displayed:

SASL/EXTERNAL authentication started
SASL username: emailAddress=osmsuser@cdsclient.test,
CN=cdsclient.test,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
SASL SSF: 0
dn:email=osmsuser@cdsclient.test,cn=cdsclient.test,
o=internet widgits pty ltd,st=some-state,c=au
Result: Success (0)

The DN for the user email=osmsuser@cdsclient.test,cn=cdsclient.test,o=internet widgits pty ltd,st=some-state,c=au can be mapped to the DN in the LDAP namespace by following the steps in “Mapping SASL Users to Distinguish Names”. The only difference is that the directive in slapd.conf is sasl-regexp instead of authz-regexp.