Managing Access Control

By default all users are denied access rights of any kind. The exception to this is the user defined in the Root DN parameter (see page 344 for a description of this 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.

Netscape Directory Server Deployment Manual.

When setting access control using the server manager, you specify whether to allow or deny access using the Action area. For more information, see "The Action Area" on page 96.

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. For more information, see "Setting Permissions Using LDIF" on page 122.

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. For more information, see "The Rights Area" on page 97.

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. For more information, see "Setting Permissions Using LDIF" on page 122.

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, during 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 bindDN 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 manger, you can define anonymous access by clicking Anyone (No Authentication) in the User/Group area. For more information, see "The Users/Groups Area" on page 96.

For information on setting anonymous access using LDIF, see "Using the userdn Keyword" on page 124.

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 manger, you can define general access by clicking Authenticated people only and All in the User/Group area. For more information, see "The Users/Groups Area" on page 96.

For information on setting up general access using LDIF, see "Using the userdn Keyword" on page 124.

User Access

uid=u*, o=airius.com

u

If you are setting access control using the server manger, you set user access using the UserDN(S) field in the Users/Groups area. For more information, see "The Users/Groups Area" on page 96.

For information on setting user access using LDIF, see "Using the userdn Keyword" on page 124.

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.

For more information about LDAP URLs, see

Appendix C, "LDAP URLs."

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 bindDN 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. For more information, see "The Users/Groups Area" on page 96.

For information on setting parent access using LDIF, see

"Using the userdn Keyword" on page 124

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 bindDN 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. For more information, see "The Users/Groups Area" on page 96.

For information on setting self access using LDIF, see

"Using the userdn Keyword" on page 124

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 manger, you can define specific groups using the GroupDN(s) field in the Users/Groups Area. For more information, "The Users/Groups Area" on page 96.

If you are setting access control using LDIF, see "Using the groupdn Keyword" on page 126 for information on setting group access.

Access Based on Attribute Value

You can set a bind rule such that the ACI will apply only if the bindDN 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 bindDN 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 manger, you can specify that the bindDN must match the DN in an attribute in the user entry by typing the attribute name in the UserDnAttr field. For more information, see "The Users/Groups Area" on page 96.

If you are setting access control using LDIF, see "Using the userdnattr Keyword" on page 127 for information on setting user DN attribute access.

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 manger, you can define specific machines to which the ACI applies using the From Host area. For more information, see "The From Host Area" on page 97.

If you are setting access control using LDIF, see "Using the ip Keyword" on page 127 and "Using the dns Keyword" on page 128 for information on defining machine-based access.

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. For more information, see

"The Extra Area" on page 97

"Using the timeofday Keyword" on page 128

"Using the dayofweek Keyword" on page 129

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). For more information on setting up SSL, see

"Managing SSL" on page 234

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. For more information, see "The Users/Groups Area" on page 96.

If you are using LDIF to set up access control, see "Using the authmethod Keyword" on page 129 for information on setting authentication-based bind rules.

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. For more information, see "The Extra Area" on page 97 and "Using Boolean Expressions in LDIF Bind Rules" on page 130.

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:

Using the Access Control Forms

You can define permissions for the directory using the Access Control forms. To access the Access Control forms:

Make sure the directory server is running.

From the directory server manager, go to the Access Control | Access Control Overview form.

Bind to the directory. You must enter the username and password of a privileged directory user, such as the directory manager, who has access to all ACI instructions that have been set for the directory.

After a pause while the ACL information is loaded, the Access Control Overview form is displayed.

This form displays the following information for each ACI:


Resource	Identifies the ACI's target. The resource, or target, is a directory entry to which the ACI applies, or one or more attributes to which the ACI applies, or both.
ACI Name	Descriptive name that you can give to each ACI to help you identify them. If you do not supply an ACI name, then Untitled is used by default.

To change or delete an existing ACI, click on the ACI's resource information or on its name. To create a new ACI, click on New ACI. Either way, a new browser window is opened to display the Access Control Rules form.

Using the Access Control Rules Form

The Access Control Rules form contains buttons, areas, and fields that allow you to target an entry and set the corresponding permissions and bind rules. After you set the target, permissions, and bind rules using the Access Control Rules form and its associated areas, you must save the new ACI.

Access Control Rules Form Buttons

The Access Control Rules form contains the following buttons:

New Line -- Provides an additional option line. For more information on the options area, see "Using the Options Area" on page 95.

Submit - Causes changes made to the ACI to be saved to the directory. For more information on saving changes to the directory, see "Applying Changes Made to the Access Control Rules Form" on page 98.

Revert -- Causes the Access Control Rules form to revert back to its original state when you first displayed it. This essentially provides you an undo for any changes you have made to the ACI since the last time you submitted changes to the directory.

Help -- Displays help on how to use the Access Control Rules form.

Show LDIF -- Provides a read-only display of the ACI in LDIF format.

Browse -- Allows you to browse the directory tree to select an entry to target. When browsing, you can press the Control or Shift keys while left-clicking your mouse to select multiple DNs.

Access Control Rules Form Areas

The Access Control Rules form consists of the following areas:

The top part of the screen is the options area. The options area provides links to forms that allow you to set actual access control. There is always at least one line representing an access control; however multiple lines are allowed. This area of the Access Control Rules form is described in "Using the Options Area" on page 95.

The bottom part of the form is the rules area. The rules area allows you to do three things.

Set a name for the ACI instruction you are creating. The name is optional; if you do not specify a name, "untitled" is used.

Set the target for the ACI. The target is required. For more information, see "Targets" on page 82.

Supply the bind DN and password to be used to log in to the directory and make the ACI changes. If the directory entry that you are writing to currently has no write permissions set for it, then you must use the root DN (unrestricted user) to set this permission.

For a description of each field in the rules Area, see

"Access Control Field Summary" on page 99

Using the Options Area

The options area is the top portion of the Access Control Rules form. The links in this area allow you to define the permissions and bind rules set by your ACI.

Each line in this area represents a unique permission/bind rule pair for the ACI. You can add a new line by clicking on the New Line button in the Access Control Rules form. You can delete a line by clicking on the trash can next to the line. If all the lines are deleted, then the ACI is deleted when the Access Control Rules form is submitted.

The options area has the following links:

Action -- Defines whether the ACI allows or denies the permission.

Users/Groups -- Defines the users and groups to which the ACI applies and the authentication methods that must be used when binding.

From Host -- Defines the hosts or IP addresses to which the ACI applies.

Rights -- Defines the type of rights (read, write, add, delete, search, selfwrite, and/or compare) that the ACI allows or denies.

Extra.... -- Allows you to view and edit the ACI bind rules.

