Sun Java System Directory Server Enterprise Edition 6.3 Deployment Planning Guide

Chapter 7 Identifying Security Requirements

How you secure data in Directory Server Enterprise Edition has an impact on all other areas of design. This chapter describes how to analyze your security needs and explains how to design your directory service to meet those needs.

This chapter covers the following topics:

Security Threats

The most typical threats to directory security include the following:

Overview of Security Methods

A security policy must be able to prevent sensitive information from being modified or retrieved by unauthorized users, but easy enough to administer.

Directory Server Enterprise Edition provides the following security methods:

These security tools can be used in combination in your security design. You can also use other features of the directory, such as replication and data distribution, to support your security design.

Determining Authentication Methods

Directory Server Enterprise Edition supports the following authentication mechanisms:

The same authentication mechanism applies to all users, whether the users are people or LDAP-aware applications.

Apart from the authentication mechanisms described above, this section also includes the following information about authentication:

Anonymous Access

Anonymous access is the simplest form of directory access. Anonymous access makes data available to any directory user, regardless of whether the user has authenticated.

Anonymous access does not allow you to track who is performing searches or what kind searches are being performed, only that someone is performing searches. When you allow anonymous access, anyone who connects to your directory can access the data. If you allow anonymous access to data, and attempt to block a user or group from that data, the user can access the data by binding to the directory anonymously.

You can restrict the privileges of anonymous access. Usually, directory administrators allow anonymous access only for read, search, and compare privileges. You can also limit access to a subset of attributes that contain general information such as names, telephone numbers, and email addresses. Do not allow anonymous access to sensitive data, such as government identification numbers, home telephone numbers and addresses, and salary information.

Anonymous access to the root DSE (base DN "") is required. Access to the root DSE enables applications to discover the capabilities of the server, the supported security mechanisms, and the supported suffixes.

Simple Password Authentication

If anonymous access is not set up, a client must authenticate to Directory Server to access the directory contents. With simple password authentication, a client authenticates to the server by providing a simple, reusable password.

The client authenticates to Directory Server through a bind operation in which the client provides a distinguished name and credentials. The server locates the entry that corresponds to the client DN, then checks whether the client's password matches the value stored with the entry. If the password matches, the server authenticates the client. If the password does not match, the authentication operation fails and the client receives an error message.

Note –

The drawback of simple password authentication is that the password is transmitted in clear text, which can compromise security. If a rogue user is listening, that user can impersonate an authorized user.

Simple password authentication offers an easy way of authenticating users. However, you need to restrict the use of simple password authentication to your organization’s intranet. This kind of authentication does not offer the level of security that is required for transmissions between business partners over an extranet or for transmissions with customers on the Internet.

Simple Password Authentication Over a Secure Connection

A secure connection uses encryption to make data unreadable to third parties while the data is sent over the network between Directory Server and its clients. Clients can establish secure connections in either of the following ways:

In either case, the server must have a security certificate, and the client must be configured to trust this certificate. The server sends its certificate to the client to perform server authentication, using public-key cryptography. This results in the client knowing that it is connected to the intended server and that the server is not being tampered with.

Then, for privacy, the client and server encrypt all data transmitted through the connection. The client sends the bind DN and password on the encrypted connection to authenticate the user. All further operations are performed with the identity of the user. The operations might also be performed with a proxy identity if the bind DN has proxy rights to other user identities. In all cases, the results of operations are encrypted when these results are returned to the client.

Certificate-Based Client Authentication

When establishing encrypted connections over SSL or TLS, you can also configure the server to require client authentication. The client must send its credentials to the server to confirm the identity of the user. The user's certificate, not the DN, is used to determine the bind DN. Client authentication protects against user impersonation and is the most secure type of connection.

Certificate-based client authentication operates at the SSL, TLS layer only. To use a certificate-based authentication ID with LDAP, you must use SASL EXTERNAL authentication after establishing the SSL connection.

You can configure certificate-based client authentication by using the dsconf get-server-prop command. See dsconf(1M) for more information.

SASL-Based Client Authentication

Client authentication during an SSL or TLS connection can also use the Simple Authentication and Security Layer (SASL), a generic security interface, to establish the identity of the client. Directory Server Enterprise Edition supports the following mechanisms through SASL:

For more information, see Using SASL DIGEST-MD5 in Clients in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide and Using Kerberos SASL GSSAPI in Clients in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

Preventing Authentication by Account Inactivation

You can temporarily prevent authentication by inactivating a user account or a set of accounts. When the account is inactivated, the user cannot bind to Directory Server, and authentication operations fail. For more information, see Manually Locking Accounts in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

Preventing Authentication by Using Global Account Lockout

In this version of Directory Server, authentication failures with a password are monitored and replicated. This enables rapid, global account lockout after a specified number of authentication attempts with an invalid password. Global account lockout is supported in any of the following cases:

Imagine a situation where all bind attempts are not directed to the same server, and the client application performs bind attempts on multiple servers faster than lockout data can be replicated. In the worst-case scenario, the client would be allowed the specified number of attempts on each server where the client attempted to bind. This situation would be unlikely if the client application were driven by input from a human user. However, an automated client built to attack a topology could exploit this deployment choice.

Prioritized replication can be used to minimize the impact of asynchronous replication latency on intrusion detection. However, you might require account lockout immediately after the specified number of failed bind attempts. In this situation, you must use Directory Proxy Server to route all bind attempts on a particular entry to the same master replica. For information about how to configure Directory Proxy Server to do this, see Operational Affinity Algorithm for Global Account Lockout in Sun Java System Directory Server Enterprise Edition 6.3 Reference.

To retain a strictly local lockout policy in a replicated topology, you must maintain compatibility with the 5.2 password policy. In this situation, the policy in effect must not be the default password policy. Local lockout can also be achieved by restricting binds to read-only consumers.

For detailed information about how global account lockout works, see Global Account Lockout in Sun Java System Directory Server Enterprise Edition 6.3 Reference.

External Authentication Mappings and Services

Directory Server provides user account host mapping, which associates a network user account with a Directory Server user account. This feature simplifies the management of both user accounts. Host mapping is required for users who are externally authenticated.

Proxy Authorization

Proxy authorization is a special form of access control. Proxy authorization or proxy authentication is when an application is forced to use a specific username/password combination to gain access to the server.

With proxy authorization, an administrator can request access to Directory Server by assuming the identity of a regular user. The administrator binds to the directory with his own credentials and is granted the rights of the regular user. This assumed identity is called the proxy user. The DN of that user is called the proxy DN. The proxy user is evaluated as a regular user. Access is denied if the proxy user entry is locked or inactivated or if the password has expired.

An advantage of the proxy mechanism is that you can enable an LDAP application to use a single bind to service multiple users who are accessing Directory Server. Instead of each user having to bind and authenticate, the client application binds to Directory Server and uses proxy rights.

For more information, see Chapter 7, Directory Server Access Control, in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

Designing Password Policies

A password policy is a set of rules that govern how passwords are administered in a system. Directory Server supports multiple password policies, as well as a default password policy.

Several elements of the password policy are configurable, enabling you to design a policy that suits the security requirements of your organization. Configuration of the password policy is described in Chapter 8, Directory Server Password Policy, in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide. The individual attributes available for configuring password policies are described in the pwpolicy(5dssd) man page.

This section is divided into the following topics:

Password Policy Options

The following password policy options are provided:

Password Policies in a Replicated Environment

Configuration information for the default password policy is not replicated. Instead, it is part of the server instance configuration. If you modify the default password policy, the same modifications must be made on each server in the topology. If you need a password policy that is replicated, you must define a specialized password policy under a part of the directory tree that is replicated.

All password information that is stored in the user entry is replicated. This information includes the current password, password history, password expiration dates and so forth.

Consider the following impact of password policies in a replicated environment:

Password Policy Migration

The Directory Server Enterprise Edition password policy configuration settings differ from the password policy configuration settings provided with the 5.x version of Directory Server. If your topology includes servers that run different versions of Directory Server, see New Password Policy in Sun Java System Directory Server Enterprise Edition 6.3 Migration Guide for information about how to migrate password policy settings.

Password Synchronization With Windows

Identity Synchronization for Windows synchronizes user account information, including passwords, between Directory Server and Windows. Both Windows Active Directory and Windows NT are supported. Identity Synchronization for Windows helps build a scalable and security-enriched password synchronization solution for small, medium, and large enterprises.

