|
| |
| Sun Java(TM) System Directory Server 5 2004Q2 Technical Overview | |
Chapter 5
Directory Server SecurityThis chapter examines the crucial aspect of security and what functionality Directory Server provides to address the principle threats to directory security, which are generally either related to unauthorized access, unauthorized tampering or denial of service attacks. This chapter is divided into the following sections:
Directory Server Security Overview
Your security policy must be strong enough to prevent sensitive information from being modified or retrieved by unauthorized users, but simple enough to administer easily. A complex security policy can lead to mistakes that either prevent people from accessing the information that you want them to access or, worse, allow people to modify or retrieve directory information that you do not want them to access. The following sections outline Directory Server’s security possibilities:
A means for one party to verify another’s identity. For example, a client gives a password to Directory Server during an LDAP bind operation.
Disables a user account, group of accounts, or an entire domain so that all authentication attempts are automatically rejected.
Defines the criteria that a password must satisfy to be considered valid, for example, age, length, and syntax.
A means of protecting sensitive data by scrambling it in a way that only authorized users have the means of decrypting.
Tailors the access rights granted to different directory users, and provides a means of specifying required credentials or bind attributes.
Maintains the integrity of information. If encryption and message digests are applied to the information being sent, the recipient can determine that it was not tampered with during transit.
Allows you to determine if the security of your directory has been compromised. For example, a basic audit procedure is to automate testing using a network-based security scanner that identifies vulnerabilities on your network. You can also conduct audits by examining the log files and the information recorded by the SNMP agents.
Authentication and Account Inactivation
While it may seem simple to protect your directory from unauthorized access, the problem can in fact be extremely complex. To have a secure directory it is necessary to protect against unauthorized access which can occur both from inside your company and outside your company if it is connected to an extranet or to the Internet.
Directory Server supports the following authentication mechanisms:
For more detail on these authentication mechanisms see the Selecting Appropriate Authentication Methods section in the Directory Server Deployment Planning Guide.
The account inactivation functionality in Directory Server, which allows you to temporarily inactivate a user account or a set of accounts, is essential to your directory security. Once inactivated, a user cannot bind to Directory Server, and the authentication operation fails. Account inactivation is implemented through an account lock attribute, which, when enabled, causes the server to automatically reject the bind operation.
Account Inactivation can be combined with the roles functionality to enable you to inactivate all members of a given role should that kind of account inactivation become necessary. The combined use of roles and account inactivation provides scalable security functionality, a must in the enterprise context.
Controlling Access
Controlling access enables you to specify that certain clients have access to particular information, while other clients do not. You implement access control using one or more access control lists (ACLs). ACLs consist of a series of access control instructions (ACIs) that either allow or deny permissions (such as read, write, search, proxy, add, delete, and compare) to specified entries and their attributes. Directory Server’s access control mechanism provides fine-grained, flexible access control in that it allows you to set permissions for either:
Add to this fine-grained, flexible model the fact that you can set permissions for a specific user, for all users belonging to a set (be it a group or a role), or for all users of the directory and you understand how powerful Directory Server’s access control model is. This section examines the following:
Access Control - The Basics
ACIs are stored in the directory, as attributes of entries. The aci attribute is an attribute which is available for use on every entry in the directory and is used by Directory Server to evaluate what rights are granted or denied when it receives an LDAP request from a client. The aci attribute can be returned in an ldapsearch operation if specifically requested. A sample aci attribute follows:
aci: (target)(version 3.0;acl "name";permission bindRules;)
where
- target which specifies the entry, attributes, or set of entries and attributes for which you want to control access
- version 3.0 is a required string which identifies the ACI version
- name is a name which is a name for the ACI. This ACI name is required and should describe the effect of the ACI
- permission is a permission which specifically states what rights the ACI either allows or denies
- bindRules specifies the credentials and bind parameters that a user has to provide to be granted access.
When you install Directory Server, or when you add a new suffix, a number of default ACIs are defined. These ACIs can be modified to suit your security requirements. The default policy is not to grant users access rights, which means that you must begin by setting some ACIs to enable your users to access the directory. The access control mechanism precedence rule states that when two conflicting permissions exist the permission that denies access always takes precedence over the permission that grants access, which means that you need to be careful when explicitly denying access that you do not end up denying more access than you actually intended.
One of the more powerful features of the Directory Server access control model is the ability to use LDAP search filters to set access control. LDAP search filters enable you to set access to any directory entry that matches a set of defined criteria. For an example of how this might work see the Setting Permissions section of the Directory Server Deployment Planning Guide.
Macro ACIs
Directory Server provides the Macro ACI functionality for optimizing the number of ACIs in your directory, which is particularly useful given that ACIs can have a noticeable impact on memory consumption. Macro ACIs are placeholders that are used to represent a DN, or a portion of a DN, in an ACI. You can use a macro to represent a DN in the target portion of the ACI, in the bind rule portion, or both. When Directory Server receives an LDAP request, the macro ACIs are matched against the resource targeted by the LDAP operation. If there is a match, the macro is replaced by the value of the DN of the targeted resource. Directory Server then evaluates the ACI normally.
Requesting Effective Rights Information
This ability to request the rights of a given user to directory entries and attributes is provided by the Effective Rights LDAP control supported by both the console and LDAP search. This Effective Rights functionality helps you administer and debug Directory Server’s powerful access control mechanism, which in the enterprise and E-business context is sometimes no mean task. See the section Effective Rights Management for further information.
ACIs - The Tips
There are many simple tips which can help facilitate access control management and improve directory performance. Although many of them constitute basic common sense such as keeping the number of ACIs in your directory to a minimum and naming them meaningfully, it is important to bear these tips in mind when implementing access control. For a complete list of ACI tips refer to the Tips on Using ACIs section in the Directory Server Deployment Planning Guide.
Password Policy
Password Policy Overview
A password policy is a set of rules that govern how passwords are administered in a given system.
The password policy functionality provided by Directory Server enables you to configure multiple password policies as opposed to one global policy for your entire directory. You can also assign password policies either to particular users or to sets of users using the Class of Service (CoS) and roles functionality. This provides significantly more scope when implementing password policy security measures, because you can tailor password policies to specific users or roles. Password policy governs the following:
- User-Defined Passwords - whether or not your password policy allows for user-defined passwords.
- Password Change at First Login or Reset - whether or not your password policy forces users to change their password at the first login or after a password has been reset by an administrator.
- Password Expiration - whether or not passwords can be used indefinitely or expire after a given time. By default, user passwords never expire.
- Expiration Warning - specifies when you send out your password expiration warning.
- Password Syntax Checking - whether or not your password policy enforces use of the syntax checking mechanism, to ensure password string compliance with guidelines.
- Password Length - specifies the minimum length for user passwords.
- Password Minimum Age - specifies whether your password policy prevents users from changing their passwords within a specified period, which can be used in conjunction with the password history feature to discourage users from reusing old passwords.
- Password History - specifies the maximum number of passwords that can be stored in the password history.
- Password Storage Scheme - specifies the type of encryption used to store passwords within the directory, be it clear text (no encryption), Secure Hash Algorithm (SHA), Salted Secure Hash Algorithm (SSHA), or UNIX CRYPT algorithm.
For a more detailed insight into each of these password policy features, refer to the Password Policy Features section in the Directory Server Deployment Planning Guide.
Configuring Password Policies
In previous releases of Directory Server, the only password policy that existed was a global policy (see the Global Password Policy section of the Directory Server Deployment Planning Guide for the default values), which although it could be adapted, meant that the same password policy had to be applied across the board. This global password policy was backed up by the hard-coded password policy, whenever the global password policy was either absent or, following modifications, no longer valid.
Now Directory Server allows the user to configure multiple password policies and choose to assign them either to particular users or to whole sets of users using the CoS and roles functionality. This flexible password policy scheme allows you to create password policies that meet security requirements for specific users or roles.
For example, an ISP decides it needs three password policies. Clients have passwords that never need to be changed. Internally, employees have passwords that they must change every month. Administrators, however, have to change their password every week, and the password must be 8 characters in length. Using the multiple password policy feature, each of these policies can be assigned to users using roles and class of service.
This new password policy design provides you maximum flexibility for adapting the Directory Server to the needs of your business model. In this multiple password policy context, it is worth noting that the following order of precedence applies:
- A password policy generated by a CoS definition will take precedence over a password policy assigned directly to the user entry.
- A password policy assigned directly to a user entry will take precedence over the global password policy.
- The global password policy, stored under cn=Password Policy,cn=config, will take precedence over the hard-coded password policy values provided with Directory Server.
Caution
There are certain considerations to be taken into account regarding password policies in replicated environments. For more information see the Password Policies in a Replicated Environment section of the Directory Server Deployment Planning Guide.
Preventing Dictionary-Style Attacks
In a dictionary-style attack, an intruder attempts to crack a password by repeatedly guessing the password until gaining authorization. The server provides three tools to help counter such attacks:
- Password syntax checking verifies that a password does not match values of the uid, cn, sn, givenName, ou, or mail attributes of the user entry. The server will not allow a user to set a password if it matches one of these values. However, syntax checking does not thwart actual dictionary attacks, in which the intruder tries every word in /usr/dict/words, for example.
- A minimum password length ensures that the user cannot set a short password. Passwords with more characters are exponentially harder to guess or attempt all values.
- The account lockout mechanism prevents binding after a certain number of failed authentication attempts. The lockout may either be temporary or permanent, depending on how strict you wish to make your password policy. Note that account lockout counters are local to a Directory Server. This feature is not designed as a global lockout from your directory service, which means that even in a replicated environment, account lockout counters are not replicated.
Controls for Resetting Passwords
Passwords can be reset using a new modification request control that checks an ACI to confirm that the client binding to the directory is allowed to make the change. The directory manager can configure an administrator group with members who have the appropriate privileges to update passwords.
Securing Connections and Data Storage
When you are using the directory to support exchanges with business partners over an extranet, or to support e-commerce applications with customers on the Internet, you must ensure the privacy and the integrity of the data exchanged. If intruders gain access to your directory or intercept communication between Directory Server and a client application, they have the potential to tamper with either directory data or directory configuration data. Your directory is rendered useless if the data can no longer be trusted by clients, or if the directory itself cannot trust the modifications and queries it receives from clients. Directory Server allows you to secure your connections and data storage and this section examines these areas in more detail:
SSL Encryption and Authentication
It is essential to protect the integrity of the information in transit over the network between servers and client applications. In order to respond to this security necessity Directory Server supports LDAPS, the standard LDAP protocol that runs on top of Secure Sockets Layer (SSL). SSL provides encrypted communications and optional authentication between Directory Server and its clients.
SSL may be enabled for both the LDAP and DSML/HTTP protocols to provide security for any connection to the server. You can use an SSL connection to bind to the server in combination with certificate-based authentication, providing higher levels of security than password checks alone. You can also configure replication to use SSL for secure communications between servers, preventing anyone from snooping your data. After a secure connection has been established, the SSL protocol requires the server to send its certificate to the client. Using public-key cryptography, the client can determine the authenticity of the certificate and verify that it was issued by a certificate authority that the client trusts. By verifying the certificate, the client can prevent a man-in-the-middle impersonation of the server by a third party.
Directory Server is capable of simultaneous SSL and non-SSL communications on separate ports. However, for security reasons, you may also restrict all communications to the secure port.
For further detail on the encryption and hashing algorithms (or ciphers), Directory Server can use see the Securing Connections With SSL section in the Directory Server Deployment Planning Guide. SSL uses encryption for privacy and hashing of checksums for data integrity. For background information regarding the use of SSL and TLS with Sun Java System servers see the Chapter 9 “Using SSL and TLS with Sun Java System Server” in the Administration Server Administration Guide.
Start Transport Layer Security
Directory Server supports the Start Transport Layer Security (Start TLS) extended operation to enable TLS on an LDAP connection that was originally not encrypted. StartTLS is supported on Windows and UNIX platforms and consitutes a more recent version of the SSL protocol.
StartTLS allows you to have a secure connection even if you do not have a dedicated encrypted port. You can open a secure connection over the regular LDAP port.
For background information regarding the use of SSL and TLS with Sun Java System servers see the Chapter 9 “Using SSL and TLS with Sun Java System Server” in the Administration Server Administration Guide.
SASL Encryption and Authentication
Client authentication to the server provides the highest level of security by ensuring that no third party may intercept or interfere with the communication between the client and the server. Directory Server supports authentication and encryption using the Simple Authentication and Security Layer (SASL). The SASL mechanism is responsible for authenticating a user through SASL credentials.
On Solaris systems, Directory Server supports the Generic Security Services API (GSSAPI) over SASL. The GSSAPI allows you to use a third-party security system such as Kerberos version 5 to authenticate clients. The server uses this API to validate the identity of the user. Then, the SASL mechanism applies the GSSAPI mapping rules to obtain a DN, which is the bind DN for all operations during this connection.
Client authentication may also be performed using DIGEST-MD5, a SASL-based mechanism of authenticating clients by comparing a hashed value the client sends with a hash of the user’s password. Because the mechanism must read user passwords, you must use a reversible encryption method for the passwords of all users who want to be authenticated through DIGEST-MD5 or store these passwords in the directory in clear text.
SASL provides advanced security, allowing Directory Server to adapt to the security standards already established within your enterprise.
Attribute Encryption
As we have already seen Directory Server provides a variety of features to protect data at access level (during reads and writes to the directory), including simple password authentication, certificate-based authentication, Secure Sockets Layer (SSL), and proxy authorization. However, there is often an additional need to protect data either when it is being stored in database files, backup files, and LDIF files, or being exported. Consider a bank storing 4-digit PIN codes in the directory. If the database files were unprotected and were dumped, unauthorized users could have access to this sensitive information. The Directory Server attribute encryption feature provides this kind of data protection, crucial to your directory’s security.
Attribute encryption is transparent to the user, who can perform LDAP operations without being aware of encryption. However, should you need to, it is possible to export data that remains encrypted, allowing for example, two servers to share secure files for updates.
The Directory Server attribute encryption feature is configured at database level, which means that once you decide to encrypt an attribute, that attribute will be encrypted for every entry in the database. However, it is worth noting that because attribute encryption occurs at an attribute level, the only way to encrypt an entire entry is to encrypt all of its attributes. The set of encryption algorithms provided by Directory Server can be used across different platforms to encrypt and decrypt attributes on disk, thus increasing the security of your data.
While attribute encryption offers increased data security, it does incur certain performance costs. Bearing this in mind, think carefully about which attributes require encryption and encrypt only those attributes you consider to be particularly sensitive. Note also that because sensitive data can be accessed directly through index files, it is necessary to encrypt the index keys corresponding to the encrypted attributes, to ensure that the attributes are fully protected. Given that indexing already has an impact on Directory Server performance (without the added cost of encrypting index keys), configure attribute encryption before data is imported or added to the database for the first time, so that encrypted attributes are indexed as such from the outset.
For further detail on how attribute encryption is implemented and certain usage considerations, refer to the Encrypting Attributes section in the Directory Server Deployment Planning Guide.
Denial of Service Attacks
Being able to guard against denial of service attacks where the attacker’s goal is to prevent the directory from providing service to its clients simply by using the system’s available resources, is an essential area of security functionality. Directory Server allows you to set limits on the resources allocated to a particular bind DN, thus providing a protection against such attacks. For details on how to configure these protective limits see the Setting Individual Resource Limits section of the Directory Server Administration Guide.