Chapter 5 Planning Security Policies

Part of any directory deployment is determining the security policy that you will use for your directory. Security policy means the rules that you use to grant and restrict directory access to individual users or, more frequently, groups of users.

In this chapter you will learn about the implementation of security policies and how you can represent security policies in your directory. This chapter includes the following sections:

Security Policy Overview—This section introduces the concept of security policies.

Directory Access Rules—This section describes how users access (or bind to) the directory. Topics include general client authentication, certificate-based authentication, authentication when using Netscape Directory Server for NT, anonymous access, and root DN authentication.

Access Control Lists—This section briefly introduces the concept of access control lists (ACL).

Setting Permissions—This section provides advice on when and where in your directory you should place access control information.

The ACI Format—This section provides a high-level overview to the Netscape Directory Server access control mechanism. Topics include ACI format and the types of permissions that you can define in your directory using ACIs.

Creating a Security Policy—This section describes the most important issues in building a security policy. Topics include using groups to manage access control, determining your directory's general access mechanism, and physical points of access to your directory.

• Kind of information you are keeping in your directory
• Ways in which you are accessing your directory
• Ways in which you are updating or managing your directory

The Netscape Directory Server provides an extremely flexible access control mechanism that you can use to define virtually any security policy, from the very simple to the very complex.

Because of the flexibility of the access control mechanism, plan some time during your deployment phase during which you can apply your access control information and make sure that it adequately represents your security desires. During this time, become familiar with the intricacies of the access control mechanism and make sure that the access controls that you add to your directory are as easy to administer as possible.

Your security policy should be strong enough to prevent sensitive information from being modified or retrieved by unauthorized users while simple enough that you can easily administer it. Ease of administration is very important when it comes to your security policy. 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.

The mechanism used for directory authentication is the same for both people and LDAP-aware applications (such as any Netscape server that is configured to use the directory).

User Authentication

In general you must authenticate to the Directory Server before you can access the directory's contents. The only exception to this is if you have set up anonymous access for your directory.

Conceptually, directory authentication can be thought of as logging in to the directory. LDAP Directory Servers, however, usually refer to this operation as binding to the directory.

Generally, bind operations consist of providing the equivalent of a user ID and a password. However, in the case of an LDAP directory, the user ID is a distinguished name. The distinguished name used to access the directory is referred to as the bind DN. It is generally true that the bind DN corresponds to the name of an entry in the directory, although this is not always the case. When you bind as the root DN, for example, there is no corresponding directory entry.

Also, the bind DN most frequently corresponds to an entry that represents a person, but again this is also not always true. Some directory administrators find it useful to bind as an organizational entry rather than as a person. The only real requirement is that the bind DN and the corresponding password must somehow be known to the directory. This means that the entry represented by the bind DN must use an object class structure that allows the userPassword attribute.

Most LDAP clients go to some lengths to hide the bind DN from the user because DNs are often long strings that are hard to remember and easy to mistype. 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 searches the directory for that identifier and returns the associated distinguished name (such as uid=fchen, ou=people, o=airius.com).
3. The LDAP client binds to the directory using the retrieved distinguished name and the password supplied by the user.

Certificate-Based Authentication

An alternate form of directory authentication involves using security certificates to bind to the directory. Instead of providing a user name and a password, the user is prompted for a password the first time he attempts to access the directory. However, this password is not matched to a password stored in the directory. Instead, it is the password that opens the user's certificate database.

If the password supplied by the user is correct, the directory client obtains authentication information from the certificate database. The client and the Directory Server then use this information to identify the user by mapping the user's certificate to a directory DN. Directory access is allowed or denied based on the directory DN that is discovered based on this identification process.

For more information on certificates and SSL, see Managing Servers with Netscape Console.

Authenticating Using Directory Server for NT

If you are not using the NT Synchronization Service, you can skip this section.

The Directory Server is capable of performing NT pass-through authentication if all the proper conditions are met. NT pass-through authentication is the process by which the Directory Server contacts an NT domain and confirms a user's authentication with that domain. If the user's authentication credentials are confirmed by the NT domain, the user is granted access to the directory.

