Ability to define ACL and ACI. Ability to describe basic rules for constructing ACIs.
We'll describe the actual procedure for editing an ACI in the next section. This section is mostly about background information.
See Chapter 5 of the Deployment Guide.
| # Introduction To Access Control Lists ### Background Access to the Directory Server, including administrative and routine lookup access, is managed through a configuration file containing the access control list, or ACL. Individual entries in the ACL allow you to do the following: Control access permissions for all or part of the directory tree. Control access to individual attributes viewable by non-administrative users, for example, beeper numbers but not home phone numbers. Control access for specific users and groups, for example HR. Control access from specific IP addresses or DNS names so that if a request is received from a specific machine, only certain permissions are allowed regardless of the ID of the user making the request. Control anonymous access to the directory database. ### Access Control Information Each entry in the directory can contain one or more ACI attributes, which holds the access control information (ACI) instructions for the entry. The ACI instruction is composed of three parts. Targets: The target specifies what object, object attributes, or group of objects and attributes you are controlling access to. Permissions: The permission specifically outlines what rights you are either allowing or denying. Bind Rules: The bind rules specify the circumstances under which access is to be granted or denied. Bind rules indicate who can access the directory, when the directory can be accessed, and the physical network locations that the directory can be accessed from. The permission and bind rule portions of the ACI are set as a pair, and you can have multiple permission-bind rule pairs for each target. This allows you to efficiently set multiple access controls for a given target. For example:
    <target>(<permission><bind rule>)(<permission><bind rule>)...
### Targets The target identifies what directory entry the ACI applies to. The target can be a directory entry (usually a branch of your directory tree) directory entry and one or more entry attributes group of entries and/or attributes that are the result of a single LDAP filter Targeting a Directory Entry When you target a directory entry, the ACIs you set apply to the target and all of its children. For example, if you target the entry `ou=accounting, o=airius.com`, the ACI will apply to all entries in the accounting branch of the Airius tree. Most often, you will want to place your ACIs on branch points in the directory rather than on individual leaf objects. You can also use wildcards when targeting a directory entry. For example, targeting `uid=c*a, o=airius.com` would target all directory entries with user ID attributes that start with `c` and end with `a`. Note however that you cannot wildcard the suffix portion of the distinguished name. For example, targeting `uid=bjensen, o=*.com` is not a legal command. If you are setting access control using the Server Manager, you target an entry using the Target field on the Access Control Rules form. Keep in mind that the entry you target must be at the same level or a child of the entry containing the ACI. For example, if the ACI attribute you are modifying resides on the `ou=accounting, o=airius.com` entry, you cannot target the `uid=sarette, ou=people, o=airius.com` entry because it is not a child of the accounting tree; rather it is within a separate branch of the Airius tree. Targeting Attributes In addition to targeting directory entries, you can also target one or more attributes included in the targeted entry. This is useful for when you want to deny or allow access to partial information about an entry. For example, you could allow access to only the common name, surname, and telephone number attributes of a given entry. Or you could deny access to sensitive information such as passwords or salary information. You can specify that the target attribute either is (=) or is not (!=) equal to a specific attribute. The attributes you supply should be recognized members of your schema, although they do not have to be allowed by the object class of the targeted entry. If you are setting access control using the Server Manager, you specify one or more attributes to deny or allow access to by using the Attr field of the Access Control Rules form. As is true when targeting directory entries, you can also use wildcards when targeting an attribute. For example, to target all attributes that begin with the letter "u", you would set the Attr field to `u*`. Targeting using LDAP Filters In addition to explicitly targeting directory entries and attributes, you can also use LDAP filters to target a group of entries and/or attributes that match a certain criteria. When searching the directory, LDAP filters select the entries to be returned as a result of the search operation. The same is true when you use LDAP filters in ACIs, except that the entries and attributes returned are then targeted by the ACI. For example, if your target is `o=airius.com`, you could set the filter to target the `ou=people` and `ou=groups` trees. Without the filter, the ACI would apply to all entries below`o=airius.com`. However, with the filter, the ACI will only apply to the `ou=people, o=airius.com` and `ou=groups, o=airius.com` entries and their child entries. If you are setting access controls using the Server Manager, you can specify a target filter in the Filter field of the Access Control Rules form. Although targeting using LDAP filters can be useful when you are targeting entries and attributes that are spread across the directory, the results are sometimes unpredictable. Because search filters do not directly name the object that you are managing access for, it is easy to unintentionally allow or deny access to the wrong objects, especially as your directory becomes more complex. Additionally, filters can make it difficult for you to troubleshoot ACI problems within your directory. If you do use filtering, do so sparingly. Be sure to test your directory access thoroughly each time you change a filter so that you are certain what the results of the change mean for access to your directory. ### Permissions Permissions specify the type of access you are allowing or denying. You can either allow or deny an entity from performing specific operations to the directory. The various operations that can be assigned are known as rights. By default all users are denied access rights of any kind. The exception to this is the user defined in the Root DN parameter. This user is known as the root or unrestricted user. The unrestricted user has full access to your directory regardless of the permissions set for the directory. For this reason, you must set some permissions for your directory if you want any normal users to be able to access your directory. There are two parts to setting permissions: Allowing or denying access Assigning rights Allowing or Denying Access You can either explicitly allow access or you can explicitly deny access to your directory tree. When an LDAP client attempts to perform any kind of access to a directory entry, the Directory Server looks for access control information from the entry being accessed back to the top, or root, or the directory tree. When deciding whether to allow or deny access, you should keep the precedence rule in mind. 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 the specific permissions you grant that user. To allow a specific user write permissions to the directory, you have to restrict the scope of the original denial for write permission 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. When setting access control using the Server Manager, you specify whether to allow or deny access using the Action area. When setting access control using LDIF, you use the allow or deny keywords in the permission portion of the ACI statement to explicitly allow or deny access. Assigning Rights Rights detail the specific operations a user can perform on the directory data. You can either allow or deny all rights or you can assign one or more of the following rights: Read -- Indicates whether directory data may be read. Write -- Indicates whether attributes may be added, modified, or deleted. Add -- Indicates whether the user or application can create entries. Delete -- Indicates whether entries can be deleted. Search -- Indicates whether the directory data can be searched for. Users must have Search and Read rights in order to view the data returned as part of a search operation. Compare -- Indicates whether the data may be used in comparison operations. With compare rights, the directory returns a yes or no in response to an inquiry, but the user cannot see the value of the entry or attribute. Selfwrite -- Indicates whether people can add or delete themselves from a group. This right is only used for group management. When setting access control using the Server Manager, you specify which rights to allow or deny using the Rights area. When setting access control using LDIF, you use the rights keywords within the permission portion of the ACI statement to explicitly allow or deny access. ### Bind Rules In the Directory server, binding refers to logging in or authenticating to the directory. The circumstances under which binding occurs determine whether access to the directory is allowed or denied. Every permission set in an ACI has a corresponding bind rule that details the specific circumstance under which binding must occur for the ACI to be applied. Bind rules can be simple. For example, a bind rule can simply state that the person accessing the directory must belong to a specific group. Bind rules can also be more complex. For example, a bind rule can state that a person must belong to a specific group and must log in from a machine with a specific IP address, between 8 AM and 5 PM. Whether access is allowed or denied depends on whether an ACI's bind rule is evaluated to be true. Bind rules use one of the two following patterns:
            <keyword> = "<expression>";
            <keyword> != "<expression>";
