|
» |
|
|
|
| | |
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 | Owner | Other user |
---|
ldap.conf | Read/Write | Read | Certificate files | Read/Write | Read | UNIX sockets | Read/Write | Read | Database directory | Read/Write | N/A | slapd | Read/Write/Execute | N/A | slapd.conf | Read/Write | N/A | Private keys | Read/Write | N/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 LayerSASL 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-MD5In 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. 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 |
Mapping SASL Users to Distinguish NamesWhen 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 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.
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 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 |
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. 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: 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. 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.
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: 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. 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 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 |
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 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 |
Restart the CDS server and verify that no errors occurred
by entering the following command: # /etc/init.d/cdsserver restart 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 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. 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. 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. 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. 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. 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. 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" 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
|