Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
 Contact HP
More options
HP.com home
HP Open Source Middleware Stacks Blueprint:: Directory Services on HP ProLiant and HP Integrity Servers with Red Hat Linux Enterprise Version 5

Setting up Security for the CDS Server

 

Technical documentation

Complete book in PDF
Feedback
Content starts here

  Table of Contents

CDS runs in different computing environments from tightly controlled local networks to the global Internet. It supports many security mechanisms to protect the data stored in the directory servers. Generally, there are three levels of security to configure: file system security, network security, and directory security. This section describes these three security levels respectively.

File System Security

Configuration of file system security is dependent on the security mechanisms of the specific operating system. For example, you can secure CDS configuration files, database files, and other miscellaneous files by setting the ownership and read/write permission of these files. Generally, file system security is configured according to the following rules.

  • All CDS-related files should be owned by the user that executes slapd. This user is usually root.

  • Other users should have read permission only on the ldap.conf file, certificate files, and UNIX sockets. Other users should never be granted write/execute permissions on any CDS-related files.

  • The database directory and the slapd and slapd.conf files and private keys should be accessible to only the owner.

The security configuration of these files is summarized in Table 3.

Table 3 File Security Configurations

File OwnerOther user
ldap.conf Read/WriteRead
Certificate files Read/WriteRead
UNIX sockets Read/WriteRead
Database directory Read/WriteN/A
slapdRead/Write/ExecuteN/A
slapd.confRead/WriteN/A
Private keys Read/WriteN/A

 

Network Security

Because CDS runs in many types of networks, network security is critical. CDS supports two mechanisms which can be used to configure network security: Simple Authenticating and Security Layer (SASL) framework and Transport Layer Security (TLS).

Using Simple Authenticating and Security Layer

SASL supports several industry-standard authentication mechanisms, including GSSAPI for Kerberos V, DIGEST-MD5, PLAIN, and EXTERNAL for use with TLS. By default, all LDAP commands use SASL for authentication. Use the -x option with the LDAP commands if you want to select Simple Authentication security instead of SASL.

This section provides the steps for configuring SASL with the DIGEST-MD5 and EXTERNAL mechanism.

Configuring SASL with DIGEST-MD5

In the DIGEST-MD5 security mechanism, when authentication begins, the server generates a secure message and the client sends a response proving it knows the secure message. Because the secure message is not sent over the wire, this mechanism is more secure than Simple Authentication.

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

  2. 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

  3. 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.

  4. 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

  5. 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

  6. 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
Mapping SASL Users to Distinguish Names

When DIGEST-MD5 is used for authentication, all user names are stored in SASL's own database. The user names are in the namespace of the authentication mechanism, and not in the normal LDAP namespace. Each user name is reformatted into a request Distinguish Name (DN) in the following form:

uid=<username>, cn=<realm>, cn=<mechanism>, cn=auth

If no realm is used, which means no sasl-realm property is configured in the slapd.conf file, then the request of DNs for SASL users is in the following form:

uid=<username>, cn=<mechanism>, cn=auth

The ldapwhoami command can be used to check the identity for a user.

The following steps describe how to map the SASL user, osmsusr@master, to a DN in the LDAP namespace that is in the form:

uid=osmsusr,ou=people,dc=osm,dc=example,dc=com

  1. 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
  2. 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

  3. 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.

  4. 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.

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

    # /etc/init.d/cdsserver restart

  6. 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.

Using TLS

TLS is almost identical to SSL. It provides lower network security services and integrity and confidentiality protections for directory servers. Combined with the EXTERNAL mechanism of SASL, TLS can offer strong authentication.

TLS uses the X.509 certificates to carry client and server identities. All servers must have valid certificates, but client certificates are optional. If SASL EXTERNAL is used for authentication, clients must own valid certificates as well. All certificates can be created and managed by the cpksca package provided by CDS.

Configuring TLS for Network Encryption
  1. 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.

  2. 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/"

  3. 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.
  4. 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/

  5. 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.

  6. 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

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

    TLSCACertificateFile /opt/symas/ssl/cacert.pem

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

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

  9. 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.

  10. 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.

  11. 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

  12. 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

  13. Restart the CDS server by entering the following command:

    # /etc/init.d/cdsserver restart

  14. 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.

  15. 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
Using the EXTERNAL Authentication Mechanism with TLS