Trash can -- Deletes the permission line. The line is deleted immediately.

With the exception of the trash can, when you click one of these links, an additional area is displayed at the bottom of the Access Control Rules form that is related to the link that you selected. The following sections describe these areas.

The Action Area. The Action area allows you to define whether the ACI is an allow or deny permission. An allow permission allows the access described by the ACI. A deny permission explicitly denies the access.

For more information on selecting an action, see "Allowing or Denying Access" on page 85. For a description of each field in the Action Area, see "Access Control Field Summary" on page 99.

Select either Allow or Deny, and then click Update. To save your changes, you must click Submit in the main part of the Access Control Rules form.

The Users/Groups Area. The Users/Groups area allows you to specify the user(s), group(s), or User DN attribute and the client authentication methods to which the permission applies. This dialog contributes to the bind rule portion of the ACI. If an ACI's bind rule is evaluated to be true, then the permission applies to the client directory request. For example, if a person binds to the directory using a User DN identified in this area, then the permission is either allowed or denied for them. Similarly, if a client binds to the directory using an authentication method selected in this area, then the permission is either allowed or denied for them.

For information on user and group definition options, see "User and Group Access" on page 88.

For information on specifying authentication methods, see "Access Based on Authentication Method" on page 92.

For a description of each field in the Users/Groups Area, see "Access Control Field Summary" on page 99.

Once you have made your changes to this area, click Update. To save your changes in the directory, you must click Submit in the main part of the Access Control Rules form.

The From Host Area. The From Hosts area allows you to specify the hosts to which the permission applies. This dialog contributes to the bind rule portion of the ACI. If an ACI's bind rule is evaluated to be true, then the permission applies to the client directory request. For example, if a person binds to the directory from a host identified in this area, then the permission is either allowed or denied for them.

For information on specifying hosts and IP addresses, see "Access from a Specific Machine or Domain" on page 91. For a description of each field in the From Host Area, see "Access Control Field Summary" on page 99.

Once you have made your changes to this area, click Update. To save your changes, you must click Submit in the main part of the Access Control Rules form.

The Rights Area. The Rights area allows you to specify the permission(s) that you are either allowing or denying.

For information on access rights, see "Assigning Rights" on page 86. For a description of each field in the Rights Area, see "Access Control Field Summary" on page 99.

Once you have made your changes to this area, click Update. To save your changes, you must click Submit in the main part of the Access Control Rules form.

The Extra Area. The directory server access control mechanism is extremely flexible. As a result, not every type of possible bind rule can be easily expressed using a graphical user interface. To compensate for this, the Extra area (or Customized Expressions) is provided to allow you to specify customized bind rules that cannot otherwise be expressed using the ACI GUI. Essentially, this area of the GUI allows you to provide the LDIF statement for the ACI's bind rule.

Some of the things that you can express using LDIF but that you cannot set using the ACI GUI are:

Not equal to (!=) expressions for user, groups, IP addresses, and hostnames.

Complex boolean constructions. For more information, see "Boolean Bind Rules" on page 92.

Bind rules based on the day of the week or the hour of the day. For more information, see "Access at a Specific Time of Day or Day of Week" on page 91.

Once you have made your changes to this area, click Update. To save your changes, you must click Submit in the main part of the Access Control Rules form.

For information on using LDIF to express bind rules, see "Setting Bind Rules Using LDIF" on page 123.

The Trash Can. Use the trash can to delete the permission line. The line is deleted immediately. If all the permission lines for a given ACI have been deleted, then the ACI is deleted from the directory when the changes are submitted using the Submit button.

If you accidentally delete a line, you can get it back by using the Revert button. However, be aware that all of the changes you made to the form since you originally displayed the ACI will also be lost.

Applying Changes Made to the Access Control Rules Form

After you have made your changes to the Access Control Rules form, do the following:

Make sure that a valid DN is entered in the Target field.

Make sure a valid bind DN is entered to the BindDN field.

Enter the appropriate password for the bind DN.

Click the Submit button. This button causes the server manager to bind to the directory using the supplied bind DN and password. If you have provided valid bind credentials, and you have write permissions for the specified target's ACI attribute, then the server manager will modify the directory as indicated by the entries on the Access Control Rules form. When the operation is completed, the server will display a message indicating that the operation was successful.

Access Control Field Summary

The following table lists and describes each field on the Access Control screens, and, where appropriate shows an example of its use. Required fields are identified as such, all other fields are optional.

Note
You cannot enter DNs that contain commas into any of the access control fields. To use DNs that contain commas within an ACI, you must create the ACI using LIDF. See "Setting Access Control Using LDIF Files" on page 116.

Table 5.1 Access Control field summary


Field	Description	Example
Access Control Rules Frame
Name	Identifies a name for the ACI for easier identification. Default is Untitled.	`anonymous`
Target	A required field that identifies the entry to which this ACI applies. This field must contain a valid DN.	`o=airius.com`
Attr	Identifies one or more attributes to which the ACI applies. To target more than one attribute, separate each attribute with double vertical bars (\|\|).	`userpassword \|\| telephonenumber`
Filter	Identifies a search filter to use to set the target.	`ou=accounting, ou=engineering`
BindDN	A required field that identifies the DN the server manager will use to bind (log in) to the directory so that the ACI changes can be made. This DN must have write permissions to the ACI attribute of the entry identified in the Target field. If the directory entry you are writing to currently has no write permissions set for it, then you must use the Root DN (unrestricted user).	`cn=administrators, o=airius.com`
Password	The bind DN's password.
Action Area
Allow	Click this radio button if you want the ACI to allow rights to the targeted entry or attribute.
Deny	Click this radio button if you want the ACI to explicitly deny rights to the targeted entry or attribute.
User/Group Area
Anyone	Click this radio button to enable anonymous access.
Authenticated people only	Click this radio button to disable anonymous access.
All	Click this radio button to enable access to all authenticated users. This is known as general access.
Only the following people	Click this radio button if you want to allow or deny access to a specific user or group of users.
GroupDn(s)	Requires one or more valid distinguished names in the format of <dn> [\|\|<dn>]...].	`cn=administrators, o=airius.com \|\| cn=mail administrators, o=airius.com`
UserDn(s)	Requires one or more valid distinguished names in the format of <dn>[\|\|<dn>] or a dynamic URL. The wildcard is supported.	`uid=bjensen, o=airius.com` or `uid=*, o=airius.com` or `ldap:///o=airius.com ??sub?(filter)`
UserDnAttr	Requires an attribute that is expected to contain a full distinguished name.	`manager`
None	No authentication is required for the ACI to apply.
Simple	Click this radio button to indicate that the ACI will only apply if the client binds using simple (username and password) authentication.
SSL	Click this radio button to indicate that the ACI will only apply if the client binds using an SSL connection.
SASL	Click this radio button to indicate that the ACI will only apply if the client binds using a SASL connection. If you click this radio button, you must also enter the SASL mechanism in the text box.	`Kerberos`
From Host Area
Anyplace	Click this radio button to indicate that the client can access the directory from any physical location. This is the default.
Only from	Click this radio button to indicate that the ACI will only apply if the client accesses the directory from a specific IP address or DNS domain or hostname.
Host Names	Enter the fully qualified DNS hostnames of the machines from which the bind must originate for the ACI to apply. Wildcards are allowed.	`abacus.airius.com` `or` `*.airius.com`
IP Addresses	Enter the IP addresses of the machines from which the bind must originate for the ACI to apply. Wildcards are allowed.	`123.45.6.78` `or` `123.45.` `or` `123..*.78`
Rights Area
All Access Rights	Click this radio button to allow or deny all rights to the targeted entry or attribute. For a list of access rights, see "Assigning Rights" on page 86.
Only the following Rights	Click this radio button to allow or deny only specific rights to the targeted entry or attribute. You must then check the desired rights. For a list of access rights, see "Assigning Rights" on page 86.