where equal (=) indicates that `<keyword>` and `<expression>` must match in order for the bind rule to be true, and not equal (!=) indicates that `<keyword>` and `<expression>` must not match in order for the bind rule to be true. Bind rules tell who can access the directory, when, and from where. More specifically, bind rules specify the users and groups that can access the directory location from which an entity must bind time or day on which binding must occur type of authentication that must be in use during binding Additionally, bind rules can be complex constructions that combine bind methods using Boolean operators. Each bind method is detailed in the following sections. #### User and Group Access Most commonly, bind rules state who can access the directory. A bind rule may state that Anyone can access the targeted resource. This is known as anonymous access. All authenticated users can access the targeted resource. This is known as general access. A specific user can access the targeted resource. This is known as user access. A specific group member can access the targeted resource. This is known as group access. A user specified in an attribute on another user entry can access the targeted resource. This is known as access based on attribute value. Anonymous Access Anonymous access can be configured for the directory such that anyone can access it. In this situation, users do not need to provide a Bind DN or password to gain access. You can limit anonymous access to specific types of access (for example, access for read or access for search) or to specific subtrees or individual entries within the directory. If you are setting access control using the server manager, you can define anonymous access by clicking Anyone (No Authentication) in the User/Group area. General Access You can use bind rules to indicate that the permission applies to anyone who has successfully bound to the directory. This allows general access while preventing anonymous access. If you are setting access control using the server manager, you can define general access by clicking Authenticated people only and All in the User/Group area. User Access You can use bind rules to specify that access to the targeted resource will be granted or denied only if the user binds using a specific DN. You can also specify groups of users by using the wildcard character (*). For example, specifying a user DN of uid=u*, o=airius.com indicates that only users with a Bind DN beginning with the letter `u` will be allowed or denied access based on the permissions you set. If you are setting access control using the server manager, you set user access using the UserDN(S) field in the Users/Groups area. Using LDAP URLs You can dynamically target users in ACIs using a URL with a filter as follows: `"ldap:///<suffix>??sub?(filter)"` For example, all users in the accounting and engineering branches of the Airius tree would be granted or denied access to the targeted resource dynamically based on the following URL: `"ldap:///o=airius.com??sub?(ou=engineering)(ou=accounting)"` Note: Do not specify a hostname or port number within the LDAP URL or the URL will be skipped. Parent Access Another special user access bind rule is the case in which a user is granted or denied access to the entry only if the Bind DN is the parent of the targeted entry. If you are setting access control using the Server Manager, you can set up parent access by entering `parent` in the UserDN(S) field in the Users/Groups area. Self Access Another special user access bind rule is the case in which you want to grant or deny users access to their own entries. In this case, access would be granted or denied if the Bind DN matches the DN of the targeted entry. If you are setting access control using the Server Manager, you can set up self access by entering `self` in the UserDN(S) field in the Users/Groups area. Group Access You can use bind rules to specify that access to a targeted entry will be granted or denied only if the user binds using a DN that belongs to a specific group. If you are setting access control using the server manager, you can define specific groups using the GroupDN(s) field in the Users/Groups Area. Access Based on Attribute Value You can set a bind rule such that the ACI will apply only if the Bind DN matches a DN specified in a specific attribute of the targeted entry. The named attribute must be one that is expected to contain a full distinguished name. For example, you can specify that the Bind DN must match the DN in the manager attribute of the user entry. In this situation, only the user's manager would have access to the entry. If you are setting access control using the server manager, you can specify that the Bind DN must match the DN in an attribute in the user entry by typing the attribute name in the UserDnAttr field. Access from a Specific Machine or Domain Using bind rules, you can indicate that the ACI is applicable only if the bind operation is arriving from a specific IP address or fully qualified DNS domain or hostname. This is often used to force all directory updates to occur from a given machine or network domain. You can also use the wildcard character (*) to denote multiple machines. For example, you could use a wildcard IP address such as `12.3.45.*` to specify a specific subnetwork or `123.45.6.*+255.255.255.115` to specify a subnetwork mask. Or you could use a wildcard domain name such as `*.airius.com` to specify a specific DNS domain. If you are setting access control using the server a, you can define specific machines to which the ACI applies using the From Host area. Access at a Specific Time of Day or Day of Week You can also use bind rules to specify that the ACI will only apply at a certain time of day or on a certain day of the week. For example, you can set a rule that will allow access only if it is between the hours of 8 AM and 5 PM Monday through Friday. The time used is the time on the local host. There is no support for time-based bind rules in the Server Manager. However, if you are using the Server Manager to set access control, you can specify time-based bind rules using the Extra area (or Customized Expressions) to enter the LDIF. Access Based on Authentication Method You can also set bind rules that state that the ACI will apply only if a client binds to the directory using a specific authentication method. The authentication methods you can require are None: Authentication is not required. Simple: The ACI will apply only if the client accesses the directory using a user name and password. SSL: The ACI will apply only if the client accesses the directory over a Secure Sockets Layer (SSL) connection (over LDAPS). SASL: The ACI will apply only if the client accesses the directory over a Simple Authentication and Security Layer (SASL) connection. For information on setting up SASL, see the Netscape Directory Server Programmer's Manual. If you are using the Server Manager to set access control, you can set up authentication-based bind rules using the User/Group area. Boolean Bind Rules Bind rules can be complex expressions that use the Boolean expressions `AND`, `OR`, and `NOT` to set very precise access rules. If you are using the Server Manager to set access control, you will need to use the Extra area (or Customized Expressions) to enter the LDIF commands if you want to use boolean bind rules. Evaluating Boolean Bind Rules Boolean expressions are evaluated in the following order: Innermost to outermost parenthetical expressions first All expressions from left to right Also, the Boolean `OR` and Boolean `AND` operators have no order of precedence and they are evaluated from left to right. However, the boolean `NOT` operator is evaluated before the Boolean `OR` and Boolean `AND`. Thus, in the following example the `NOT` operator is evaluated before the `AND` operator: <bind rule 1> and not <bind rule 2>

Copyright © 2000
Sun-Netscape Alliance