Deployment Guide
Red Hat Directory Server                                                            
Previous
 Contents
 Index
 Next

Chapter 7

Designing a Secure Directory

How you secure the data in Red Hat Directory Server (Directory Server) affects all of the previous design areas. Your security design needs to protect the data contained by your directory and meet the security and privacy needs of your users and applications.

This chapter describes how to analyze your security needs and explains how to design your directory to meet these needs. It includes the following sections:

About 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 three categories:

The remainder of this section provides a brief overview of the most common security threats to assist you with designing your directory's security policies.

Unauthorized Access

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

For example, an unauthorized client can use another client's credentials to access the data. This is particularly likely when your directory uses unprotected passwords. 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 scenarios described here are just a few examples of how an unauthorized client might access your directory data.

The authentication methods, password policies, and access control mechanisms provided by the Directory Server offer efficient ways of preventing unauthorized access. Refer to "Selecting Appropriate Authentication Methods," on page 143, "Designing a Password Policy," on page 147, and "Designing Access Control," on page 158, for more information about these topics.

Unauthorized Tampering

If intruders gain access to your directory or intercept communications between Directory Server and a client application, they have the potential to modify (or tamper with) your directory 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.

For example, if your directory cannot detect tampering, an attacker could change a client's request to the server (or not forward it) and change the server's response to the client. SSL 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 and Start TLS," on page 169.

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 about setting resource limits based on the user's bind DN, refer to chapter 7, "User Account Management," in the Red Hat Directory Server Administrator's Guide.

Analyzing Your Security Needs

You need to analyze your environment and users to determine your specific security needs. When you performed your site survey in chapter 3, "How to Design the Schema, you made some basic 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.

The way 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:

If your directory serves an extranet or supports e-commerce applications over the Internet, in addition to the previous points, your concerns are:

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

Determining Access Rights

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

You can grant access rights in two ways:

If you choose this open method, you must concentrate on determining what data is sensitive or critical to your business.
If you choose this restrictive method, you must spend some time understanding the information needs of each category of user inside, and possibly outside, of your organization.

No matter how you determine 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," on page 143. For information about restricting access to directory information, refer to "Designing Access Control," on page 158.

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:

For information about encryption methods provided in the Directory Server, refer to "Password Storage Scheme," on page 157. For information about signing data, refer to "Securing Connections with SSL and Start TLS," on page 169, and "Securing Connections with SASL," on page 169. For encrypting sensitive information as it is stored within the database, see "Database Encryption," on page 168.

Conducting Regular Audits

As an extra security measure, you should conduct regular audits to verify the efficiency of your overall security policy. You can do this by examining the log files and the information recorded by the SNMP agents.

For more information about SNMP, refer to Red Hat Directory Server Administrator's Guide.

Example Security Needs Analysis

The examples provided in this section illustrate how the imaginary ISP company example.com analyzes its security needs.

example.com's business is to offer web hosting and Internet access. Part of example.com's activity is to host the directories of client companies. It also provides Internet access to a number of individual subscribers.

Therefore, example.com has three main categories of information in its directory:

example.com needs the following access controls:

Overview of Security Methods

Directory Server offers a number of methods that you can use to design an overall security policy that is adapted to your needs. Your security policy should be strong enough to prevent sensitive information from being modified or retrieved by unauthorized users while simple enough to administer easily. A complex security policy can lead to mistakes that either prevent people from accessing 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.

Selecting Appropriate Authentication Methods

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

Directory Server provides the following methods for authentication:

The directory uses the same authentication mechanism for 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," on page 147.

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 only allow anonymous access for read, search, and compare privileges (not for write, add, delete, or selfwrite). 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 more 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 can either grant anonymous access if the user does not attempt to provide a password or deny access if the user provides any non-null string for the password.

For example, consider the following ldapsearch command: 

% ldapsearch -D "cn=joe" -w secretpwd -b "example.com" cn=joe

Although the directory 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, you must authenticate to the directory before you 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 the directory via a bind operation in which it provides a distinguished name and a set of 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 organizational entry rather than as a person. The directory 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, fchen).
  2. The LDAP client application searches the directory for that identifier and returns the associated distinguished name (such as uid=fchen,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 cleartext over the wire. If a rogue user is listening, this can compromise the security of your directory 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 on the Internet.

Certificate-Based Authentication

An alternate form of directory authentication involves using digital certificates to bind to the directory. The directory prompts your users for a password when they first access it. However, rather than matching a password stored in the directory, the password opens the user's certificate database.

If the user supplies the correct password, the directory client application obtains authentication information from the certificate database. The client application and the directory then use this information to identify the user by mapping the user's certificate to a directory DN. The directory allows or denies access based on the directory DN identified during this authentication process.

For more information about certificates and SSL, see Managing Servers with Red Hat Console.

Simple Password over TLS

When a secure connection is established between Directory Server and a client application using SSL or the Start TLS operation, the server can demand an extra level of authentication by requesting a password. In such cases, the password is not passed in clear over the wire.

For more information about SSL, refer to "Securing Connections with SSL and Start TLS," on page 169. For information about the StartTLS operation, refer to the Red Hat Directory Server Administrator's Guide.

Proxy Authentication

Proxy authentication is a special form of authentication because the user requesting access to the directory does not bind with its own DN but with a proxy DN.

The proxy DN is an entity that has appropriate rights to perform the operation requested by the user. When you grant proxy rights to a person or an application, you grant the right to specify any DN as a proxy DN with the exception of the Directory Manager DN.

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

The proxy DN is specified in the LDAP operation submitted by the client application. For example: 

% ldapmodify -D "cn=manager" -w secretpwd -y 
"cn=joe,dc=example,dc=com" -b "example.com" -f mods.ldif

This ldapmodify command gives the manager entry (cn=manager) the permissions of a user named Joe (cn=joe) to apply the modifications in the mods.ldif file. The manager does not need to provide Joe's password for making this change.

Note

The proxy mechanism is very powerful and must be used sparingly. Proxy rights are granted within the scope of the ACL, and there is no way to restrict who can be impersonated by an entry that has the proxy right-that is, when you grant a user proxy rights, that user has the ability to proxy for any user under the target; there is no way to restrict the proxy rights to only certain users. For example, if an entity has proxy rights to the dc=example,dc=com tree, that entity can do anything. So make sure you set the proxy ACI at the lowest possible level of the DIT. For more information on this, see "Proxied Authorization ACI Example" in chapter 6, "Managing Access Control," in the Red Hat Directory Server Administrator's 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 the directory, 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.

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 "About Roles," on page 73.

Designing a Password Policy

A password policy is a set of rules that govern how passwords are used in a given system. The password policy mechanism provided by Directory Server allows you to dictate such things as how long a password must be and whether users can reuse passwords. The sections that follow explain:

How Password Policy Works

Directory Server supports fine-grained password policy, which enables you to define password policies at the subtree and user level. This allows the flexibility of defining a password policy for:

Such a policy is known as the global password policy. When configured and enabled, the policy will be applied to all users within the directory except for the Directory Manager entry and those user entries that have local password policies enabled.
You can use this feature to define a common, single password policy for all directory users.
Such a policy is known as the subtree level or local password policy. When configured and enabled, the policy will be applied to all users under the specified subtree.
You can use this feature in a hosting environment to support different password policies for each hosted company (rather than enforcing a single policy for all the hosted companies).
Such a policy is known as the user level or local password policy. When configured and enabled, the policy will be applied to the specified user only.
You can use this feature to define different password policies for different directory users. For example, you can configure some users to change their passwords daily, some users to change it every month, and the rest of the users to change it every six months.

By default, Directory Server includes entries and attributes that are relevant to the global password policy. To set up a password policy for a subtree or user, you will need to add a few additional entries at the subtree or user level and enable the nsslapd-pwpolicy-local attribute of the cn=config entry. This attribute acts as a switch, giving you the flexibility to turn fine-grained password policy on and off. For details about the attribute, check Red Hat Directory Server Configuration, Command, and File Reference.

For a subtree (for example, ou=people, dc=example, dc=com), the following changes are required:

dn: cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
objectClass: top
objectClass: nsContainer
cn: nsPwPolicyContainer
dn: cn="cn=nsPwPolicyEntry, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
objectclass: top
objectclass: ldapsubentry
objectclass: passwordpolicy
dn: cn="cn=nsPwTemplateEntry, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
objectclass: top
objectclass: extensibleObject
objectclass: costemplate
objectclass: ldapsubentry
cosPriority: 1
pwdpolicysubentry: cn="cn=nsPwPolicyEntry, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
dn: cn=nsPwPolicy_cos, ou=people, dc=example, dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn="cn=nsPwTemplateEntry, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
cosAttribute: pwdpolicysubentry default operational-default

For a user (for example, uid=jdoe, ou=people, dc=example, dc=com), the following changes are required:

dn: cn=nsPwPolicyContainer, ou=people, dc=example, dc=com
objectClass: top
objectClass: nsContainer
cn: nsPwPolicyContainer
dn: cn="cn=nsPwPolicyEntry, uid=jdoe, ou=people, dc=example, 
dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, 
dc=com

objectclass: top

objectclass: ldapsubentry

objectclass: passwordpolicy
 

dn: uid=jdoe, ou=people, dc=example, dc=com

changetype: modify

replace: pwdpolicysubentry

pwdpolicysubentry: "cn=nsPwPolicyEntry, uid=jdoe, ou=people, 
dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, 
dc=example, dc=com

You can make these changes either from the Directory Server Console or by using the ns-newpwpolicy.pl script. The Red Hat Directory Server Configuration, Command, and File Reference lists the command-line syntax for the script. The Red Hat Directory Server Administrator's Guide includes procedures for accomplishing these tasks. Once these entries are added to the directory, they help determine the type (global or local) of the password policy Directory Server should enforce.

When a user attempts to bind to the directory, Directory Server determines whether a local policy has been defined and enabled for the user's entry.

The server then compares the user-supplied password with the value specified in the user's directory entry to make sure they match. The server also uses the rules defined by the password policy to ensure that the password is valid before allowing the user to bind to the directory.

Note

The global and local password policies are mutually exclusive. That is, if you define and enable a local password policy for a subtree or user, Directory Server applies that policy during the bind process. In the absence of a local password policy (for example, if you don't define or if you disable a local password policy), the server subjects the user to the global password policy.

The password policy design requires sending the password policy request control with the bind request. The LDAP command-line utility -g supresses sending this request control with the bind request. For details about the -g option, check ldapsearch, ldapmodify, or ldapdelete utilities in Red Hat Directory Server Configuration, Command, and File Reference.


Figure 7-1 illustrates how password-policy checks are enforced when a bind request is processed.

Figure 7-1 Flow Diagram Depicting How Password Policy Checking Works

In addition to bind requests, password policy also occurs during add and modify operations if the userPassword attribute (which is explained in the section that follows) is present in the request.

Password Policy Attributes

This section describes the attributes you set to create a password policy for your server. For instructions to set these attributes, check the Red Hat Directory Server Administrator's Guide.

The attributes are described in the following sections:

Password Change after Reset

The Directory Server password policy lets you decide whether users must change their passwords after the first login or after the password is reset by the 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 "User-Defined Passwords," on page 154, for information.)

If you choose not to allow users to change their own passwords, administrator assigned passwords should not follow any obvious convention and should be difficult to discover.

By default, users do not need to change their passwords after reset.

User-Defined Passwords

You can set up your password policy either to allow or not to 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-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 the 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 Expiration

You can set your password policy so that users can use the same passwords indefinitely. Or you can set your policy 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. On the other hand, 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.

The server remembers the password expiration even if you turn the password expiration feature off. This means that if you turn the password expiration option back on, 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 decide to 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.

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. The Directory Server displays the warning when the user binds to the server. If password expiration is turned on, by default, 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.

Grace Login Limit

If you want to allow some users to login using their expired passwords, you should specify the number of grace login attempts that are allowed to a user after the password has expired.

By default, grace logins are not permitted.

Password Syntax Checking

The password policy establishes some syntax guidelines for password strings, such as the minimum password length guideline. The password syntax-checking mechanism ensures that the password strings conform to the password syntax guidelines established by the password policy. Also, the password syntax-checking mechanism also ensures that the password is not a "trivial" word. A trivial word is any value stored in the uid, cn, sn, givenName, ou, or mail attribute of the user's entry.

By default, password syntax checking is turned off.

Password Length

The Directory Server allows 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 that users can remember the password without writing it down.

By default, no minimum password length is set.

Password Minimum Age

You can configure the Directory Server not to allow users to change their passwords for a time you specify. You can use this feature in conjunction with the passwordHistory attribute to discourage users from reusing old passwords.

Setting the password minimum age (passwordMinAge) attribute to 2 days, for instance, prevents a user from repeatedly changing his 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 set up the Directory Server to store from 2 to 24 passwords in history, or you can disable password history, thus allowing users to reuse passwords.

If you set up your password policy to enable password history, the directory stores a specific number of old passwords. If a user attempts to reuse one of the passwords the Directory Server has stored, the directory rejects the password. This feature prevents users from reusing a couple of passwords that are easy to remember.

The passwords remain in history even if you turn the history feature off. This means that if you turn the password history option back on, users cannot reuse the passwords that were in the history before you disabled password history.

The server does not maintain a password history by default.

Password Storage Scheme

The password storage scheme specifies the type of encryption used to store Directory Server 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 cleartext passwords in the directory. The crypt algorithm provides compatibility with UNIX passwords. SSHA is the most secure of the choices.

Designing an Account Lockout Policy

Once you have established a password policy for your directory, you can protect your user passwords from potential threats by configuring an account lockout policy.

The lockout policy works in conjunction with the password policy to provide further security. The account lockout feature protects against hackers who try to break into the directory by repeatedly trying to guess a user's password. You can set up your password policy so that a specific user is locked out of the directory after a given number of failed attempts to bind.

Designing a Password Policy in a Replicated Environment

Password and account lockout policies are enforced in a replicated environment as follows:

The password policy information in your directory, such as password age, the account lockout counter, and the expiration warning counter, are all replicated. However, the configuration information is kept locally and is not replicated. This information includes the password syntax and the history of password modifications.

When configuring a password policy in a replicated environment, consider the following points:

Designing Access Control

Once you decide on one or more authentication schemes to establish the identity of directory clients, you need to decide how to use the schemes to protect information contained in your directory. Access control allows you to specify that certain clients have access to particular information, while other clients do not.

You specify access control using one or more access control list (ACL). Your directory's ACLs consist of a series of one or more access control information (ACI) statements that either allow or deny permissions (such as read, write, search, and compare) to specified entries and their attributes.

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

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

About the ACI Format

When designing your security policy, it is helpful to understand how ACIs are represented in your directory. It is also helpful to understand what permissions you can set in your directory. This section gives you a brief overview of the ACI mechanism. For a complete description of the ACI format, see the Red Hat Directory Server Administrator's Guide.

Directory ACIs take the general form: 

target permission bind_rule

The ACI variables are defined below:

So, ACIs are expressed as follows: 

"For the directory object target, allow or deny permission if the 
bind_rule is true."

permission and bind_rule are set as a pair, and you can have multiple permission bind_rule pairs for every target. This allows you to efficiently set multiple access controls for any given target. For example: 

target(permission bind_rule)(permission bind_rule)...

You can set a permission that allows anyone binding as Babs Jensen to write to Babs Jensen's telephone number. The bind rule in this permission is the part that states "if you bind as Babs Jensen." The target is Babs Jensen's phone number, and the permission is write access.

Targets

You must decide what entry is targeted by every ACI you create in your directory. If you target a directory entry that is a directory branch point, then that branch point, as well as all of its child entries, are included in the scope of the permission. If you do not explicitly specify a target entry for the ACI, then the ACI is targeted to the directory entry that contains the ACI statement. Also, the default set of attributes targeted by the ACI is any attribute available in the targeted entry's object class structure.

For every ACI, you can target only one entry or only those entries that match a single LDAP search filter.

In addition to targeting entries, you can also target attributes on the entry. This allows you to set a permission that applies to only a subset of attribute values. You can target sets of attributes by explicitly naming those attributes that are targeted or by explicitly naming the attributes that are not targeted by the ACI. Use the latter case if you want to set a permission for all but a few attributes allowed by an object class structure.

Permissions

You allow or deny permissions. In general, you should avoid denying permissions for the reasons explained in "Allowing or Denying Access," on page 162.

You can allow or deny the following permissions:

Bind Rules

The bind rule usually indicates the bind DN subject to the permission. It can also specify bind attributes such as time of day or IP address.

Bind rules allow you to express easily that the ACI applies only to a user's own entry. You can use this to allow users to update their own entries without running the risk of a user updating another user's entry.

Using bind rules, you can indicate that the ACI is applicable:

The following keywords are provided to help you more easily express these kinds of access:

Setting Permissions

By default, all users are denied access rights of any kind. The exception to this is the Directory Manager. For this reason, you must set some ACIs for your directory if you want your users to be able to access your directory.

The following sections describe the access control mechanism provided by your Directory Server. For information about how to set ACIs in your directory, see the Red Hat Directory Server Administrator's 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. The 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 the directory, 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 the directory, 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 in question.

Allowing or Denying Access

You can explicitly allow or deny access to your directory tree. Be careful of explicitly denying access to the directory. Because of the precedence rule, if the directory finds rules explicitly forbidding access, the directory 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 privileges you avoid the need to set an explicit deny privilege.

When to Deny Access

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

For security reasons, you find that you suddenly need to deny access to a particular user, group, or physical location. Rather than spend the time to carefully examine your existing ACL to understand how to restrict appropriately the allow permissions, you may want to temporarily set the explicit deny until you have time to do this analysis. If your ACL has become this complicated, then, in the long run, the deny ACI only adds to your administrative burden. As soon as possible, rework your ACL to avoid the explicit deny and simplify your overall access control scheme.
For example, you can deny all writing activities from Sunday at 11:00 p.m. (2300) to Monday at 1:00 a.m. (0100). From an administrative point of view, it may be easier to manage an ACI that explicitly restricts time-based access of this kind than to search through the directory for all the allow-for-write ACIs and restrict their scopes in this time frame.
If you are allowing a person or group of people to manage some part of the directory tree, but you want to make sure that they do not modify some aspect of the tree, use an explicit deny. For example, if you want to make sure the Mail Administrators do not allow write access to the common name attribute, then set an ACI that explicitly denies write access to the common name attribute.

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 of 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 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 allow you to set access to any directory entry that matches a defined set of criteria.

For example, you could allow read access for any entry that contains an organizationalUnit attribute that is set to Marketing.

Filtered access control rules let you use predefine levels of access. 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 and on using LDAP search filters with ACIs, see the Red Hat Directory Server Administrator's Guide.

Viewing ACIs: Get Effective Rights

It can be necessary to view access controls set on an entry to grant fine-grained access control or for efficient entry management. Get effective rights is an extended ldapsearch which returns the access control permissions set on each attribute within an entry and allows an LDAP client to determine what operations the server's access control configuration will a user to perform.

The access control information is divided into two groups of access: rights for an entry and rights for an attribute. "Rights for an entry" means the rights, such as modify or delete, that are limited to that specific entry. "Rights for an attribute" means the access right to every instance of that attribute throughout the directory.

Some of the situations when this kind of detailed access control may be necessary include the following:

An ldapsearch run with the -J tool will return the access controls placed on a particular entry along with the regular search results. The following search shows user Ted Morris the rights he has to his personal entry: 

./ldapsearch -p 389 -h localhost -D 
"uid=tmorris,ou=people,dc=example,dc=com" -w password -b 
"uid=tmorris,ou=people,dc=example,dc=com" -J 
"1.3.6.1.4.1.42.2.27.9.5.2:true:dn: 
uid=tmorris,ou=people,dc=example,dc=com" "(objectClass=*)"
 
version: 1

dn: uid=tmorris, ou=People, dc=example,dc=com

givenName: Ted

sn: Morris

ou: Accounting

ou: People

l: Santa Clara

manager: uid=dmiller, ou=People, dc=example,dc=com

roomNumber: 4117

mail: [email protected]

facsimileTelephoneNumber: +1 408 555 5409

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

uid: tmorris

cn: Ted Morris

userPassword: {SSHA}bz0uCmHZM5b357zwrCUCJs1IOHtMD6yqPyhxBA==

entryLevelRights: vadn

attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rscow, 
manager:rsc, roomNumber:rscwo, mail:rscwo, 
facsimileTelephoneNumber:rscwo, objectClass:rsc, uid:rsc, 
cn:rsc, userPassword:wo

In this example, Ted Morris has the right to add, view, delete, or rename the DN on his own entry, as shown by the returns in entryLevelRights. For attributes, he has the right to read, search, compare, self-modify, or self-delete the location (l) attribute but only self-write and self-delete rights to his password, as shown in the attributeLevelRights return.

Information is not given for attributes in an entry that do not have a value; for example, if the userPassword value is removed, then a future effective rights search on the entry above would not return any effective rights for userPassword, even though self-write and self-delete rights could be allowed. Likewise, if the street attribute were added with read, compare, and search rights, then street: rsc would appear in the attributeLevelRights results.

You can also view this information through the Console by right-clicking on an entry, either a group or a user, and selecting "Advanced Properties." Checking the "Show effective rights" checkbox will show all the attribute-level rights (r, s, c, w, o) next to the attributes in the list and the entry-level rights (v, a, d, n) underneath the DN.

For more information about using get effective rights, see the Red Hat Directory Server Administrator's Guide.

Using ACIs: Some Hints and Tricks

The following are some ideas that you should keep in mind when you implement your security policy. They can help to lower the administrative burden of managing your directory security model and improve your directory's performance characteristics.

Some of the following hints have already been described earlier in this chapter. They are included here to provide you with a complete list.

Although the default rule is to deny access to any user who has not been specifically granted access, you might find that you can save on the number of ACIs by using one ACI allowing access close to the root of the tree and a small number of deny ACIs close to the leaf entries. This scenario can avoid the use of multiple allow ACIs close to the leaf entries.
This means that if you are allowing or restricting access to a subset of attributes on an object, determine whether the smallest list is the set of attributes that are allowed or the set of attributes that are denied. Then express your ACI so that you are managing the smallest list.
For example, the person object class contains dozens of attributes. If you want to allow a user to update just one or two of these attributes, then write your ACI so that it allows write access for just those few attributes. If, however, you want to allow a user to update all but one or two attributes, then create the ACI so that it allows write access for everything but a few named attributes.
Because search filters do not directly name the object that you are managing access for, their use can result in unexpected surprises, especially as your directory becomes more complex. If you are using search filters in ACIs, run an ldapsearch operation using the same filter to make sure you know what the results of the changes mean to your directory.
Watch out for overlapping ACIs. For example, if you have an ACI at your directory root point that allows a group write access to the commonName and givenName attributes and another ACI that allows the same group write access for just the commonName attribute, then consider reworking your ACIs so that only one control grants the write access for the group.
As your directory grows more complicated, it becomes increasingly easy to overlap accidentally ACIs in this manner. By avoiding ACI overlap, you make your security management easier while potentially reducing the total number of ACIs contained in your directory.
While naming ACIs is optional, giving each ACI a short, meaningful name helps you to manage your security model, especially when examining your ACIs from the Directory Server Console.
Try to limit ACI placement to your directory root point and to major directory branch points. Grouping ACIs helps you manage your total list of ACIs, as well as helping you keep the total number of ACIs in your directory to a minimum.
Although this syntax is perfectly acceptable for the server, it's confusing for a human administrator.

Database Encryption

Because information in a database is stored in plain text, some extremely sensitive information, such as government identification numbers or passwords, may not be protected enough by access control measures. It may be possible to gain access to a server's persistent storage files, either by going directly through the filesystem or by accessing discarded disk drives or archive tape.

Database encryption allows individual attributes to be encrypted as they are stored in the database. When configured, every instance of a particular attribute, even index data, will be encrypted and can only be accessed via a secure channel, such as SSL/TLS.

For information on using database encryption, see chapter 3, "Configuring Directory Databases," in the Red Hat Directory Server Administrator's Guide.

Securing Connections with SSL and Start TLS

After designing your authentication scheme for identified users and your access control scheme for protecting information in your directory, you need to design a way to protect the integrity of the information passed among servers and client applications.

To provide secure communications over the network, you can use the LDAP protocol over the Secure Sockets Layer (SSL) .Directory Server can have SSL-secured connections and non-SSL connections simultaneously. Additionally, Directory Server can support Start TLS, a way of initiating a Transport Layer Security (TLS) connection over a regular port.

SSL/TLS can be used in conjunction with the RC2 and RC4 encryption algorithms from RSA. The encryption method selected for a particular connection is the result of a negotiation between the client application and Directory Server. SSL/TLS can also be used in conjuction with CRAM-MD5, which is a hashing mechanism that guarantees that information has not been modified during transmission.

For information about enabling SSL or using Start TLS, refer to the Red Hat Directory Server Administrator's Guide.

Securing Connections with SASL

As an alternative to SSL, Directory Server supports LDAP client authentication and encryption through the Simple Authentication and Security Layer (SASL). For some UNIX applications and platforms, SASL is the native security method to share information.

SASL is a security framework, meaning it sets up a system that allows different mechanisms to authenticate a user to the server, depending on what mechanism is enabled in both client and server applications. It can also establish an encrypted session between the client and a server.

To establish a secure session, Directory Server utilizes the GSS-API mechanism to encrypt data during sessions, allowing UNIX LDAP clients to authenticate with the server using Kerberos version 5 credentials.

Note

SASL data encryption is not supported for client connections that use SSL/TLS.


More information about using SASL GSS-API, refer to chapter 11, "Managing SSL and SASL," in the Red Hat Directory Server Administrator's Guide.

Other Security Resources

For more information about designing a secure directory, take a look at the following:




Previous
 Contents
 Index
 Next
© 2001 Sun Microsystems, Inc. Used by permission. © 2005 Red Hat, Inc. All rights reserved.
Read the Full Copyright and Third-Party Acknowledgments.

 last updated May 20, 2005