When users authenticate to a Directory Server running on NT, the Directory Server first attempts to confirm the user's identity using the normal Directory Server authentication mechanisms. If this authentication fails, the Directory Server attempts to confirm authentication with the appropriate NT Primary Domain Controller if the following conditions are true:

• The Directory Server is running in the NT domain where the authentication must occur, or the Directory Server is running in an NT domain that shares a trust relationship with the NT domain where the authentication must occur.
• The user's bind attempt must provide a distinguished name that is known to the directory. This is the bind DN, and it is used to retrieve the user's bind entry.
• The password that the user provides must not match the password stored on the user's bind entry. This condition can also be met if the user's bind entry does not have a userPassword attribute-data pair.
• The user's bind entry contains the NTUser object class.

1. Contacts the NT domain identified on the user's NTUserDomainId attribute.
2. Attempts to authenticate to the NT domain using the user ID stored on the NTUserDomainId attribute and the password provided by the user on the original authentication attempt.

Anonymous Access

Anonymous access can be configured for the directory such that anyone can access the directory without providing bind credentials. That is, clients do not need to provide a bind DN or password to gain access. When a bind DN and password are not provided to the directory, the directory assumes a null bind DN and a null password, and the access that it allows or denies depends on the permissions that you have set up for anonymous access.

Anonymous access is also granted if the user authenticates using a bind entry that does not include a userPassword attribute-data pair and the user does not provide a password on the bind attempt.

However, the Directory Server fails the bind attempt if the user authenticates using a bind entry that does not include a userPassword attribute-data pair and the user provides any non-null string for the password.

Usually directory administrators only allow anonymous access for read, search, and compare privileges (not for write, add, delete, or selfwrite). Also, the access is usually limited to a subset of attributes that contain information generally useful across the enterprise, such as person names, telephone numbers, email addresses, and so forth. 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, salary information, and so forth.

The various privileges that you can set for the directory are described in "Permissions". For general advice for allowing or denying access to specific attributes, see "Setting Permissions".

Directory Manager Authentication

The Directory Manager is the distinguished name for the privileged directory user (it was formerly known as the root DN). After authentication, the Directory Manager has complete access to the directory regardless of the access controls in use on the directory.

It is not required that a Directory Manager be configured for the directory. In general, though, the Directory Manager is configured when the Directory Server is configured. As a general rule, you should use your Directory Manager to initially populate your database and set up access controls for normal directory entries. As soon as you have configured at least one entry that has full access to the directory, then you should stop using the Directory Manager for normal directory operations.

Warning. If you configure a Directory Manager at server installation time, you must also provide a Directory Manager password. However, it is possible for this password to be deleted from slapd.conf by direct editing of the file. This can create operational problems with your server. Always be sure a Directory Manager password is configured in slapd.conf when a Directory Manager is configured for your Directory Server.

For more information on database usage and your Directory Server, see the Netscape Directory SDK Programmer's Guide.

Using the ACL, you can set permissions for:

• 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

The following sections describe the access control mechanism provided by your Directory Server. For information on how to set ACIs in your directory, see the Netscape Directory Server Administrator's Guide.

The Precedence Rule

When a user attempts any kind of access to a directory entry, the Directory Server examines the access control set in the directory from the entry being accessed back to the top, or root, or the directory tree held by the server.

Because the ACL allows you to set permissions that denies as well as grant access, it is important to remember the precedence rule:

Precedence Rule. If two permissions exist and are in conflict, 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 for a user. 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 the user. Then you have to create an additional allow-for-write permission for the user in question.

Because of this, and because by default users are denied access anyway, you should use deny permissions sparingly in order to avoid potential confusion.

Allowing or Denying Access

You can either explicitly allow access or you can explicitly deny access to your directory tree. Be careful of explicitly denying access to the directory. Because of the precedence rule, if the directory can find any rules explicitly forbidding access, it will do so regardless of any conflicting permissions that may grant access. It can be very confusing to set a rule that allows access, only to find that access is not permitted because another rule explicitly denies the access from some other point in the directory.