TLS provides strong authentication when used with the EXTERNAL mechanism. CDS clients must have a valid certificate to identify themselves. All authentication information for clients must be written to a configuration file that is specified by the environment variable LDAPRC. The following steps describe how to configure the EXTERNAL mechanism with TLS.

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

  2. 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.

  3. 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.

  4. 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

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

    URI ldaps://<CDS_SERVER>:636/ BASE dc=example,dc=com SASL_MECH EXTERNAL TLS_CERT /opt/symas/ssl/clientcert.pem TLS_KEY /opt/symas/ssl/clientkey.pem

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

  6. 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.

  7. Restart the CDS server.

  8. 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
  9. 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.

Directory Security

Access to the slapd entries and attributes stored in the CDS server is controlled by the Access Control Lists (ACLs) which are configured by access directives in the file slapd.conf. The structure of the access control directives is as follows:

access to <what> [ by <who> <access> [ <control> ] ]

The <what> field specifies the entries or attributes the access directive applies to. It can have the following forms:

dn.<dnstyle>=<DN>
filter=<ldapfilter>
attrs=<attrlist>

The <who> field means what types of users the access directive applies to. There may be multiple <who> fields in an access directive, indicating different users are granted different privileges on the same resource. It can have the following forms:

*
anonymous
users
self
dn.<dnstyle>=<DN>
dnattr=<attrname>
group=<group>
peername=<peername>
sockname=<sockname>
domain=<domain>
sockurl=<sockurl>

The <access> field indicates the specific privileges <who> is granted. It can have one of the following values:

none auth compare search read write

The <control>field is optional. It controls the flow of the access rule application. It can have one of the following values:

stop
continue
break

For more information on access directives, visit the Web site located at:

http://www.openldap.org/doc/admin23/slapdconf2.html#Access%20Control