This solution provides the following:

For more information about using Identity Synchronization for Windows in your deployment, see the Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide.

Determining Encryption Methods

Encryption helps to protect data in transit, as well as stored data. This section describes the following methods of data encryption:

Securing Connections With SSL

Security design involves more than an authentication scheme for identifying users and an access control scheme for protecting information. You must also protect the integrity of information between servers and client applications while it is being sent over the network.

To provide secure communications over the network, you can use both the LDAP and DSML protocols over the Secure Sockets Layer (SSL). When SSL is configured and activated, clients connect to a dedicated secure port where all communications are encrypted after the SSL connection is established. Directory Server and Directory Proxy Server also support the Start Transport Layer Security (Start TLS) control. Start TLS allows the client to initiate an encrypted connection over the standard LDAP port.

For an overview of SSL and TLS in Directory Server, see Chapter 2, Directory Server Security, in Sun Java System Directory Server Enterprise Edition 6.3 Reference.

Encrypting Stored Attributes

Attribute encryption concerns the protection of stored data. This section describes the attribute encryption functionality, and covers the following topics:

What Is Attribute Encryption?

Directory Server Enterprise Edition provides various features to protect data at the access level, including password authentication, certificate-based authentication, SSL, and proxy authorization. However, the data stored in database files, backup files, and LDIF files must also be protected. The attribute encryption feature prevents users from accessing sensitive data while the data is stored.

Attribute encryption enables certain attributes to be stored in encrypted form. Attribute encryption is configured at the database level. Thus, after an attribute is encrypted, the attribute is encrypted in every entry in the database. Because attribute encryption occurs at the attribute level (not the entry level), the only way to encrypt an entire entry is to encrypt all of its attributes.

Attribute encryption also enables you to export data to another database in an encrypted format. The purpose of attribute encryption is to protect sensitive data only when the data is being stored or exported. Therefore, the encryption is always reversible. Encrypted attributes are decrypted when returned through search requests.

The following figure shows a user entry being added to the database, where attribute encryption has been configured to encrypt the salary attribute.

Figure 7–1 Attribute Encryption Logic

Figure shows attributes encrypted in the database.

Attribute Encryption Implementation

The attribute encryption feature supports a wide range of encryption algorithms. Portability across different platforms is ensured. As an additional security measure, attribute encryption uses the private key of the server’s SSL certificate to generate its own key. This key is then used to perform the encryption and decryption operations. To be able to encrypt attributes, a server must be running over SSL. The SSL certificate and its private key are stored securely in the database and protected by a password. This key database password is required to authenticate to the server. The server assumes that whoever has access to this key database password is authorized to export decrypted data.

Note that attribute encryption only protects stored attributes. If you are replicating these attributes, replication must be configured over SSL to protect the attributes during transport.

If you use attribute encryption, you cannot use the binary copy feature to initialize one server from another server.

Attribute Encryption and Performance

While attribute encryption offers increased data security, this feature does impact performance. Use attribute encryption only to encrypt particularly sensitive attributes.

Sensitive data can be accessed directly through index files. Thus, you must encrypt the index keys corresponding to the encrypted attributes, to ensure that the attributes are fully protected. Indexing already has a performance impact, without the added cost of encrypting index keys. Therefore, configure attribute encryption before data is imported or added to the database for the first time. This procedure ensures that encrypted attributes are indexed as such from the outset.

Designing Access Control With ACIs

Access control 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 to specified entries and their attributes. Permissions include the ability to read, write, search, proxy, add, delete, compare, import and export.

By using an ACL, you can set permissions for the following:

In addition, you can set permissions for a specific user, for all users that belong to a group, or for all users of the directory. You can also define access for a network location, such as an IP address or a DNS name.

This section provides an overview of the Directory Server access control mechanism. For detailed information about configuring access control and ACIs, see Chapter 7, Directory Server Access Control, in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide. For information about the architecture of the access control mechanism, see How Directory Server Provides Access Control in Sun Java System Directory Server Enterprise Edition 6.3 Reference.

Default ACIs

The default behavior of Directory Server is to deny access unless there is a specific ACI that grants access. therefore, if no ACIs are defined, all access to the server is denied.

When you install Directory Server or when you add a new suffix, several default ACIs are defined automatically in the root DSE. These ACIs can be modified to suit your security requirements.