Setting Access Control Using the Server Manager

You can use the server manager to create, edit, delete the access control rules for your directory. Although the procedures you will perform will depend on the specific access control rules required for your organization based on the security policy you have developed, this section provides general procedures for:

Creating a New ACI

Editing an Existing ACI

Deleting an Existing ACI

In addition, the section entitled "Usage Examples" on page 106 provides a collection of some ACI rules that are commonly used in directory server security policies along with step-by-step instructions for using the server manager to create these standard ACIs.

Creating a New ACI

To create a new ACI, do the following:

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory. You must enter the username and password of a privileged directory user, such as the directory manager, who has access to all ACI instructions that have been set for the directory.

Click New ACI. The Access Control Rules form is displayed. For details on the Access Control Rules form, see "Using the Access Control Rules Form" on page 94.

Enter a name for the ACI. The name can be any string you want to use to uniquely identify the ACI. The name is optional.

Enter a target. This is required. The target must be a valid distinguished name. You can type the target DN or click Browse to select from a list of available DNs. You can use the default "is" to set a target that is equal to the DN you enter or select "is not" to set a target that is not equal to the DN you enter.

The DN you target cannot contain a comma as part of its value. If you want to target a DN that contains a comma, you must create your ACI using LIDF. See "Setting Access Control Using LDIF Files" on page 116.

Optionally enter an attribute to target in the Attr field or an LDAP search filter in the Filter field. You can use the default "is" to set a target attribute or filter that is equal to the value you enter or select "is not" to set a target attribute or filter that is not equal to the value you enter.

Go to Action. Select whether this is an allow or a deny permission. Click Update. For details on the Action area, see "The Action Area" on page 96.

Go to Users/Groups. Enter the users, groups, or user DN attributes, if any, that this permission is for. Click Update. For details on the Users/Groups area, see "The Users/Groups Area" on page 96.

Go to From Host. Enter the hosts, if any, that the permission is for. Click Update. For details on the From Host area, see "The From Host Area" on page 97.

Go to Rights. Select the set of access control permissions that you are allowing or denying. Click Update. For details on the Rights area, see "The Rights Area" on page 97.

Enter the bind DN and password.

Click Submit. The server displays a confirmation box.

Click OK. The new ACI is created.

Editing an Existing ACI

To edit an existing ACI, do the following:

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory. You must enter the username and password of a privileged directory user, such as the directory manager, who has access to all ACI instructions that have been set for the directory.

Click the ACI that you want to change. The Access Control Rules form is displayed for the ACI that you are editing. For details on the Access Control Rules form, see "Using the Access Control Rules Form" on page 94.

Make the desired changes to the various areas of the Access Control Rules form. Click Update as you are finished with each area.

Enter the bind DN and password.

When you are done editing the ACI, click Submit. The server displays a confirmation box.

Click OK. The ACI is modified.

Deleting an Existing ACI

To delete an existing ACI, do the following:

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory. You must enter the username and password of a privileged directory user, such as the directory manager, who has access to all ACI instructions that have been set for the directory.

Click on the ACI that you want to delete. The Access Control Rules form is displayed for the ACI that you are deleting.

Click the trash can at the end of the permissions/bind rules line (for details on the permissions/bind rules line, see "Using the Options Area" on page 95). If more than one line is shown, continue to click on the trash can until all of the lines are deleted.

Enter the bind DN and password.

Click Submit. The server will display a confirmation box.

Click OK. The ACI is deleted immediately. There is no undo.

Usage Examples

The following sections describe how to set some of the more common directory permissions.

Setting Anonymous Access for Read, Search, and Compare

Most directories are run such that you can anonymously access them for read, search, or compare. You can set this permission by doing the following:

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter the suffix value for your directory (for example: o=airius.com).

Go to Action. Click Allow and then Update.

Go to Rights. Click Read, Search, and Compare, and then click Update.

Optional step. In Name field, enter a unique value such as anonymous. In the future, this will allow you to see at a glance which of your access controls allows anonymous read and search.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

Allowing Users to Modify Their Own Directory Entries

Many directories allow users to change attribute values in their own entries. The following procedure shows you how to set this permission.

Note

By setting this permission, you are also granting users the right to delete attribute values.

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter the suffix value for your directory (for example: o=airius.com).

Go to Action. Click Allow and then Update.

Go to Users/Groups. In the UserDn(s) field, enter self. Then click Update.

Go to Rights. Click Write, and then Update.

Optional step. In the Name field, enter a unique value such as allow-self-write. In the future, this will allow you to see at a glance which of your access controls allows each user to write to their own entry.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

Allowing Users to Change Some of Their Own Attributes

Many directory administrators want to allow users to change some but not all of the attributes in their own entry. For example, you may want to allow a user to change his or her own password or telephone number, but nothing else. The following procedure shows you how to set this permission.

Note

By setting this permission, you are also granting users the right to delete attribute values.

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter the suffix value for your directory (for example: o=airius.com).

In the Attr field, enter userpassword || telephonenumber.

In the options area, beneath Action click Deny. In the resulting Action frame, click Allow and then Update.

Go to Users/Groups. In the UserDn(s) field, enter self. Then click Update.

Go to Rights. Click Write, and then click Update. This allows users to only write their own attributes. If you want the users to be able to read, search, or compare these attribute values, then make sure you set a separate permission to allow this. If you have setup anoymous search in your directory as described in "Setting Anonymous Access for Read, Search, and Compare" on page 106, then you do not have to create any further permissions.

