Previous     Contents     Index     DocHome     Next     
iPlanet Directory Server 5.1 Deployment Guide



Chapter 7   Designing a Secure Directory


How you secure the data in 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 iPlanet Directory Server offer efficient ways of preventing unauthorized access. Refer to "Selecting Appropriate Authentication Methods", "Designing a Password Policy", and "Designing Access Control", 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 iPlanet 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.

iPlanet 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 "User Account Management" in the iPlanet 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, "Directory Data Design," 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:

  • To provide users and applications with access to the information they need to perform their jobs

  • To protect sensitive data regarding employees or your business from general access

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

  • To offer your customers a guarantee of privacy

  • To guarantee information integrity

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 may grant access rights in two ways:

  • Grant all categories of users as many rights as possible while still protecting your sensitive data.

    If you choose this open method, you must concentrate on determining what data is sensitive or critical to your business

  • Grant each category of users the minimum access they require to do their jobs.

    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 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 encrypting data transfers

  • By using certificates to sign data transfers

For information about encryption methods provided in the iPlanet Directory Server, refer to "Password Storage Scheme". For information about signing data, refer to "Securing Connections With SSL".


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 iPlanet Directory Server Administrator's Guide.


Example Security Needs Analysis

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

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

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

  • siroe.com internal information

  • Information belonging to corporate customers

  • Information pertaining to individual subscribers

siroe.com needs the following access controls:

  • Provide access to the directory administrators of Company22 and Company33 to their own directory information.

  • Implement Company22's and Company33's own access control policies for their directory information.

  • Implement a standard access control policy for all individual clients who use siroe.com for internet access from their homes.

  • Deny access to siroe.com's corporate directory to all outsiders.

  • Grant read access to siroe.com's directory of subscribers to the world.



Overview of Security Methods

iPlanet 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.

iPlanet Directory Server provides the following security methods:

  • Authentication

    A means for one party verifies another's identity. For example, a client gives a password to Directory Server during an LDAP bind operation.

  • Password policies

    Defines the criteria that a password must satisfy to be considered valid, for example, age, length, and syntax.

  • Encryption

    Protects the privacy of information. When data is encrypted, it is scrambled in a way that only the recipient can understand.

  • Access control

    Tailors the access rights granted to different directory users, and provides a means of specifying required credentials or bind attributes.

  • Account inactivation

    Disables a user account, group of accounts or an entire domain so that all authentication attempts are automatically rejected.

  • Signing with SSL

    Maintains the integrity of information. If information is signed, the recipient can determine that it was not tampered with during transit.

  • Auditing

    Allows you to determine if the security of your directory has been compromised. For example, you can audit the log files maintained by your directory.

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?

iPlanet 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".


Anonymous Access

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

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 either:

  • Grants anonymous access if the user does not attempt to provide a password

  • Denies 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 "siroe.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=siroe,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 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 out on the Internet.


Certificate-Based Authentication

An alternate form of directory authentication involves using security 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 iPlanet 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". For information about the Start TLS operation, refer to the iPlanet Directory Server Administrator's Guide.


Proxy Authorization

The proxy authorization method is a special form of authentication: a user that binds to the directory using its own identity is granted through proxy authorization the rights of another user.

For example, using proxy authorization, directory administrators can request access to the directory 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 the directory to allow proxy requests:

  • You must grant the administrators the right to proxy as other users

  • You must grant your regular users normal access rights as defined in your access control policy.


    Note You can grant proxy rights to all users of the directory except the Directory Manager. You should exercise great care when granting proxy rights because you grant the right to specify any DN (except the Directory Manager DN) as the proxy DN.


The proxy mechanism is very powerful. One of its main advantages 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 and uses proxy rights.

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

% ldapmodify -D "cn=TimeSheetApplication" -w secretpwd -y "cn=manager,dc=siroe,dc=com" -b "siroe.com" -f weekly_update.ldif

This ldapmodify command shows the application using the permissions of the manager entry (cn=manager) to apply the modifications in the weekly_update.ldif file. Note that the password for the manager is not required.



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 "Managed, Filtered, and Nested Roles".



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 short a password must be and whether users can reuse passwords. When users attempt to bind to the directory, the directory compares the password with the value in the password attribute of the user's directory entry to make sure they match. Directory 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.


Password Policy Attributes

This section describes the attributes you set to create a password policy for your server. 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" 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 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 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 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 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 so 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 to not allow users to change their passwords for 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 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 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:

  • Clear text (no encryption)

  • Secure Hash Algorithm (SHA)

  • Salted Secure Hash Algorithm (SSHA). This encryption method is the default.

  • UNIX crypt algorithm

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 a Password Policy in a Replicated Environment

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

  • Password policies are enforced on the data master.

  • Account lockout is enforced on all servers participating in replication.

Some of the password policy information in your directory is replicated. The replicated attributes are:

  • passwordMinAge and passwordMaxAge

  • passwordExp

  • passwordWarning

However, the configuration information is kept locally and is not replicated. This information includes the password syntax and the history of password modifications. Account lockout counters are not replicated either.

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

  • All replicas issue warnings of an impending password expiration. This information is kept locally on each server, so if a user binds to several replicas in turn, the user receives the same warning several times. In addition, if the user changes the password, it may take time for this information to be updated on the consumer replicas. If a user changes a password and then immediately rebinds, the bind may fail until the consumer replica registers the changes made to the master replica.

  • You want the same bind behavior to occur on all servers, including masters and replicas. Make sure you create the same password policy configuration information on each server.

  • Account lockout counters may not work as expected in a multi-master environment.

  • Entries that are created for replication (for example, the server identities) need to have passwords that never expire. To make sure that these special users have passwords that do not expire, add the passwordExpirationTime attribute to the entry and give it a value of 20380119031407Z (the top of the valid range).


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. 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.

The account lockout feature protects against hackers who try to break into the directory by repeatedly trying to guess a user's password. Account lockout counters are local to a directory server. This feature is not designed as a global lockout from your directory service, which means that even in a replicated environment, account lockout counters are not replicated.



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:

  • The entire directory

  • A particular subtree of the directory

  • Specific entries in the directory

  • A specific set of entry attributes

  • Any entry that matches a given LDAP search filter

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. You can also 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 iPlanet Directory Server Administrator's Guide.

Directory ACIs take the following general form:

target permission bind_rule

The ACI variables are defined below:

  • target

    Specifies the entry (usually a subtree) the ACI targets, the attribute it targets, or both. The target identifies the directory element that the ACI applies to. An ACI can target only one entry, but it can target multiple attributes. In addition, the target can contain an LDAP search filter. This allows you to set permissions for widely scattered entries that contain common attribute values.

  • permission

    Identifies the actual permission being set by this ACI. The permission says that the ACI allows or denies a specific type of directory access, such as read or search, to the specified target.

  • bind_rule

    Identifies the bind DN or network location to which the permission applies. The bind rule may also specify an LDAP filter, and if that filter is evaluated to be true for the binding client application, then the ACI applies to the client application.

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)...

For example, 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, is 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".

You can allow or deny the following permissions:

  • Read

    Indicates whether directory data may be read.

  • Write

    Indicates whether directory data may be changed or created. This permission also allows directory data to be deleted, but not the entry itself. To delete an entire entry, the user must have delete permissions.

  • Search

    Indicates whether the directory data can be searched. This differs from the Read permission in that Read allows directory data to be viewed if it is returned as part of a search operation. For example, if you allow searching for common names and read for a person's room number, then the room number can be returned as part of the common name search, but the room number cannot, itself, be searched for. This would prevent people from searching your directory to see who occupies a particular room.

  • Compare

    Indicates whether the data may be used in comparison operations. Compare implies the ability to search, but actual directory information is not returned from the search. Instead, a simple Boolean value is returned that indicates whether the compared values match. This is used to match userPassword attribute values during directory authentication.

  • Selfwrite

    Used only for group management. This permission allows users to add or delete themselves from a group. Selfwrite works with proxy authorization: it grants the right to add or remove the proxy DN from a group entry (not the DN of the bound user).

  • Add

    Indicates whether child entries can be created. This permission allows a user to create child entries beneath the targeted entry.

  • Delete

    Indicates whether an entry can be deleted. This permission allows a user to delete the targeted entry.

  • Proxy

    Indicates that the user can use any other DN (except Directory Manager) to access the directory with the rights of this DN.


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 easily express 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:

  • Only if the bind operation is arriving from a specific IP address or DNS hostname. This is often used to force all directory updates to occur from a given machine or network domain.

  • If the person binds anonymously. Setting a permission for anonymous bind means that the permission also applies to anyone who binds to the directory.

  • For anyone who successfully binds to the directory. This allows general access while preventing anonymous access.

  • Only if the client has bound as the immediate parent of the entry.

  • Only if the entry that the person has bound as meets a specific LDAP search criteria.

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

  • Parent

    If the bind DN is the immediate parent entry, then the bind rule is true. This allows you to grant specific permissions that, for example, allow a directory branch point to manage its immediate child entries.

  • Self

    If the bind DN is the same as the entry requesting access, then the bind rule is true. For example, you can grant specific permission that allows individuals to update their own entries.

  • All

    The bind rule is true for anyone who has successfully bound to the directory.

  • Anyone

    The bind rule is true for everyone. This keyword is what allows or denies anonymous 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 iPlanet 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:

  • Create one rule that allows write privileges to every attribute except the uid attribute. This rule should apply to everyone.

  • Create one rule that allows write privileges to the uid attribute. This rule should apply only to members of the Directory Administrators group.

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:

  • You have a large directory tree with a complicated ACL spread across it.

    For security reasons, you find that you suddenly need to deny access to a particular user, group, or physical location. Rather than take the time to carefully examine your existing ACL to understand how to appropriately restrict 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.

  • You want to restrict access control based on a day of the week or an hour of the day.

    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.

  • You want to restrict privileges when you are delegating directory administration authority to multiple people.

    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 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 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. 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:

  • Create an attribute on every user's directory entry called publishHomeContactInfo.

  • Set an access control rule that grants read access to the homePhone and homePostalAddress attributes only for entries whose publishHomeContactInfo attribute is set to TRUE (meaning enabled). Use an LDAP search filter to express the target for this rule.

  • Allow your directory users to change the value of their own publishHomeContactInfo attribute to either TRUE or FALSE. In this way, the directory user can decide whether this information is publicly available.

For more information about using LDAP search filters, and on using LDAP search filters with ACIs, see the iPlanet 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.

  • Minimize the number of ACIs in your directory.

    Although Directory Server can evaluate over 50,000 ACIs, it is difficult to manage a large number of ACI statements. A large number of ACIs makes it hard for you to determine immediately the directory object available to particular clients.

    iPlanet Directory Server 5.1 provides a new feature that minimizes the number of ACIs in the directory by using macros. Macros are placeholders that are used to represent a DN, or a portion of a DN, in an ACI. You can use the macro to represent a DN in the target portion of the ACI, or in the bind rule portion, or both. For more information on macro ACIs, refer to "Managing Access Control" in the iPlanet Directory Server Administrator's Guide.

  • Balance allow and deny permissions.

    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.

  • Identify the smallest set of attributes on any given ACI.

    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 people 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.

  • Use LDAP search filters cautiously.

    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.

  • Do not duplicate ACIs in differing parts of your directory tree.

    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 accidentally overlap 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.

  • Name your ACIs.

    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 console.

  • Use standard attributes in user entries to determine access rights.

    As far as possible, use information that is already part of standard user entries to define access rights. If you need to create special attributes, consider creating them as part of a role or Class of Service (CoS) definition. For more information on roles and CoS, refer to "Grouping Directory Entries".

  • Group your ACIs as closely together as possible within your directory.

    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, and also helps you keep the total number of ACIs in your directory to a minimum.

  • Avoid using double negatives, such as deny write if the bind DN is not equal to cn=Joe.

    Although this syntax is perfectly acceptable to the server, it is confusing for a human administrator.



Securing Connections With SSL

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).

SSL 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 can also be used in conjuction with CRAM-MD5, which is a hashing mechanism that guarantees that information has not been modified during transmission.

Directory Server can have SSL-secured connections and non SSL connections simultaneously.

For information about enabling SSL, refer to the iPlanet 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     DocHome     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated October 29, 2001