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.

Directory Access Rules

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

User Authentication

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

Note, too, that 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

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

Authenticating Using Directory Server for NT

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

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

Root DN Authentication

It is not required that a root DN be configured for the directory. In general, though, the root DN is configured when the directory server is configured. As a general rule, you should use your root DN 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 root DN for normal directory operations.

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.

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

Setting Permissions

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

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.

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

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

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

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

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.

The ACI Format

Directory ACIs take the following general form:

   <target> <permission> <bind rule>

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

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

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.

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

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

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

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.

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

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

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.

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.

Last Updated: 02/17/98 15:41:59

Изменено 19-Mar-98 10:06
Copyright (С) 1999 Оптилинк