Optional step. In the Name field, enter a unique value such as write pw and tel. In the future, this will allow you to see at a glance which of your access controls allows each user to write to their own entry.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

Granting a Group Full Directory Access

Most directories have a group that is used to identify directory administrators. This group of users is usually given full access to all or part of the directory. By applying the access rights to the group, you can avoid setting the access rights for each directory administrator individually. Instead, you grant users these access rights simply by adding them to the group.

The following procedure shows you how to grant the members of an administrators group full access to the directory.

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter the suffix value for your directory (for example: o=airius.com).

Go to Action. Click Allow and then Update.

Go to Users/Groups. In the GroupDn(s) field, enter cn=administrators, o=airius.com. Then click Update.

Optional step. In the Name field, enter a unique value such as admin all. In the future, this will allow you to see at a glance which of your access controls allows the administrators group full access to the directory.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

You have now set the permission that allows any members of the administrators group full privileges to the entire directory. You can create groups and add or delete members from the group using either the directory server gateway or the Users and Groups area of the administration server. See the online documentation that comes with these tools for information on how to manage groups.

Granting a Group Rights to Add and Delete Entries

Many directories have a group that is used to identify individuals who add and delete entries from the directory regularly, such as a Human Resources group that is responsible for adding and deleting employees from the directory. By applying access rights to the group, you can avoid setting the access for each group member individually. Instead, you grant users these access rights simply by adding them to the group.

The following procedure shows you how to grant the members of the HR administrators group add and delete access to the directory.

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter the suffix value for your directory (for example: o=airius.com).

Go to Action. Click Allow and then Update.

Go to Users/Groups. In the GroupDn(s) field, enter the group DN (for example, cn=HR administrators, o=airius.com). Then click Update.

Go to Rights. Click Add and Delete. Then click Update.

Optional step. In the Name field, enter a unique value such as HR-admin. In the future, this will allow you to see at a glance which of your access controls allows the HR administrators group access to the directory.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

You have now set the permission that allows any members of the HR administrators group privileges to add and delete entries from the directory. You can create groups and add or delete members from the group using either the directory server gateway or the Users and Groups area of the administration server. See the online documentation that comes with these tools for information on how to manage groups.

Allowing Full Access to a Specific Branch Point

One type of access control that is commonly used is to set up specific administrators of individual subdirectories. This allows you, for example, to have a group of people that are responsible for administering an Accounting subtree and another group of people that are responsible for administering a Marketing subtree.

The following procedure shows you how to allow a group called accounting administrators to have full directory access to the accounting subtree.

Note

ou=accounting, o=airius.com

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter the suffix value for your directory (for example: o=airius.com).

Go to Action. Click Allow and then Update.

Go to Users/Groups. In the GroupDn(s) field, enter cn=accounting administrators, ou=accounting, o=airius.com. Then click Update.

Optional step. In the Name field, enter a unique value such as acct admin all. In the future, this will allow you to see at a glance which of your access controls allows the accounting administrators group full access to the accounting subdirectory.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

You have now set the permission that allows any members of the accounting administrators group full read, write, search, and compare privileges to the accounting subdirectory. You can create groups, and add or delete members from the group using either the directory server gateway or the Users and Groups area of the administration server. See the online documentation that comes with these tools for information on how to manage groups.

Allowing Access at a Specific Time of Day or Day of Week

Many directories have "blackout" periods where users cannot write to the directory. Keep in mind that when setting up time-based access restrictions, it may be easier to manage an ACI that explicitly restricts time-based access rather than to search though the directory for all the allow for write ACIs and restricting their scopes to exclude access during the designated blackout period. The following example shows you how to set up access control so that all write access to the directory is denied between the hours of 11 pm Sunday and 1 am Monday.

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter the suffix value for your directory (for example: o=airius.com).

Go to Rights. Click Write and then Update.

Go to Extra. In the resulting Extra (or Customized Expressions) area, enter the following ACI bind rule statements:

(timeofday >= "2300") and (timeofday >= "0100") and (dayofweek = "Sun, Mon")

Optional step. In Name field, enter a unique value such as time/date. In the future, this will allow you to see at a glance which of your access controls restricts access to the directory based on the time of day and day of week.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

Allowing Updates Only from a Specific Location

Many directories restrict directory updates to clients running from a specific DNS hostname or IP address. This ensures that the directory cannot be updated unless the person has access to a specific machine. This type of update restriction is most common when you are populating your directory using some HR or accounting package, or by using some kind of LDAP gateway.

The following procedure shows you how to allow write access to the directory server running on accounting.airius.com tree only to clients running on the machine named abacus.airius.com.

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter the suffix value for the branch of the tree you want to allow access to (for example: ou=accounting, o=airius.com).

Go to Action. Click Allow and then Update.

Go to From Host. Click Only From. Then go to the Host Names field and enter abacus.airius.com. Then click Update.

Go to Rights. Click Write and then Update.

Optional step. In the Name field, enter a unique value such as updates from abacus. In the future, this will allow you to see at a glance which of your access controls allow updates from the machine named abacus.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

Allowing Access Over SSL Only

There may be times that you want the directory data that is being read or updated to be encrypted so that it cannot be captured or tampered with. This will often be the case if you are allowing updates to your directory from outside your firewall. For example, the directory administrator may want to be able to update or query the directory from home sometimes.

The following procedure shows you how to allow access from a machine 123.45.6.78 outside the Airius firewall only if the user binds to the directory using a Secure Sockets Layer (SSL) connection.

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter the suffix value for your directory (for example: o=airius.com).

Go to Action. Click Allow and then Update.

Go to From Host. Click Only From and then go to the IP Addresses field and enter 123.45.6.78. Then click Update.

Go to Users/Groups. Click all. Also, click SSL in the Authentication methods area. Then click Update.

Optional step. In the Name field, enter a unique value such as SSL. In the future, this will allow you to see at a glance which of your access controls require binding over an SSL connection for access to the directory.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

Setting a Target Using Filtering

If you want to set access controls that allow access to a number of entries that are spread across the directory, you may want to use a filter to set the target. Keep in mind that 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.

The following procedure shows you how to grant user bjensen write access to the department number, home phone number, home postal address, JPEG photo, and manager attributes for all members of the accounting organization.

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter the suffix value for your directory (for example: o=airius.com).

In the rules area go to the Attr field, and enter
departmentNumber || home* || jpegPhoto || Manager.

In the Filter field, enter ou=accounting.

Go to Action. Click Allow and then Update.

Go to Rights. Click Write and then Update.

Go to Users/Groups. In the UserDn(s) field, enter uid=bjensen, o=airius.com. Then click Update.

