Planning Security Policies

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

Security Policy Overview

The security policy that you use for your directory is a reflection of the:

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.

You can keep your directory as secure or relaxed as is dictated by the situation in your enterprise. The planning that you performed for your directory data will form the foundation for your security policy. In addition, the general attitude at your enterprise regarding security will also drive the nature of your directory's security policy.

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.

Directory Access Rules

It is useful to understand how LDAP clients bind (authenticate) to the directory before examining how you can control access to your directory.

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

Warning

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

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

Access-Control Lists

Access-Control Lists (ACLs) provide you with the ability to control access to your directory. You can either allow or deny access to your directory using ACLs. Your directory's ACL is composed 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 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, all users belonging to a specific group, or for all users of the directory. Finally, you can also define access for a network locations such as an IP address or a DNS name.

Setting Permissions

By default all users are denied access rights of any kind. The exception to this is the root DN. 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 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.

By providing only allow privileges that carefully restrict the scope of the privilege, you avoid the need to set an explicit deny privilege and therefore avoid possible administrative problems.

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

Where to Place Access-Control Rules

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

For more information on using LDAP search filters, and on using LDAP search filters with ACIs, see the Netscape Directory Server Administrator's Guide.

The ACI Format

When designing your security policy, it is helpful to have a broad understanding of how ACIs are represented in your directory. It is also helpful to understand what permissions you can set in your directory. Note that this section is not intended to provide you with a detailed description of the Netscape ACL mechanism. For a complete description of the ACL format, see the Netscape Directory Server Administrator's Guide.

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.

Taken together, ACIs are expressible as follows:

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

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

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.

Bind Rules

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

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

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.

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.

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

Creating a Security Policy

Now that you have a general idea of how access-control is handled in the directory, you can begin generating your security policy.

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 (SuiteSpot servers actually require this group for certain kinds of server administration. For more information, see Managing Netscape Servers). 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

In addition, if you want to allow local management of directory data, then you need to consider the administrative groups needed at each individual site. This is especially true if you are allowing directory data to be managed at local sites around your enterprise. This situation is especially likely to occur if you are replicating data to geographically separate locations.

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.

Determining General Directory Access

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.0 requires anonymous access, as does the public key search function in Communicator 4.0. 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.

Determining Points of Access

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.

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

Museum

Planning Security Policies