Because of the precedence rule and the administrative problems an explicit deny can create, and because access is denied by default anyway, it is best to limit the scope of your allow access rules to include only the smallest possible subset of users or clients. 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. A better approach is to 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.

When to Explicitly Deny Access

Because of the reasons stated above, there are very few situations when it is desirable to set an explicit deny. Even so, you may find an explicit deny to be useful in the following situations:

• 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 spend 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 will only add to your administrative burdens. As soon as possible, you should 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. That is, if you are allowing a person or a group of people to manage some part of the directory tree, but you want to make sure that this delegated administration group does not modify some aspect of that part of the tree, then use an explicitly deny to disallow that type of access. For example, if you want to make sure the Mail Administrators do not allow write access to the common name attribute, then set a ACI that explicitly denies write access to the common name attribute.

Access Control rules can be placed on any entry in the directory. For the most common usages of the Directory Server, access control rules are placed on entries of type country, organization, organizationalUnit, inetOrgPerson, or group.

To simplify your ACL administration, try to group these rules together 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 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. This feature allows you to set a type of 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.

One of the best uses of filtered access control rules is that you can use this feature to predefine types of access. For example, suppose your directory contains home address and telephone number information. Some people will want to publish this information, while others will 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. 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.

Directory ACIs take the following general form:

<target> <permission> <bind rule>

Each of these parts of an ACI are:

• <target>—Specifies the entry (usually a subtree) to which the ACI is targeted, and/or the attribute to which it is targeted. That is, 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 is allowing or denying 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, then the ACI applies to the client.

"For the directory object <target>, allow or deny <permission> if the <bind rule> is true."

<target>(<permission><bind rule>)(<permission><bind rule>)...

Targets

You must decide what entry is targeted by each and every ACI that you create in your directory. If you target a directory entry that represents 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".

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 it is that sits in room number 12.
• Compare—Indicates whether the data may be used in comparison operations. Compare implies the ability to search, but actual directory information is not returned as a result of the search. Instead, a simple Boolean value is returned that indicates whether the compared values match. This is used most commonly to match userPassword values during directory authentication.
• Selfwrite—Used only for group management. This permission allows someone to add or delete themselves to or from a group.
• 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.

While targets indicate what directory object the ACI applies to, bind rules indicate the bind situations that the ACI applies to. Normally this means that the bind rule indicates which bind DNs the permission applies to.

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 that part that states "if you bind as Babs Jensen." The target is Babs Jensen's phone number, and the permission is write access.

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.

However, bind rules can be used to express more complex bind situations than just bind DNs.

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 also means that the permission applies to anyone who binds to the directory as well.
• 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.

• Parent—If the bind DN represents 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 for which access is requested, then the bind rule is true. This allows you to grant specific permission that, for example, allows an individual user to update her own entry.
• 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.

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 in this list for completeness.

• Minimize the number of ACIs in your directory. You should use no more than 100 ACIs in your directory. This is because it is difficult to manage a large number of ACI statements. Specifically, a large number of ACIs will make it hard for you to determine immediately which directory object can be accessed by what client.
• 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 structure contains dozens of total 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, make sure you test your directory access thoroughly each time you change the filters so that you are certain what the results of the changes mean to your directory.
• Avoid explicit denies. Because of the precedence rule, it is administratively easier to simply restrict the scope of any given allow access to the smallest set of possible users or directory objects. If you do use explicit denies, be prepared for situations where users are unexpectedly unable to access directory objects.
• 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 will become increasingly easy to accidentally overlap ACIs in this manner. By avoiding ACI overlap, you will 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, granting each ACI a short, meaningful name will help you to manage your security model, especially when examining your ACIs from the Directory Server Manager.
• 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. This will help you manage your total list of ACIs, as well as help you keep the total number of ACIs in your directory to a minimum.
• Use the root DN sparingly, if at all. Instead, you should create a directory administrator entry that has full access to your directory contents. This allows you to easily change or modify the administrative entry in the event that it becomes compromised (whereas changes to the root DN require a server restart).

When you performed your data analysis (see "Analyzing Your Site Survey"), you should have 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 policy.

Planning Your Groups

When you perform your data analysis, you make some basic decisions on what groups of people can read and write information. You should now formally identify all the groups that you need in your directory. As you formally identify and name your groups, make sure you document your decisions. Make sure you know the formal name of each group, the general permissions you want each group to have, and the people who you immediately will want to add to each group.

Note. While they are implemented in essentially the same way, there are two types of groups that your directory will contain. One is used for identifying access control permissions for a defined set of people. Another is used for managing mailing lists. This latter group typically uses the mailGroup object class. Its usage is not discussed in this manual.

For example, many directories commonly have an Administrator's group (Netscape servers actually require this group for certain kinds of server administration. For more information, see Managing Servers with Netscape Console). Usually the Administrator's group is granted complete access to the directory. By adding users to this group, you are granting those users full read, write, search, and compare privileges to the entire directory. Typically you will want this group to contain just a small number of users (3-10, depending on the size of your enterprise).

In addition to the Administrator's group, you may also want to create groups of users that have some, but not complete, write access to the directory. One such group may be Department Administrators. Some enterprises use Department Administrators to manage a subset of employee information, such as fax numbers, department numbers, and physical location information. By distributing these administration burdens to a select, identifiable group of people, you are make your directory easier to manage and ensure that you have data consistency at least at the department level.

Some other groups that you might need include:

• an Accounting group for people with read and write access to financial information
• an HR group for people with read and write access to sensitive employee information
• a Sales Administration group for people with read and write access to customer contact information
• a Mail Administrators group for people who can set up and manage mail accounts
• a News Administrators for people who can create and manage news (discussion) groups

Group Usage Advice

As you plan your groups, make sure you do the following:

• Avoid high levels of nesting within groups. That is, do not create a situation where one group is a member of another group, which is in turn a member of a third group, and so on. This kind of nesting will severely impact your server performance. You should limit yourself to no more than 2 levels of nesting to avoid server degradation.
• Do not create circular groups. That is, do not create a situation where group 1 is a member of group 2 and group 2 is a member of group 1. This can cause the server to loop repeatedly through the group attempting to find out if a bind DN is a member of the group. Eventually the server will time out, but activities like this will degrade your server's performance.

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

Consider these key points:

• Anonymous access provides the easiest form of access to your directory. However, anonymous access does not allow you to track who is performing what kinds of searches; only that someone is performing searches. Also, remember that anonymous access means anyone can make a connection 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.
• Some LDAP clients, such as Netscape Communicator 4.x, require anonymous access for directory lookups. The address book function in Communicator 4.x requires anonymous access, as does the public key search function in Communicator 4.x. If you are using an LDAP product that requires anonymous access, then you should carefully consider what pieces of directory data are required by that product and make sure to allow anonymous access only to those pieces of data.

Many enterprises restrict directory updates to clients running at a given IP address or from a specific DNS hostname. This ensures that the directory cannot be updated unless the person has access to a specific machine or sets of machines.

You may want to restrict read and search access to your directory to only a specific IP address, subnet, or domain name. This allows you to ensure that only people physically inside your enterprise can access your directory. To support this, the Netscape Directory Server ACL model allows wildcard patterns on IP addresses and DNS hostnames.

You may feel that this level of access control is unnecessary for a wide variety of reasons. However, you should consider this level of directory access if any of the following apply to you:

• You are running an extranet and are allowing some amount of directory information to be read and/or written to your directory from the Internet. In this case, you may want to restrict access to your directory based on domain name or IP address.
• You have one and only one location from which you want to update directory information. This will generally be true if you are populating your directory by using some HR or Accounting package, or by using some kind of an LDAP gateway. In this case, restrict directory updates to only that machine or subnet where the mastering application is running.
• You are an Internet Service Provider and you want to make sure directory updates and/or reads are performed only from the appropriate site.

Note. There is no way to prevent people from bypassing this type of security by faking (spoofing) the IP address or DNS hostname that they are running from. Therefore, avoid relying only on physical points of access to determine access control unless you are confident that your user community will not attempt to bypass your directory security policy.