Optional step. In the Name field, enter a unique value such as accounting filter. In the future, this will allow you to see at a glance which of your access controls uses filtering to allow access to the accounting branch of the directory.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

Allowing Users to Add or Remove Themselves from a Group

Many directories set ACIs that allow users to add or remove themselves from groups. This is useful, for example, for allowing users to add and remove themselves from mailing lists.

The following example allows anyone to add or delete themselves from the Jokes group.

In the directory server manager, go to Access Control | Access Control Overview.

Bind to the directory.

Click New ACI.

In the Target field, enter cn=jokes, ou=Mail Server, o=airius.com.

Go to Action. Click Allow and then Update.

Go to Users/Groups. Click All. Then click Update.

Go to Rights. Click Selfwrite, and then click Update.

Optional step. In the Name field, enter a unique value such as selfwrite jokes. In the future, this will allow you to see at a glance which of your access controls allows each user to write to their own entry.

Make sure the BindDN and Password fields are filled out correctly, and then click Submit.

Setting Access Control Using LDIF Files

Access control information is stored in the ACI attribute of each directory entry. Because the access control information is stored in the directory, it can be managed using LDIF files. For a general description of the LDIF language, see Chapter 2, "LDAP Data Interchange Format."

The ACI attribute is an operational attribute; that is, it is available for use on every entry in the directory, regardless of whether it is defined for the object class structure in use on the entry.

The following sections describe the ACI language syntax. It is important to understand this syntax if you are going to use LDIF to manipulate access control permissions.

Tip

LDIF ACI statements can be very complex. However, if you are setting access control for a large number of directory entries, using LDIF is the preferred method over using the GUI because of the time it can save. To familiarize yourself with LDIF ACI statements, however, you may want to use the server manager to set the ACI and then click the Show LDIF button on the Access Control Rules form. This will show you the correct LDIF syntax. If your operating system allows, you can even copy the LDIF to the clipboard and then paste it into your LDIF file.

The ACI Language Syntax

ACIs take the form


	aci: (<target>)(version 3.0;acl"<name>";<permission><bind rule>;)

where:

<target> defines the object, attribute, or filter you are using to define what resource to controlling access to. The target can be a distinguished name, one or more attributes, and/or a single LDAP filter. For general information on targets, see "Targets" on page 82. For information on target syntax, see "Setting Targets Using LDIF" on page 118.

version 3.0 is a required string that identifies the ACL version.

acl "<name>" is a name for the ACI. <name> can be any string that identifies the ACI. The ACI name is required.

<permission> defines the actual access rights and whether they are to be allowed or denied. For general information on permissions, see "Permissions" on page 85. For information on the permission syntax, see "Setting Permissions Using LDIF" on page 122.

<bind rules> identify the circumstances under which the directory log in must occur in order for the ACI to take effect. For general information on bind rules, see "Bind Rules" on page 87. For information on bind rule syntax, see "Setting Bind Rules Using LDIF" on page 123.


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

ACIs are order independent with regard to the (<target>) and (<permission><bind rule>) parts of the ACI.

The following is an example of a complete LDIF ACI instruction:


aci: (target="ldap:///uid=bjensen,o=airius.com")(targetattr=*)
(version 3.0;acl "acl1";allow (write) userdn="ldap:///self";)

In this example, the ACI rule named acl1 states that the user bjensen has rights to modify all attributes in her own directory entry.

The following sections describe the syntax of each portion of the ACI in more detail.

Setting Targets Using LDIF

Targeting indicates which directory resources the ACI rule apply to. For general information on targeting, see "Targets" on page 82.

The general syntax for a target is:


aci: (<keyword> = "<expression>")


aci: (<keyword> != "<expression>")

where equal (=) indicates that the target is the resource specified in the <expression>, and not equal (!=) indicates the target is not the resource specified in the <expression>.

The quotation marks ("") around <expression> are required. What you use for <expression> is dependent upon the exact <keyword> that you supply.

The following table lists each keyword and the associated expressions.

Table 5.2 LDIF Target keywords


Keyword	Valid Expressions	Wildcard allowed?
`target`	`ldap:///<distinguished name>`	yes
`targetattr`	`<attribute>`	yes
`targetfilter`	`<LDAP search filter>`	yes

The following sections further detail the target syntax for each keyword.

Using the target Keyword

To target an entry, use the target keyword. The target keyword can accept a value of the following format:


	"ldap:///<distinguished name>"

This identifies the distinguished name of the entry to which the access control rule applies. For example:


	(target = "ldap:///uid=bjensen, o=airius.com")

Note

If the DN of the entry to which the access control rule applies contains a comma, you must escape the comma with two backslashes (\\). For example:


	(target = "ldap:///uid=lfuentes, o=Airius Bolivia\\, S.A.")

You can also use a wildcard when targeting a distinguished name using the target keyword. The wildcard indicates that any character or string or substring is a match for the wildcard. Pattern matching is based on any other strings that have been specified with the wildcard. The following are legal examples of wildcard usage:

(target="ldap:///uid=*, o=airius.com")

Matches every distinguished name in the Airius tree that begins with uid.

(target="ldap:///uid=*Anderson, o=airius.com")

Matches every distinguished name who's uid ends with Anderson.

(target="ldap:///uid=C*A, o=airius.com")

Matches every distinguished name who's uid begins with C and ends with A.

(target="ldap:///uid=*, o=*, o=airius.com")

Matches every entry in the Airius tree whose distinguished name contains the uid and o attributes. Thus:


		uid=fchen, ou=Engineering, o=airius.com


would match, but:



		uid=bjensen, o=airius.com
		ou=Engineering, o=airius.com


would not.

Note

You cannot use wildcards in the suffix part of a distinguished name. That is, if your directory uses the suffixes


	c=US

and


	c=GB

not


	(target="ldap:///o=airius, c=*")

For more information on using the target keyword, see "Targeting a Directory Entry" on page 83.

Using the targetattr Keyword

You can target a specific attribute by using the targetattr keyword. For example:


	(targetattr = "cn")

The attribute identified on the targetattr keyword applies to the entry that the ACI is targeting, and to all that entry's child entries. That is, if you target the password attribute on the entry:


	uid=bjensen, ou=Marketing, o=airius.com

then only the password attribute on the bjensen entry is affected by the ACI. If however, you target the tree's branch point:


	ou=Marketing, o=airius.com

then all the entries beneath the branch point that can contain a password attribute are affected by the ACI.

For general information on targeting attributes, see "Targeting Attributes" on page 83.

Targeting Multiple Attributes

You can use the ACI's resource information to target multiple attributes by using the targetattr keyword along with the || symbol. For example, to target an entry's common name, surname, and uid attributes, use the following:


	(targetattr = "cn || sn || uid")

Targeting Both an Entry and Attributes

By default, the entry that is targeted by ACI containing a targetattr keyword is the entry on which the ACI is placed. That is, if you put the ACI:


	aci: 	 (targetattr = "uid")(<access control rules>;)

on the ou=Marketing, o=airius.com entry, then the ACI applies to the entire Marketing subtree. However, you can also explicitly specify a target using the target keyword as follows:


	aci: 	 (target="ldap:///ou=Marketing, o=airius.com")
	 (targetattr = "uid")(<access control rules>;)

The order in which you specify the target, the targetattr and the access control rules is not important. Also, the entry you target using the target keyword must reside within the domain controlled by the entry on which the ACI is supplied. For more information on using the target keyword, see "Using the target Keyword" on page 119.

Using the targetfilter Keyword

You can target a group of entries and/or attributes using an LDAP search filter and the targetfilter keyword. For example:


	(targetfilter = "<search operation>")

where <search operation> is a search operation in the standard LDAP search filter format. For information on the syntax of LDAP searches, see Chapter 8, "Finding Directory Entries."

For example,


	(targetfilter = "(|(ou=accounting)(ou=engineering))"

would target all entries in the accounting and engineering branches of the directory tree.

For more information on targeting using LDAP filters, see "Targeting using LDAP Filters" on page 84.

Setting Permissions Using LDIF

Permissions indicate whether a specified right is allowed or denied. Whether the defined permission is allowed or denied is determined by whether the accompanying bind rule is evaluated to be true. For general information on permissions, see "Permissions" on page 85.

ACI Permissions take the form


	allow|deny (<rights>)

where

allow|deny can be either the allow keyword or the deny keyword. Just as they suggest, allow grants the user the permission, and deny forbids the user the permission. For more information on allowing or denying access, see "Allowing or Denying Access" on page 85.

<rights> is a list of 1 to 7 comma-separated keywords enclosed within parentheses. Valid keywords are read, write, add, delete, selfwrite, search, compare, or all. For a description of each access right, see "Assigning Rights" on page 86.

In the following example, read, search, and compare access is allowed provided the bind rule is evaluated to be true:


	aci: 	 (target="ldap:///o=airius.com") (version 3.0;acl "acl2";
	 allow (read, search, compare) <bind rule>;)

Setting Bind Rules Using LDIF

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>";

Note

timeofday

The quotation marks ("") around <expression> are required as is the delimiting semicolon (;). What you use for <expression> is dependent upon the exact <keyword> that you supply.

The following table lists each keyword and the associated expressions, and indicates whether wildcard characters are allowed.

Table 5.3 LDIF bind rule keywords


Keyword	Valid expressions	Wildcard allowed?
`userdn`	`ldap:///<DN>` `ldap:///all` `ldap:///anyone` `ldap:///self` `ldap:///parent` `ldap:///<suffix>??sub?(filter)`	yes, in DN only
`groupdn`	`ldap:///<DN> \|\| <DN>`	no
`userdnattr`	`<attribute>`	no
`ip`	`<IP address>`	yes
`dns`	`<DNS host name>`	yes
`dayofweek`	`sun` `mon` `tue` `wed` `thu` `fri` `sat` `sun`	no
`timeofday`	`0 - 2359`	no
`authmethod`	`none` `simple` `ssl` `sasl <authentication method>`	no

The following sections further detail the bind rule syntax for each keyword.

Using the userdn Keyword

The userdn keyword requires one or more valid distinguished names in the format of ldap:///<dn>[||ldap:///<dn>]...], the keyword ldap:///self, ldap:///all, or ldap:///anyone. For general information about user access, see "User Access" on page 89.

Note

If a DN contains a comma, the comma must be escaped by a backslash (\).

The following are examples of the userdn syntax:


userdn = "ldap:///uid=*, o=airius.com";
The bind rule is evaluated to be true if the user binds to the directory using any distinguished name of the supplied pattern. For example, both of the following bind DNs would be evaluated as true: `uid=ssarette, o=airius.com uid=bjensen, o=airius.com` whereas both of the following bind DNs would be evaluated as false: `cn=Babs Jensen, o=airius.com uid=tjaz, ou=Accounting, o=airius.com`
userdn = "ldap:///self";
The bind rule is evaluated to be true if the user is accessing the entry represented by the DN that the user has bound to the directory as. That is, if the user has bound as `uid=ssarette, o=airius.com` and the user is attempting an operation on the uid=ssarette entry, then the bind rule is true.
userdn = "ldap:///all";
The bind rule is evaluated to be true for any valid bind DN. To be true, a valid distinguished name and password must have been presented by the user during the bind operation.
userdn = "ldap:///anyone";
The bind rule is evaluated to be true for anyone; use this keyword to provide anonymous access to your directory.
userdn = "ldap:///uid=bjensen, o=airius.com \|\| ldap:///uid=rsweeny, o=airius.com";
The bind rule is evaluated to be true if the client binds as either of the two supplied distinguished names.
userdn != "ldap:///uid=*, ou=Accounting, o=airius.com";
The bind rule is evaluated to be true if the client is not binding as a UID-based distinguished name in the accounting subtree. Keep in mind that this bind rule only makes sense if the targeted entry is above the accounting branch of the directory tree.
userdn = "ldap:///o=airius.com???(ou=engineering)(ou=sales)";
The bind rule is evaluated to be true if the client belongs to the engineering or sales subtree.

Using the groupdn Keyword

The groupdn keyword requires one or more valid distinguished names in the format of ldap:///<dn> [|| ldap:///<dn> [|| ldap:///<dn>]...]. The bind rule is evaluated to be true if the bind DN belongs to the named group. For general information about group access, see "Group Access" on page 90.

Note

If a DN contains a comma, the comma must be escaped by a backslash (\).

The following are examples of the groupdn syntax:


groupdn = "ldap:///cn=Administrators, o=airius.com";
The bind rule is evaluated to be true if the bind DN belongs to the Administrators group.
groupdn = "ldap:///cn=Administrators, o=airius.com" \|\| "ldap:///cn=Mail Administrators, o=airius.com";
The bind rule is evaluated to be true if the bind DN belongs to either the Administrators or the Mail Administrators group.

Using the userdnattr Keyword

The userdnattr keyword requires an attribute that is expected to contain a full distinguished name. Examples would be the manager or secretary attributes. For general information about user attribute access, see "Access Based on Attribute Value" on page 90.

The following are examples of the userdnattr syntax:


userdnattr = "manager";
The bind rule is evaluated to be true if the bind DN is the same as the value set for the manager attribute of the targeted entry. This is useful for, for example, allowing a user's manager to manage employees' password attribute.

Using the ip Keyword

ip

ip = "<IP address>" or ip != "<IP address>"

Wildcards are allowed. For example:


ip = "12.345.6.*";
The bind rule is evaluated to be true if the client accessing the directory is located at the named IP address. This is useful for, for example, allowing certain kinds of directory access only from a specific subnet or machine.

Using the dns Keyword

dns

dns = "<DNS Hostname>" or dns != "<DNS Hostname>"

Wildcards are allowed. For example:


dns = "*.airius.com";
The bind rule is evaluated to be true if the client accessing the directory is located in the named domain. This is useful for, for example, allowing certain kinds of directory access only from a specific domain.

Using the timeofday Keyword

timeofday

timeofday <operator> "<time>"

where <operator> is equal to (=), not equal to (!=), greater than (>), greater than or equal to (>=), less than (<), or less than or equal to (<=).

Note

The time on the server is used for the evaluation, and not the time of the client. For example:


timeofday = "1200";
The bind rule is evaluated to be true if the client is accessing the directory at noon.
timeofday != "1200";
The bind rule is evaluated to be true if the client is accessing the directory at any time other than noon.
timeofday > "1200";
The bind rule is evaluated to be true if the client is accessing the directory at any time after noon.
timeofday < "1200";
The bind rule is evaluated to be true if the client is accessing the directory at any time before noon.
timeofday >= "1200";
The bind rule is evaluated to be true if the client is accessing the directory at noon or later.
timeofday <= "1200";
The bind rule is evaluated to be true if the client is accessing the directory at noon or earlier.

Using the dayofweek Keyword

The LDIF syntax for setting a bind rule based on the day of the week is as follows:

dayofweek = "<day>"

where <day> is one of the following: Sun, Mon, Tue, Wed, Thu, Fri, Sat. A list of values is allowed.

Note

The day on the server is used for the evaluation, and not the day on the client. For example:


dayofweek = "Sun, Mon, Tue";
The bind rule is evaluated to be true if the client is accessing the directory on Sunday, Monday, or Tuesday.

Using the authmethod Keyword

The LDIF syntax for setting a bind rule based on authentication method is as follows:

authmethod = "<authentication method>"

where <authentication method> is "none", "simple", "ssl", or "sasl <sasl mechanism>".

For example,


authmethod = "none";
Authentication is not checked during bind rule evaluation.
authmethod = "simple";
The bind rule is evaluated to be true if the client is accessing the directory using a username and password.
authmethod = "ssl";
The bind rule is evaluated to be true if the client is accessing the directory using ldaps.
authmethod = "sasl kerberos";
The bind rule is evaluated to be true if the client is accessing the directory using the Kerberos SASL mechanism. The SASL mechanisms such as Kerberos are not provided as part of the directory server. For information on integrating SASL with the directory server, see the Netscape Directory Server Programmer's Manual.

Using Boolean Expressions in LDIF Bind Rules

Bind rules can be complex expressions that use the boolean expressions AND, OR, and NOT.

The general format for a Boolean bind rule is as follows:


	<bind rule> [<boolean>][<bind rule>][<boolean>][<bind rule>]...;)

For example, the following bind rule will be evaluated as true if the bind DN is a member of either the administrator's group or the mail administrator's group, and if the client is running from within the Airius domain:


(groupdn = "ldap:///cn=administrators, o=airius.com" or groupdn = "ldap:///cn=mail administrators, o=airius.com") and dns = "*.airius.com";)

Note the trailing semicolon (;) is a required delimiter that must appear after the final bind rule.

ACI Usage Examples

The following sections provide examples of setting ACIs using LDIF.

Defining Permissions for All Users

The following example allows all users at Airius to read access to the directory. In the following examples, users must authenticate to the directory server to obtain access to the directory granted by this ACI:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target = "ldap:///o=airius.com") (targetattr=*)
(version 3.0; acl "all-read"; allow (read) userdn = "ldap:///all";)

The following example allows every user write privileges only to their own userPassword attribute:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (targetattr = "userPassword")
(version 3.0; acl "write-self"; allow (write) userdn = "ldap:///self";)

The following example allows every user to read every attribute except the userPassword attribute:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target = "ldap:///o=airius.com")(targetattr != "userPassword")
(version 3.0; acl "read-all-not-pw"; allow (read) userdn = "ldap:///all";)

Defining Anonymous Access

Anonymous access allows users to gain access to the directory by providing no authentication information to the directory server. You grant anonymous access to an entry by specifying no client request attributes in the ACL.

The following example allows anonymous read and search access to every entry in the directory:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///o=airius.com")(targetattr=*)
(version 3.0; acl "anonymous-read-search"; allow (read, search)
userdn = "ldap:///anyone";)

The following example allows anonymous read or search access to the Marketing subtree:


dn: ou=Marketing, o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///ou=Marketing, o=airius.com")(targetattr=*)
(version 3.0; acl "anonymous-search-mktg"; allow (read, search)
userdn = "ldap:///anyone";)

Defining Permissions for Individual Users

The following example allows a specific user read or search access to the Marketing subtree. The user will be required to authenticate before obtaining access to the directory:


dn: ou=Marketing, o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///ou=Marketing, o=airius.com")(targetattr=*)
(version 3.0; acl "bjensen-r-s-mktg"; allow (read, search)
userdn = "ldap:///uid=bjensen, ou=Marketing, o=airius.com";)

The following example allows a specific user write access to the userPassword or telephoneNumber attribute of his own entry:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (targetattr = "userpassword || telephonenumber")
(version 3.0; acl "ssarette-write-pw-phone"; allow (write)
userdn = "ldap:///uid=ssarette, o=airius.com";)

The following example allows either of the two users to write to the administrator's group. That is, both of these users can add and delete group members to the administrator's group or change attribute values for the group entry:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target = "ldap:///cn=administrators,o=airius.com") (targetattr="member||uniquemember")(version 3.0; acl "write-admingrp"; allow (write)userdn = "ldap:///uid=ssarette, o=airius.com" ||
"ldap:///uid=bjensen, o=airius.com";)

The following example allows anyone to add or delete themselves from the Jokes group. This is useful, for example, for allowing users to add and remove themselves from mailing lists:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target = "ldap:///cn=jokes, ou=Mail Server, o=airius.com")
(targetattr="member")(version 3.0; acl "selfwrite-jokes"; allow (selfwrite)userdn = "ldap:///all";)

The following example allows users to write access to the description and jpegPhoto attributes of their own entries:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (targetattr = "description || jpegPhoto")(version 3.0; acl 
"write-jpeg-descrip-self"; allow (write) userdn = "ldap:///self";)

The following example allows the user to add and delete directory entries. Note, however, that because the ACI does not grant write permission, the user cannot modify the entry even if he created it himself.


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target = "ldap:///o=airius.com")(version 3.0; acl 
"landrew-add-delete"; allow (add, delete) userdn = "ldap:///uid=landrew, o=airius.com";)

The following example allows the user to write to his own child entries:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target = "ldap:///o=airius.com")(targetattr=*)(version 3.0; acl "ssarette-parent"; allow (write) userdn = "ldap:///parent";)

Defining Permissions for a Group of Users

The following example allows a group of users called Administrators to write to the entire contents of the directory:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///o=airius.com")(targetattr=*)
(version 3.0; acl "Administrators-write"; allow (write) groupdn =
"ldap:///cn=Administrators, o=airius.com";)

The following example allows anyone who is in the Directory Administrator group and not in the Content Administrators group to write to the uid attribute of any entry in the directory:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (targetattr= "uid")
(version 3.0; acl "diradmins-write-UID"; allow (write) 
groupdn = "ldap:///cn= Directory Administrators, o=airius.com" and groupdn != "ldap:///cn = Content Administrators, o=airius.com";)

The following example grants a manager full access to his or her employee's entries. In order for this to work, the manager attribute on each of the employee's entries must be set to the manager's distinguished name:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///o=airius.com")(targetattr=*)
(version 3.0; acl "manager-write"; allow (all) userdnattr = "manager";)

The following example allows members of the HR group to add new entries to and delete entries from the people organizational unit:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///ou=people, o=airius.com")
(version 3.0; acl "HR-add-delete"; allow (add, delete) groupdn =
"ldap:///cn=HR, o=airius.com";)

The following example allows members of the Engineering admins group to modify the homePhone, homePostalAddress, and manager attributes of all entries in the Engineering business category. This example uses LDAP filtering to select all entries with businessCategory attributes set to Engineering.


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (targetattr="departmentNumber || home* || Manager")
(targetfilter="businessCategory=Engineering")
(version 3.0; acl "eng-admins-write"; allow (write)
groupdn ="ldap:///cn=Engineering Admins, o=airius.com";)

Defining Permissions for a Specific Subtree

The following example allows a client to bind as the accounting organizational unit entry, and then have full access to all the entries beneath the accounting subtree:


dn: ou=Accounting, o=airius.com
objectClass: top
objectClass: organizationalUnit
userPassword: {crypt}dksfjaoewirsdkfj
ACI: (target="ldap:///ou=Accounting, o=airius.com")(targetattr=*)
(version 3.0; acl "accounting-branch"; allow (all)
userdn = "ldap:///ou=Accounting, o=airius.com";)

The following example allows any member of the accounting subtree to add themselves to or delete themselves from the Bean Counters group:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///cn=Bean Counters, ou=Accounting, o=airius.com") (targetattr="member")(version 3.0; acl "selfwrite-beancounters"; allow (selfwrite)userdn = "ldap:///uid=*, ou=Accounting, o=airius.com";)

Defining Permissions for a Specific Location

The following example allows a client running on the machine ldap.airius.com full access to the directory:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///o=airius.com")(targetattr=*)
(version 3.0; acl "acl 2"; allow (all) dns = "ldap.airius.com";)

The following example allows anonymous searching of the directory as long as the client is running on the specified subnet:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///o=airius.com")(targetattr=*)
(version 3.0; acl "acl 2"; allow (read, search)
userdn = "ldap:///anyone" and ip = "2.3.1.*";)

Defining Permissions Based on the Day of Week or the Time of Day

The following example denies all access to everyone except the Directory Administrator's group from 1:00 am to 3:00 am (0100 to 0300) on Sunday, Tuesday, and Friday:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///o=airius.com")(targetattr=*)
(version 3.0; acl "acl 1"; allow (all)
groupdn = "ldap:///cn=Directory Administrators, o=airius.com";)
ACI: (target="ldap:///o=airius.com")(targetattr=*)
(version 3.0; acl "acl 2"; deny (all)
groupdn != "ldap:///cn=Directory Administrators, o=airius.com" and dayofweek = "Sun, Tues, Fri" and
(timeofday >= "0100" and timeofday <= "0300");)

Defining Permissions Based on Authentication Method

The following example allows members of the Directory Administrators group full access to the directory provided that they bind to the directory using the Simple Authentication and Security Layer (SASL) protocol:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///o=airius.com")(targetattr=*)
(version 3.0; acl "acl 2"; allow (all)
groupdn = "ldap:///cn=Directory Administrators, o=airius.com" and
authmethod = "sasl kerberos";)

The following example allows read and write access from the machine named mastermind.airius.com if the bind is established using a Secure Sockets Layer (SSL) connection:


dn: o=airius.com
objectClass: top
objectClass: organization
ACI: (target="ldap:///o=airius.com")(targetattr=*)
(version 3.0; acl "acl 1"; allow (read, write)
dns = "mastermind.airius.com" and authmethod = "ssl";)

Defining Permissions for DNs That Contain a Comma

DNs that contain commas require special treatement within your LDIF ACI statements. In the target portion of the ACI statement, commas must be escaped by two backslashes (\\). Within the bind rule portion of the ACI, commas must be escaped by a single backslash (\). The following example illustrates this syntax.


dn: o=Airius Bolivia\, S.A.
objectClass: top
objectClass: organization
ACI: (target="ldap:///o=Airius Bolivia\\, S.A.")(targetattr=*)
(version 3.0; acl "acl 2"; allow (all)
groupdn = "ldap:///cn=Directory Administrators, o=Airius Bolivia\, S.A.";)

Museum

Managing Access Control

Understanding Access Control

Targets

Targeting a Directory Entry

Targeting Attributes

Targeting using LDAP Filters

Permissions

Allowing or Denying Access

User and Group Access

Anonymous Access

Group Access

Access Based on Authentication Method

Using the Access Control Forms

Using the Access Control Rules Form

Access Control Rules Form Areas

Using the Options Area

Applying Changes Made to the Access Control Rules Form

Setting Anonymous Access for Read, Search, and Compare

Granting a Group Rights to Add and Delete Entries

Allowing Full Access to a Specific Branch Point

Allowing Access at a Specific Time of Day or Day of Week

The ACI Language Syntax

Setting Targets Using LDIF

Using the target Keyword

Targeting Both an Entry and Attributes

Setting Bind Rules Using LDIF

Using the userdn Keyword

ACI Usage Examples

Defining Permissions for All Users

Defining Anonymous Access

Defining Permissions for Individual Users

Defining Permissions for a Group of Users

Defining Permissions for a Specific Subtree

Defining Permissions for a Specific Location

Defining Permissions Based on the Day of Week or the Time of Day

Defining Permissions Based on Authentication Method

Defining Permissions for DNs That Contain a Comma