In the following example, five DNs are created as the users. They are granted different privileges on the ou attribute and the userPassword attribute of dc=osm,dc=example,dc=com.

  1. Verify that the CDS test data has been added to the CDS server by entering the following command on the CDS server:

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

  2. Add the following DNs as the test users using the ldapadd command as follows:

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

    dn: dc=dn1,dc=example,dc=com
    objectClass: dcObject
    objectClass: organizationalUnit
    dc: dn1
    ou: dn1
    
    dn: dc=dn2,dc=example,dc=com
    objectClass: dcObject
    objectClass: organizationalUnit
    dc: dn2
    ou: dn2
    
    dn: dc=dn3,dc=example,dc=com
    objectClass: dcObject
    objectClass: organizationalUnit
    dc: dn3
    ou: dn3
    
    dn: dc=dn4,dc=example,dc=com
    objectClass: dcObject
    objectClass: organizationalUnit
    dc: dn4
    ou: dn4
    
    dn: dc=dn5,dc=example,dc=com
    objectClass: dcObject
    objectClass: organizationalUnit
    dc: dn5
    ou: dn5
  3. For each DN created in step 2, set the test password to abc123 using the ldappasswd command. For example, enter the following command to set a password for dc=dn1,dc=example,dc=com:

    # /opt/symas/bin/ldappasswd -x -D rootdn -w rootpw \

    -h cds_server -s abc123 dc=dn1,dc=example,dc=com

  4. Add the following access directives to the slapd.conf file:

    access to dn="dc=osm,dc=example,dc=com" attrs=ou,userPassword 
    by dn="dc=dn1,dc=example,dc=com" none
        by anonymous auth
        by dn="dc=dn2,dc=example,dc=com" compare
        by dn="dc=dn3,dc=example,dc=com" search
        by dn="dc=dn4,dc=example,dc=com" read
        by dn="dc=dn5,dc=example,dc=com" write
    NOTE: You must input a tab before the line " by dn=" otherwise the ACL will not work.

    These directives should be placed before the default access directives:

    access to *
            by self write
            by users read
            by anonymous auth
  5. Restart the CDS server and verify that no errors occurred by entering the following command:

    # /etc/init.d/cdsserver restart

  6. Use the ldapcompare command with 'dc=dn1,dc=example,dc=com' as the user to verify that the user has no privileges to perform compare operations on the DN:

    # /opt/symas/bin/ldapcompare -x -D 'dc=dn1,dc=example,dc=com' \

    -w abc123 -h cds_server dc=osm,dc=example,dc=com ou:osm

    Because the user 'dc=dn1,dc=example,dc=com' is assigned a privilege value of none, it cannot perform any operations on the specified resource.

    The following output displays:

    Compare Result: Insufficient access (50)

    UNDEFINED

  7. To test the compare privilege of the user 'dc=dn2,dc=example,dc=com' use the ldapcompare by entering the following:

    # /opt/symas/bin/ldapcompare -x -D 'dc=dn2,dc=example,dc=com' \

    -w abc123 -h cds_server dc=osm,dc=example,dc=com ou:osm

    The return value, TRUE indicates that the user 'dc=dn2,dc=example,dc=com' can perform the compare operation on the ou attribute of dc=osm,dc=example,dc=com and the value of the ou attribute is equal to osm.

  8. Use the ldapsearch command to verify that the user 'dc=dn2,dc=example,dc=com' cannot perform the search operation on the specific resource by entering the following:

    # /opt/symas/bin/ldapsearch -x -D 'dc=dn2,dc=example,dc=com' \

    -w abc123 -h cds_server ou=osm

    The following is displayed:

    # extended LDIF
    #
    # LDAPv3
    # base <> with scope subtree
    # filter: ou=osm
    # requesting: ALL
    #
    
    # search result
    search: 2
    result: 0 Success
    
    # numResponses: 1

    No DNs are displayed even though the DN 'dc=osm,dc=example,dc=com' with ou equal to osm does exist in the CDS database, indicating that the user dc=dn2,dc=example,dc=com is not granted the search privilege.

  9. Use the ldapsearch command with the user 'dc=dn3,dc=example,dc=com' to verify the search privilege has been granted and takes effect:

    # /opt/symas/bin/ldapsearch -x -D 'dc=dn3,dc=example,dc=com' \

    -w abc123 -h cds_server ou=osm -LLL

    The following is displayed:

    dn: dc=osm,dc=example,dc=com
    objectClass: dcObject
    objectClass: organizationalUnit
    dc: osm

    The DN dc=osm,dc=example,dc=com is searched out but the attributes of ou and userPassword are not listed because the user 'dc=dn3,dc=example,dc=com' does not have read privileges on these two attributes.

  10. Use the ldapsearch command with 'dc=dn4,dc=example,dc=com' to test the user's read privilege by entering the following command:

    # /opt/symas/bin/ldapsearch -x -D 'dc=dn4,dc=example,dc=com' \

    -w abc123 -h cds_server ou=osm -LLL

    The following is displayed:

    dn: dc=osm,dc=example,dc=com
    objectClass: dcObject
    objectClass: organizationalUnit
    dc: osm
    ou: osm
    userPassword:: e1NTSEF9ajJBQjhFUmNvZitTV0V5Rkp3ZGtjWE5va0J6ODFYa0g=

    Because the user dc=dn4,dc=example,dc=com is granted the read privilege, the ou and userPassword attributes are displayed in the results.

  11. Create a modify.ldif file, to verify that the user dc=dn4,dc=example,dc=com cannot modify the ou attribute of dc=osm,dc=example,dc=com, using the following content:

    dn: dc=osm,dc=example,dc=com
    changetype: modify
    replace: ou
    ou: osm.test

    Notice that in the file, the value of ou is changed to osm.test.

  12. Using the ldapmodify command and the user dc=dn4,dc=example,dc=com, apply the entry modification in the modify.ldif created in step 11 by entering the following command:

    # /opt/symas/bin/ldapmodify -x -D 'dc=dn4,dc=example,dc=com' \

    -w abc123 -h cds_server -f /tmp/modify.ldif

    The following is displayed:

    modifying entry "dc=osm,dc=example,dc=com" ldap_modify: Insufficient access (50)

    This message means that the user dc=dn4,dc=example,dc=com has no privileges to write the ou attribute of dc=osm,dc=example,dc=com.

  13. Now, use the same ldapmodify command with the user dc=dn5,dc=example,dc=com to verify the user has been given write privileges, by entering the following command:

    # /opt/symas/bin/ldapmodify -x -D 'dc=dn5,dc=example,dc=com' \

    -w abc123 -h cds_server -f /tmp/modify.ldif

    If write privileges are successfully granted, the following message displays:

    modifying entry "dc=osm,dc=example,dc=com"

  14. Use the ldapsearch command to verify the attributes of dc=osm,dc=example,dc=com have been successfully changed, by entering the following command:

    # /opt/symas/bin/ldapsearch -x -D 'dc=dn5,dc=example,dc=com' \

    -w abc123 -h cds_server -b 'dc=osm,dc=example,dc=com' -s base -LLL

    The following message is displayed:

    dn: dc=osm,dc=example,dc=com
    objectClass: dcObject
    objectClass: organizationalUnit
    dc: osm
    userPassword:: e1NTSEF9ajJBQjhFUmNvZitTV0V5Rkp3ZGtjWE5va0J6ODFYa0g=
    ou: osm.test

    Notice that in the file, the value of ou is changed to osm.test because dc=dn5,dc=example,dc=com is granted the write privilege. It can also search and read the values of ou and userPassword, as specified in the ACLs

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
2007 Hewlett-Packard Development Company, L.P.