For details on the default ACIs and how to modify them, see How Directory Server Provides Access Control in Sun Java System Directory Server Enterprise Edition 6.3 Reference.

ACI Scope

Directory Server 6.x includes two major changes to ACI scope.

The change in ACI scope has implications for migration. If you are migrating to Directory Server 6.x from a 5.x version of Directory Server, see Changes to ACIs in Sun Java System Directory Server Enterprise Edition 6.3 Migration Guide.

Obtaining Effective Rights Information

The access control model provided by Directory Server can grant access to users through many different mechanisms. However, this flexibility can make your security policy fairly complex. Several parameters can define the security context of a user, including IP address, machine name, time of day, and authentication method.

To simplify the security policy, Directory Server enables you to request and list the effective access rights that a given user has to specified directory entries and attributes. For more information, see Viewing Effective Rights in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

Tips on Using ACIs

The following tips can simplify your directory security model and improve directory performance:

Designing Access Control With Connection Rules

Connection rules enable you to prevent selected clients from establishing connections to Directory Server. The purpose of connection rules is to prevent a denial-of-service attack caused by malicious or poorly designed clients that connect to Directory Server and flood the server with requests.

Connection rules are established at the TCP level by defining TCP wrappers. For more information about TCP wrappers, see Client-Host Access Control Through TCP Wrapping in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

Designing Access Control With Directory Proxy Server

Directory Proxy Server connection handlers provide a method of access control that enables you to classify incoming client connections. In this way, you can restrict the operations that can be performed based on how the connection has been classified.

You can use this functionality, for example, to restrict access to clients that connect from a specified IP address only. The following figure shows how you can use Directory Proxy Server connection handlers to deny write operations from specific IP addresses.

Figure 7–2 Directory Proxy Server Connection Handler Logic

Figure shows connection handlers used to grant write
access to  clients, based on IP address.

How Connection Handlers Work

A connection handler consists of a list of criteria and a list of policies. Directory Proxy Server determines a connection's class membership by matching the origination attributes of the connection with the criteria of the class. When the connection has been matched to a class, Directory Proxy Server applies the policies that are contained in that class to the connection.

Connection handler criteria can include the following:

The following policies can be associated with a connection handler:

For more information about Directory Proxy Server connection handlers and how to set them up, see Chapter 20, Connections Between Clients and Directory Proxy Server, in Sun Java System Directory Server Enterprise Edition 6.3 Reference.

Grouping Entries Securely

Roles and CoS require special consideration with regard to security.

Using Roles Securely

Not every role is suitable for use within a security context. When creating a role, consider how easily it can be assigned to and removed from an entry. Sometimes, users should be able to add themselves to or remove themselves from a role. However, in some security contexts such open roles are inappropriate. For more information, see Directory Server Roles in Sun Java System Directory Server Enterprise Edition 6.3 Reference.

Using CoS Securely

Access control for reading applies to both the real attributes and the virtual attributes of an entry. A virtual attribute generated by the Class of Service (CoS) mechanism is read like a normal attribute. Virtual attributes should therefore be given read protection in the same way. However, to make the CoS value secure, you must protect all of the sources of information the CoS value uses: the definition entries, the template entries, and the target entries. The same is true for update operations. Write access to each source of information must be controlled to protect the value that is generated from these sources. For more information, see Chapter 9, Directory Server Class of Service, in Sun Java System Directory Server Enterprise Edition 6.3 Reference.

Using Firewalls

Firewall technology is typically used to filter or block network traffic to and from an internal network. If LDAP requests are coming from outside a perimeter firewall, you need to specify what ports and protocols are allowed to pass through the firewall.

The ports and protocols that you specify depend on your directory architecture. As a general rule, the firewall must be configured to allow TCP and UDP connections on ports 389 and 636.

Host-based firewalls can be installed on the same server that is running Directory Server. The rules for host-based firewalls are similar to the rules for perimeter defense firewalls.

Running as Non-Root

You can create and run server instances as a non-root user. By running server instances as a non-root user, you limit any potential damage that an exploit could cause. Furthermore, servers running as non-root users are subject to access control mechanisms on the operating system.

Other Security Resources

For more information about designing a secure directory, see the following resources: