Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java(TM) System Directory Server 5.2 2005Q1 Deployment Planning Guide 

Chapter 7
Access Control, Authentication, and Encryption

How you secure data in Directory Server 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 to meet those needs. It includes the following sections:

Security Threats

There are many potential threats to the security of your directory. Understanding the most common threats helps you plan your overall security design. The most typical threats to directory security fall into the following broad categories:

Unauthorized Access

While it may seem simple to protect your directory from unauthorized access, the problem can be more complicated. There are several opportunities along the path of directory information delivery for an unauthorized client to gain access to data. Unauthorized access includes:

For example, an unauthorized client can use another client's credentials to access the data, or an unauthorized client can eavesdrop on the information exchanged between a legitimate client and Directory Server.

Unauthorized access can occur from inside your company, or if your company is connected to an extranet or to the Internet, from outside.

The authentication methods, password policies, and access control mechanisms provided by Directory Server offer efficient ways of preventing unauthorized access. Refer to Selecting Appropriate Authentication Methods, Designing Password Policies, and Designing Access Control for more information.

Unauthorized Tampering

If intruders gain access to your directory or intercept communication between Directory Server and a client application, they have the potential to modify (or tamper with) directory data. These unauthorized modifications may include:

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.

If your directory cannot detect tampering, an attacker could alter a client's request to the server, cancel the request, or change the server's response to the client. The Secure Socket Layer (SSL) protocol and similar technologies can solve this problem by signing information at either end of the connection. For more information about using SSL with Directory Server, refer to Securing Connections With SSL.

Denial of Service

With a denial of service attack, the attacker's goal is to prevent the directory from providing service to its clients. For example, an attacker might simply use the system's resources to prevent them from being used by someone else.

Directory Server offers a way of preventing denial of service attacks by setting limits on the resources allocated to a particular bind DN. For more information, refer to "Setting Individual Resource Limits" in the Administration Server Administration Guide.

Overview of Security Methods

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.

Directory Server provides the following security methods:

These tools for maintaining security 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.

Analyzing Your Security Needs

When you performed your site survey in Chapter 2, "Planning and Accessing Directory Data," you made certain decisions about who can read and write the individual pieces of data in your directory. This information now forms the basis of your security design.

How you implement security is also dependent on how you use the directory to support your business. A directory that serves an intranet does not require the same security measures as a directory that supports an extranet, or e-commerce applications that are open to the Internet.

If your directory serves an intranet only, your concerns are primarily:

If your directory serves an extranet, or supports e-commerce applications over the Internet, you also need to offer your customers and business partners a guarantee of privacy.

This section contains the following information about analyzing your security needs:

Determining Access Rights

When you perform a data analysis, you decide what information your users, groups, partners, customers, and applications need to access.

You can grant access rights in two ways:

Regardless of how you decide to grant access rights, you should create a simple table that lists the categories of users in your organization and the access rights you grant to each. You may also want to create a table that lists the sensitive data held in the directory, and for each piece of data, the steps taken to protect it.

For information about checking the identity of users, refer to Selecting Appropriate Authentication Methods. For information about restricting access to directory information, refer to Designing Access Control.

Ensuring Data Privacy and Integrity

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.

You can do this in several ways, by:

For information about encryption methods provided in Directory Server, refer to Password Storage Scheme and Encrypting Attributes. For information about signing data, refer to Securing Connections With SSL.

Conducting Security Audits

Security audits ensure that the implementation of a security policy is working. There are several aspects to a security audit. 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. For more information about monitoring your directory, refer to Chapter 8, "Directory Server Monitoring."

Selecting Appropriate Authentication Methods

A basic decision you must make regarding your security policy is how users access Directory Server. Will you allow anonymous access, or will you require every person who uses Directory Server to bind to the directory?

Directory Server supports the following authentication mechanisms:

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

For information about preventing authentication by a client or group of clients, see Preventing Authentication by Account Inactivation.

Anonymous Access

Anonymous access provides the easiest form of access to your directory. It makes data available to any user of your directory, regardless of whether they have authenticated.

However, anonymous access does not allow you to track who is performing what kinds of searches; only that someone is performing searches. When you allow anonymous access, anyone who connects to your directory can access the data.

Therefore, if you attempt to block a specific user or group of users from seeing some kinds of directory data, but you have allowed anonymous access to that data, then those users can still access the data simply 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. Often, administrators limit access to a subset of attributes that contain general information such as names, telephone numbers, and email addresses. Anonymous access should never be allowed for sensitive data such as government identification numbers (social security numbers in the US), home telephone numbers and addresses, and salary information.

If a user attempts to bind with an entry that does not contain a user password attribute, Directory Server either:

For example, consider the following ldapsearch command:

% ldapsearch -h ds.example.com -D "cn=joe,dc=Example,dc=com"
  -w secretpwd -b "cn=joe,dc=Example,dc=com" "objectclass=*"

ldap_simple_bind_s: Invalid credentials

Although Directory Server allows anonymous access for read, Joe cannot access his own entry because it does not contain a password that matches the one he provided in the ldapsearch command.

Simple Password

If you have not set up anonymous access, clients must authenticate to Directory Server before they can access the directory contents. With simple password authentication, a client authenticates to the server by sending a simple, reusable password.

For example, a client authenticates to Directory Server via a bind operation in which it provides a distinguished name and its credentials. The server locates the entry in the directory that corresponds to the client DN and checks whether the password given by the client matches the value stored with the entry. If it does, the server authenticates the client. If it does not, the authentication operation fails and the client receives an error message.

The bind DN often corresponds to the entry of a person. However, some directory administrators find it useful to bind as an administrative entry rather than as a person. Directory Server requires the entry used to bind to be of an object class that allows the userPassword attribute. This ensures that the directory recognizes the bind DN and password.

Most LDAP clients hide the bind DN from the user because users may find the long strings of DN characters hard to remember. When a client attempts to hide the bind DN from the user, it uses a bind algorithm such as the following:

  1. The user enters a unique identifier such as a user ID (for example, bjensen).
  2. The LDAP client application searches the directory for that identifier and returns the associated distinguished name (such as uid=bjensen,ou=people,dc=Example,dc=com).
  3. The LDAP client application binds to the directory using the retrieved distinguished name and the password supplied by the user.

    Note

    The drawback of simple password authentication is that the password is sent in clear text. If a rogue user is listening, this can compromise the security of your Directory Server because that person can impersonate an authorized user.

Simple password authentication offers an easy way of authenticating users, but it is best to restrict its use to your organization's intranet. It does not offer the level of security required for transmissions between business partners over an extranet, or for transmissions with customers out on the Internet.

Proxy Authorization

Proxy authorization is a special form of access control: a user that binds to Directory Server using his own identity is granted the rights of another user, through proxy authorization.

Using proxy authorization, directory administrators can request access to Directory Server by assuming the identity of a regular user. They bind to the directory using their own credentials, but for purposes of access control evaluation, are granted the rights of the regular user. This assumed identity is called the proxy user, and the DN of that user, the proxy DN.

To configure Directory Server to allow proxy requests:

One of the main advantages of the proxy mechanism is that you can enable an LDAP application to use a single thread with a single bind to service multiple users making requests against Directory Server. Instead of having to bind and authenticate for each user, the client application binds to Directory Server and uses proxy rights.

For more information on proxy authorization, refer to "Managing Access Control" in the Directory Server Administration Guide.

Simple Password Over a Secure Connection

A secure connection uses encryption to make data unreadable to third parties while it is sent over the network between Directory Server and its clients. Clients may 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. As a result, the client knows that it is connected to the intended server and that the server is not being tampered with.

The client and server then begin to encrypt all data transmitted through the connection for privacy. 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 or 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 they are returned to the client.

For more information about SSL, refer to Securing Connections With SSL. For information about configuring certificates and activating SSL, see "Managing Authentication and Encryption" in the Directory Server Administration Guide.

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 credentials, and not the DN, are used to determine the bind DN. Client authentication protects against user impersonation and is the most secure type of connection.

One form of credentials that a client may send is the user's certificate. To perform certificate-based authentication, the directory must be configured to perform certificate mapping, and all users must store a copy of their certificate in their entry. After receiving a user certificate from a client, the server performs a mapping based on the certificate contents to find a user entry in the directory. This entry must contain an exact copy of the certificate for the user to be positively identified. All operations proceed using this entry's DN as the bind DN, and all results are encrypted over the SSL or TLS connection.

For more information about certificate mapping, see "Using Client Authentication" in the Administration Server Administration Guide and "Configuring Certificate-Based Authentication in Clients" in the Directory Server Administration Guide.

Directory Server now supports a version of the Network Security Services (NSS) component with a certificate base that allows for larger certificates than were previously possible. In addition, a directory is automatically created next to the certificate database when an object larger than 14 KB is imported.

SASL-Based Client Authentication

Another type of client authentication during an SSL or TLS connection uses the Simple Authentication and Security Layer (SASL) to establish the identity of the client. Directory Server supports the following mechanisms through the generic security interface of SASL:

When using either SASL mechanism, the server must also be configured to perform identity mapping. The SASL credentials are called the Principal, and each mechanism must have specific mappings to determine the bind DN from the contents of the Principal. When the Principal is mapped to a single user entry and the SASL mechanism validates that user's identity, the user's DN is the bind DN for the connection.

For more information, see "Using SASL DIGEST-MD5 in Clients"and "Using Kerberos SASL GSSAPI in Clients"in the Directory Server Administration Guide.

Preventing Authentication by Account Inactivation

You can temporarily inactivate a user account or a set of accounts. Once inactivated, a user cannot bind to Directory Server, and the authentication operation fails.

Account inactivation is implemented through the operational attribute, nsAccountLock. When an entry contains the nsAccountLock attribute with a value of true, the server rejects the bind. (The nsAccountLock attribute should never be modified manually, but using the command-line utilities.)

You use the same procedures for inactivating users and roles. However, inactivating a role means that you inactivate all of the members of that role and not the role entry itself. For more information about roles, refer to Managed, Filtered, and Nested Roles.

Designing Password Policies

A password policy is a set of rules that govern how passwords are administered in a given system.

The password policy can be used to configure multiple password policies, as opposed to one global policy for your entire directory. You can assign password policies either to particular users or to sets of users by using the 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 policies cannot be applied to static groups.

For detailed information about the attributes available to build password policies, see "Password Policy Attributes" and "Account Lockout Attributes" in the Directory Server Administration Reference. For information about configuring and managing password policies, refer to "Managing User Accounts and Passwords" in the Directory Server Administration Guide. This section is divided into the following topics:

Password Policy Features

This section describes the main password policy features, and is divided into the following sub-sections:

User-Defined Passwords

You can set up your password policy to either allow or not allow users to change their own passwords. A good password is the key to a strong password policy. Good passwords do not use trivial words—that is, any word that can be found in a dictionary, names of pets or children, birthdays, user IDs, or any other information about the user that can be easily discovered (or stored in the directory itself).

Also, a good password should contain a combination of letters, numbers, and special characters. Often, however, users simply use passwords that are easy to remember. This is why some enterprises choose to set passwords for users that meet the criteria of a "good" password, and do not allow the users to change passwords.

However, assigning passwords to users takes a substantial amount of an administrator's time. In addition, by providing passwords for users rather than letting them come up with passwords that are meaningful to them and therefore more easily remembered, you run the risk that the users will write their passwords down somewhere where they can be discovered. By default, user-defined passwords are allowed.

Password Change at First Login or Reset

The Directory Server password policy lets you decide whether users must change their passwords at the first login or after the password is reset by an administrator.

Often the initial passwords set by the administrator follow some sort of convention, such as the user's initials, user ID, or the company name. Once the convention is discovered, it is usually the first value tried by a hacker trying to break in. In this case, it is a good idea to require users to change their passwords after such a change. If you configure this option for your password policy, users are required to change their password even if user-defined passwords are disabled. (see the previous section on User-Defined Passwords.)

By default, users do not need to change their passwords at first login or after a reset.

Password Expiration

You can configure your password policy so that users can use the same passwords indefinitely, or so that passwords expire after a given time. In general, the longer a password is in use, the more likely it is to be discovered. However, if passwords expire too often, users may have trouble remembering them and resort to writing their passwords down. A common policy is to have passwords expire every 30 to 90 days.

Directory Server remembers the password expiration configuration even if you disable password expiration. This means that if you re-enable password expiration, passwords are valid only for the duration you set before you last disabled the feature. For example, suppose you set up passwords to expire every 90 days and then decided to disable password expiration. When you re-enable password expiration, the default password expiration duration is 90 days because that is what you had it set to before you disabled the feature.

By default, user passwords never expire.

The new global configuration attribute, usePwdChangedTime, enables you to limit the duration during which a user can log in after a password is changed, for example, after a password is reset by an administrator.

Expiration Warning

If you choose to set your password policy so that user passwords expire after a given number of days, it is a good idea to send users a warning before their passwords expire. You can set your policy so that users are sent a warning 1 to 24,855 days before their passwords expire. Directory Server displays the warning when the user binds to the server. By default, if password expiration is turned on, a warning is sent (via an LDAP message) to the user one day before the user's password expires, provided the user's client application supports this feature.

Password Syntax Checking

The password policy establishes syntax guidelines for password strings. The password syntax-checking mechanism ensures that password strings conform to these guidelines. By default, password syntax checking is turned off. Password length is checked, only if password syntax checking is enabled.

Password Length

Directory Server enables you to specify a minimum length for user passwords. In general, shorter passwords are easier to crack. You can require passwords that are from 2 to 512 characters. A good length for passwords is 8 characters. This is long enough to be difficult to crack, but short enough so that users can remember the password without writing it down.

By default the minimum password length is 6 characters. The minimum length of a password is checked only if password syntax checking is turned on.

Password Minimum Age

You can configure your password policy to prevent users from changing their passwords with a specified period. You can use this feature in conjunction with the password history feature to discourage users from reusing old passwords.

Setting the password minimum age to 2 days, for example, prevents users from repeatedly changing their password during a single session to cycle through the password history and reuse an old password once it is removed from the history list. You can specify any number from 0 to 24,855 days. A value of zero (0) indicates that the user can change the password immediately.

Password History

You can configure Directory Server to store a maximum of 24 used passwords in history.

With password history enabled, if a user attempts to reuse one of the passwords Directory Server has stored, the password is rejected. This feature prevents users from reusing one or two passwords that are easy to remember.

If you disable the password history feature, no previously used passwords are stored and users are able to reuse passwords. By default, Directory Server does maintain a password history.

Password Storage Scheme

The password storage scheme specifies the type of encryption used to store passwords within the directory. You can specify:

Although passwords stored in the directory can be protected through the use of access control information (ACI) instructions, it is still not a good idea to store clear text passwords in the directory. The CRYPT algorithm provides compatibility with UNIX passwords. SSHA is the most secure, and is the default hash algorithm for Directory Server.

Configuring Password Policies

The following password policy options are provided:

Note: password policies cannot be applied to static groups.

This section describes these options in more detail, and explains the order of precedence that governs the application of password policies when multiple password policies exist for a given user entry. This section is divided into the following topics:

Global Password Policy

The global password policy is stored under cn=Password Policy,cn=config, and is applied by default. You can modify this policy to suit your security needs. The default global policy enforces the following:

The default policy (where passwords never expire, no syntax checks are performed, and the account lockout mechanism is not enabled) has low management overheads but is not the most secure. You should balance your security requirements against the management overheads generated by a demanding password policy.

Note

In previous versions of Directory Server, global password policy attributes were stored directly under cn=config. They are now stored under cn=Password Policy,cn=config. If this entry does not exist, the hard-coded password policy provided with Directory Server is applied.

Defining Password Policies for Users or Sets of Users

You define a password policy for a specific user entry or for a set of users, with the passwordPolicySubentry attribute. The value of this attribute is the DN of an LDAPsubentry that contains the password policy attributes you wish to apply directly to the user's entry. This attribute can either be a real attribute or a virtual attribute generated by a CoS definition.

You can define password policies for a set of users by configuring the CoS definition to provide values for the passwordPolicySubentry attribute in user entries as a function of the Roles that those user entries have. While this is not the only way to define password policies for sets of users, it is the method used by Directory Server Console. Password policies cannot be applied to static groups.

To make managing your password policy easier, you should co-locate the user or set of users to which the password policy applies, and the password policy itself. This will ensure that the password policy LDAP subentry is replicated along with the password policy.

You can apply password policies to dynamic groups, but not static groups.

For procedural information on defining individual password policies, see "Managing Individual Password Policies"in the Directory Server Administration Guide.

Multiple Password Policies and Their Order of Precedence

There are three main rules of precedence that govern the application of password policies when a user entry has more than one password policy assigned to it. The rules are as follows:

  1. A password policy generated by a CoS definition will take precedence over a password policy assigned directly to the user entry. This is because the cosAttribute value defined in the CoS definition entry is obliged to contain an operational qualifier, which causes the CoS generated password policy to override any real attributes that may have been assigned directly to the user. For more information about the Roles and CoS mechanism, see Chapter 4, "The Directory Information Tree."
  2. A password policy assigned directly to a user entry will take precedence over the global password policy.
  3. 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.

    4. Caution

    When you are configuring password policies using CoS, it is important to establish an order of precedence in case a user entry is affected by more than one CoS generated password policy. You specify order of precedence by entering the appropriate value in the cosPriority attribute when you create your CoS template entry. You assign the highest priority with a value of 0. CoS templates that contain no cosPriority attribute are considered lowest priority, and when templates have the same (or no) cosPriority attribute value, a priority is chosen arbitrarily. For more information on Roles and CoS, see Chapter 4, "The Directory Information Tree."

Preventing Dictionary-Style Attacks

In a dictionary-style attack, an intruder attempts to crack a password by repeatedly guessing from a list of common words and variations, until gaining authorization. The server provides three tools to counter such attacks:

Password Policies in a Replicated Environment

Configuration information for the global password policy is not replicated, because it is an entry under cn=config. If you modify the global password policy, you must therefore make the same modifications on each of the servers in your topology manually. If you require a global password policy that is replicated, you must define such a policy under a part of the directory tree that is replicated.

All password information that is stored in the user entry (current password, password history, password expiration dates, and so forth) is replicated. Account lockout counters are stored at the local server level and are not replicated.

You should consider the following impact of password policies in a replicated environment:

Designing Access Control

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 (such as read, write, search, proxy, add, delete, and compare) to specified entries and their attributes.

Using an ACL, you can set permissions for the following:

In addition, you can set permissions for a specific user, for all users belonging 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 describes the Directory Server access control mechanism, and is divided into the following topics:

ACI Format

ACIs are stored in the directory, as attributes of entries. The aci attribute is an operational attribute; it is available for use on every entry in the directory, regardless of whether it is defined for the object class of the entry. It 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 is returned in an ldapsearch operation if specifically requested. For more information on the format of ACIs see "ACI Syntax,"in the Directory Server Administration Guide.

Default ACIs

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. For details on the default ACIs and how to modify them, refer to "Default ACIs"in the Directory Server Administration Guide.

Setting Permissions

If no ACIs are present in the directory, the default policy is not to grant users access rights (with the exception of the Directory Manager.) Therefore, you must set some ACIs to enable your users to access the directory. The following sections describe the access control mechanism provided by Directory Server. For information on setting ACIs, see "Creating ACIs From the Command Line"and "Creating ACIs Using the Console" in the Directory Server Administration Guide.

The Precedence Rule

When a user attempts any kind of access to a directory entry, Directory Server examines the access control set in the directory. To determine access, Directory Server applies the precedence rule. This rule states that when two conflicting permissions exist, the permission that denies access always takes precedence over the permission that grants access.

For example, if you deny write permission at the directory's root level, and you make that permission applicable to everyone accessing Directory Server, then no user can write to the directory regardless of any other permissions that you may allow. To allow a specific user write permissions to Directory Server, you have to restrict the scope of the original deny-for-write so that it does not include that user. Then you have to create an additional allow-for-write permission for the user.

Allowing or Denying Access

You can explicitly allow or deny access to your directory tree. Be careful of explicitly denying access to Directory Server. Because of the precedence rule, if the directory finds rules explicitly forbidding access, it will forbid access regardless of any conflicting permissions that may grant access.

Limit the scope of your allow access rules to include only the smallest possible subset of users or client applications. For example, you can set permissions that allow users to write to any attribute on their directory entry, but then deny all users except members of the Directory Administrators group the privilege of writing to the uid attribute. Alternatively, you can write two access rules that allow write access in the following ways:

By providing only allow access, you avoid the need to set explicit deny access.

When to Deny Access

You rarely need to set an explicit deny. However, you may find an explicit deny useful in the following circumstances:

Where to Place Access Control Rules

Access control rules can be placed on any entry in the directory. Often administrators place access control rules on entries of type country, organization, organizationalUnit, inetOrgPerson, or group.

To simplify your ACL administration, group your rules as much as possible. Since a rule generally applies to its target entry and to all that entry's children, it is best to place access control rules on root points in the directory or on directory branch points, rather than to scatter them across individual leaf (such as person) entries.

Using Filtered Access Control Rules

One of the more powerful features of the Directory Server ACI 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 example, you could allow read access for any entry that contains an organizationalUnit attribute with a value of Marketing.

Filtered access control rules let you use predefined levels of access. For example, suppose your directory contains home address and telephone number information. Some people want to publish this information, while others want to be "unlisted." You can handle this situation by doing the following:

For more information about using LDAP search filters with ACIs, see "Targeting Entries or Attributes Using LDAP Filters" in the Directory Server Administration Guide.

Using Macro ACIs

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.

When the server starts, all ACIs are brought into memory, although cache limits do not apply to them. This can have a considerable impact on memory consumption. If you use repeating directory tree structures, you should therefore optimize the number of ACIs used in Directory Server by using macro ACIs where possible.

For more information on macro ACIs see "Advanced Access Control: Using Macro ACIs" in the Directory Server Administration Guide.

Requesting Effective Rights Information

The access control model provided by Directory Server is powerful in that access can be granted to users via many different mechanisms. However, this flexibility can make determining what your security policy comprises fairly complex. Because there are several parameters that can define the security context of a user (IP address and machine name, time of day, and authentication method, for example,) it is useful to be able to list the rights of a given user to directory entries and attributes.

Directory Server enables you to request the effective access rights that a user has to specified directory entries and attributes. The effective rights information obtained corresponds to:

When establishing why a user does or does not have access to certain data, you must reflect all of the user's parameters when initiating your effective rights search operation.

This section examines the effective rights feature in more detail and is divided into the following topics:

About the Effective Rights Feature

The effective rights feature uses the ldapsearch utility supplied with the Directory Server Resource Kit (DSRK). The rights information you require is specified using a particular option and the information relative to these rights is returned with your ldapsearch results. For information on how to use the effective rights feature, see "Viewing Effective Rights"in the Directory Server Administration Guide.

Access Control on the Effective Rights Feature

To obtain effective rights information, users must have the access control rights to use the Effective Rights control and read access to the aclRights attribute. This double layer of access control for the effective rights feature provides basic security which can be more finely tuned if necessary. By analogy with proxy, if you have read access to the aclRights attribute in an entry, you can request information about anyone's rights to that entry and its attributes. This implies that the user who manages the resource can determine who has rights to that resource, even if that user does not actually manage those with the rights.

If a user requesting rights information does not have the rights to use the Effective Rights control, the operation will fail and an error message will be returned. However, if the user requesting rights information does have the rights to use the control but lacks the rights to read the aclRights attribute, the aclRights attribute will simply be absent from the returned entry. This behavior reflects Directory Server's general search operation behavior.

If a proxy control is attached to an Effective Rights control-based search operation, the effective rights operation will be authorized as the proxy user. This means that the proxy user will require the rights to use the Effective Rights control, and the entries returned will be those entries that the proxy user has the right to search and view.

Results of an Effective Rights Request

The information returned as a result of an effective rights request includes :

For detailed information on each of these aspects, refer to "Understanding Effective Rights Results," in the Directory Server Administration Guide.

Tips on Using ACIs

The following tips can help to lower the administrative burden of managing your directory security model and improve directory performance. Some of the following hints have already been described earlier in this chapter, but are included here to provide a complete list.

ACI Limitations

When creating an access control policy, be aware of the following restrictions:

Securing Connections With SSL

In addition to designing an authentication scheme for identifying users and an access control scheme for protecting information, you must protect the integrity of the information in transit over the network between servers and client applications.

To provide secure communications over the network you can use both the LDAP and DSML-over-HTTP protocols over the Secure Sockets Layer (SSL). When you have configured and activated SSL, clients connect to a dedicated secure port where all communications are encrypted once the SSL connection is established. Directory Server also supports the Start Transport Layer Security (Start TLS) control, which allows the client to initiate an encrypted connection over the standard LDAP port. For a comprehensive overview of SSL and TLS, refer to "Using SSL and TLS with Sun Java System Servers" in the Administration Server Administration Guide.

Directory Server supports SSL-secured connections and non-SSL connections simultaneously.

SSL uses encryption for privacy and hashing of checksums for data integrity. When establishing an SSL connection, the client application and Directory Server select the strongest encryption algorithm (cipher) common to their configurations. Directory Server may use any of the following ciphers:

Ciphers are combined with one of the following hashing algorithms:

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.

You can also configure the server to request authentication from the client. Directory Server supports certificate-based and SASL-based client authentication. These mechanisms are described in Selecting Appropriate Authentication Methods. 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 5.2 supports the Sun Crypto Accelerator Board . This feature enhances the performance for connections using the SSL protocol with certificate-based authentication. This board accelerates SSL key-related calculations, and may be useful in deployments where client applications repeatedly bind over SSL, search, and then unbind. SSL accelerator boards may not improve Directory Server performance when key-related calculations are not the performance bottleneck. In addition, SSL accelerator boards are most effective if the clients that are establishing connections are doing so from different machines. If a system establishes multiple SSL-based connections, it is likely that the SSL caching session will limit the number of RSA operations, which will in turn limit the benefit that the accelerator board may provide. For information on how to install and configure the Sun Crypto Accelerator Board see "Using the Sun Crypto Accelerator Board" in the Directory Server Administration Guide.

For information about configuring and enabling SSL in Directory Server and its clients, refer to "Managing Authentication and Encryption" in the Directory Server Administration Guide.

Encrypting Attributes

This section presents the attribute encryption functionality, and is divided into the following topics:

What is Attribute Encryption?

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 for the data stored in database files, backup files, and LDIF files to be protected. 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 attribute encryption feature prevents users from accessing sensitive data while it is in storage.

Attribute encryption enables you to specify that certain attributes be stored in an encrypted form. It is configured at the database level, which means that once you decide to encrypt an attribute, that attribute will be encrypted for every entry in the database. Because attribute encryption occurs at an attribute level rather than an entry level, the only way to encrypt an entire entry is to encrypt all of its attributes.

In addition to protecting data while in storage, attribute encryption enables you to export data to another database in encrypted format. However, because the purpose of attribute encryption is to protect sensitive data only when it is in storage or being exported, the encryption is always reversible. Encrypted attributes are therefore decrypted when returned via search requests.

Figure 7-1 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

Attribute encryption showing attributes encrypted in the database but decrypted in the ldapsearch and ldapmodify queries

Attribute Encryption Implementation

The attribute encryption feature supports a wide range of encryption algorithms, and ensures portability across different platforms. As an additional security measure, attribute encryption uses the private key of the server's SSL certificate to generate its own key, which is used to perform the encryption and decryption operations. This implies that, in order to be able to encrypt attributes, your server must be running over SSL. The SSL certificate and its private key are stored securely in the database in that they are protected by a password, and it is this key database password that is required to authenticate to the server. It is assumed that whoever has access to this key database password will be authorized to export decrypted data.

When importing data online with a view to encrypting it, you will already have provided the key database password to authenticate to the server, and will not be prompted a second time. If you are importing data offline, Directory Server will prompt you for the password before it allows you to encrypt the data you are importing. When decrypting data (a more security sensitive operation), Directory Server automatically prompts you for the key database password, regardless of whether the export operation is online or offline. This provides an additional security layer.

Note

As long as the certificate or private key does not change, the server will continue to generate the same key, which will make it possible to transport (export then import) data from one server instance to another (provided both server instances have used the same certificate.)

Attribute Encryption and Performance

While attribute encryption offers increased data security, it does incur certain performance costs. Bearing this in mind, you should think carefully about which attributes require encryption and encrypt only those attributes you consider to be particularly sensitive.

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), it is advisable to configure attribute encryption before data is imported or added to the database for the first time. This procedure will ensure that encrypted attributes are indexed as such from the outset.

Attribute Encryption Usage Considerations

Consider the following when implementing the attribute encryption feature:

For procedural information on the attribute encryption feature, see "Encrypting Attribute Values" in the Directory Server Administration Guide.

Grouping Entries Securely

This section deals with the security issues related to grouping entries and contains the following topics:

Using Roles Securely

Not every role is suitable for use within a security context. When creating a new role, consider how easily the role can be assigned to and removed from an entry. Sometimes it is appropriate for users to be able to add themselves to or remove themselves from a role. For example, if you had an interest group role called Mountain Biking, you would want interested users to add themselves or remove themselves easily.

However, in some security contexts it is inappropriate to have such open roles. For example, consider account inactivation roles. By default, account inactivation roles contain ACIs defined for their suffix (for more information about account inactivation, see "Inactivating Users and Roles" in the Directory Server Administration Guide. When creating a role, the server administrator decides whether or not a user can assign themselves to or remove themselves from the role.

For example, user A possesses the managed role, MR. The MR role has been locked using account inactivation through the command line. This means that user A cannot bind to the server because the nsAccountLock attribute is computed as "true" for that user. However, suppose the user was already bound and noticed that he is now locked through the MR role. If there are no ACIs preventing him, the user can remove the nsRoleDN attribute from his entry and unlock himself.

To prevent users from removing the nsRoleDN attribute, you would need to apply ACIs. With filtered roles you would have to protect the part of the filter that would prevent the user from being able to relinquish the filtered role by modifying an attribute. Users should not be allowed to add, delete, or modify the attribute used by the filtered role, and in the same way if the value of the filter attribute is computed then all the attributes that can modify the value of the filter attribute should be protected too. As nested roles can be comprised of filtered and managed roles, the above points should be considered for each of the roles that comprise the nested role.

Using CoS Securely

Access control for reading applies to both the real and virtual attributes of an entry. A virtual attribute generated by the Class of Service mechanism is read just as a normal attribute and should be given read protection in the same way.

However, in order to make the CoS value secure, you must protect all of the sources of information it 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 should be controlled to protect the value that is generated from them.

The following sections describe the general principals for read and write protection of data in each of the CoS entries. The detailed procedure for defining individual access control instructions (ACIs) is described in "Managing Access Control" in the Directory Server Administration Guide.

Protecting the CoS Definition Entry

Although the CoS definition entry does not contain the value of the generated attribute, it provides the information to find that value. Reading the CoS definition entry would reveal how to find the template entry containing the value, and writing to this entry would modify how the virtual attribute is generated.

You should therefore define both read and write access control on the CoS definition entries.

Protecting the CoS Template Entries

The CoS template entry contains the value of the generated CoS attribute. Therefore, as a minimum, the CoS attribute in the template should be protected for both reading and updating.

In the case of pointer CoS, there is a single template entry that should not be allowed to be renamed. In most cases, it is simplest to protect the entire template entry.

With classic CoS, all template entries have a common parent given in the definition entry. If only templates are stored in this parent entry, access control to the parent entry will protect the templates. However, if other entries beneath the parent require access, the template entries must be protected individually.

In the case of indirect CoS, the template may be any entry in the directory, including user entries that might still need to be accessed. Depending on your needs, you can either control access to the CoS attribute throughout the directory, or choose to ensure that the CoS attribute is secure in each entry used as a template.

Protecting the Target Entries of a CoS

All entries in the scope of a CoS definition, for which the virtual CoS attribute will be generated, also contribute to computing its value.

When the CoS attribute already exists in a target entry, by default, the CoS mechanism will not override this value. If you do not want this behavior, you should either define your CoS to override the target entry or protect the CoS attribute in all potential target entries. For information on these procedures see "Managing Identity and Roles"in the Directory Server Administration Guide.

Both indirect and classic CoS also rely on a specifier attribute in the target entry. This attribute gives the DN or RDN of the template entry to use. You should protect this attribute either globally throughout the scope of the CoS or individually on each target entry where needed.

Protecting Other Dependencies

It is possible to define virtual CoS attributes in terms of other generated CoS attributes and roles. You will need to understand and protect these dependencies in order to guarantee the protection of your virtual CoS attribute.

For example, the CoS specifier attribute in a target entry could be nsRole, and therefore the role definition would also need to be protected. For more information, see Grouping Entries Securely.

In general, any attribute or entry that is involved in the computation of the virtual attribute value should have both read and write access control. For this reason, complex dependencies should be well planned or simplified to reduce subsequent complexity of access control implementation. Keeping dependencies on other virtual attributes to a minimum also improves directory performance and reduces maintenance.

Securing Configuration Information

For the majority of deployments no additional access controls are required either for the root DSE entry (the entry returned for a base object search with a zero-length DN) or for the subtrees below cn=config, cn=monitor or cn=schema. The root DSE entry and these subtrees contain attributes that are automatically generated by Directory Server and used by LDAP clients to determine the capabilities and configuration of the directory server.

However, one of the root DSE entry attributes called namingContexts contains a list of the base DNs for each of the Directory Server databases. In addition to this list, these DNs are also stored in the mapping tree entries below cn=config and cn=monitor. Should you wish to hide the existence of one or more subtrees and protect your configuration information for security reasons, it will be necessary to place:

Other Security Resources

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



Previous      Contents      Index      Next     

Copyright 2005 Sun Microsystems, Inc. All rights reserved.