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


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.


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


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.


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.


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


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


  • Encryption

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

  • Access control


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


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.



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.


  • 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


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.


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


    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.


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.

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.


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




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


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.


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


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


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.


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.


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


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.



  • 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


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




By providing only allow privileges, you avoid the need to set an explicit deny privilege.

When to Deny Access


  • 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



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.



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


    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 © 2002 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated February 26, 2002