Directory-Specific Access Control Implementation

All three supported directories (that is, DirX, OpenLDAP, and iPlanet) have complex mechanisms for controlling access, depending on the user bound to the directory.

DirX stores the access control lists in subentries that conforms to the X.500 standard. The access control subentries are created by using the DirX DAP client dirxcp. These access control subentries are replicated in a shadowing scenario.

OpenLDAP defines the access control list statically within the LDAP server configuration file umc.slapd.conf. In the case of replication, the access control lists must be copied manually into the configuration file of the slave directory.

IPlanet/Netscape Directory 4.13 stores the access control lists in the directory. IPlanet/Netscape Directory 4.13 extends the standard object class top by the optional attribute aci that is used to store the access control lists. This means that the aci information can be added through the LDAP protocol. The aci values are replicated to the slave directory.

DirX

DirX access control information is stored in subentries that are from the type subentry and acceSDXontrolSubentry. These subentries include the information about the target (that is, what is controlled), precedence (that is, higher precedence overwrites lower precedence), and the access control information (that is, prescriptive ACI) that includes the user class (that is, who is affected by the control parameters) and the permissions on entry and attribute level.

Access control subentries can contain many prescriptive ACIs with a list of one or more items to be protected, such as entries and sets of operation or user attributes.

The UMCdirxa package includes a tcl-file, called acldefs.tcl, that defines the following variables for the permissions:

• DAER—Deny read access on entry level
• AER—Grant read access on entry level
• AEM—Grant full access on entry level
• AEME—Grant modify access on entry level
• DAAR—Deny read access on attribute level
• AAR—Grant read rights on attribute level
• AAM—Grant modify rights on attribute level

The UMCdirxa package includes the file access.cp that sets the access controls for the SDX software.

Figure 29 shows a tcl-script with an explanation of the various parts.

Figure 29: Creation of an Access Control Subentry Example in DirX

OpenLDAP

The OpenLDAP access controls are configured in the LDAP server configuration file umc.slapd.conf. The precedence of the access controls is governed by the order of appearance of the access control list in the umc.slapd.conf file. Whenever the target of the user class is fulfilled, OpenLDAP ignores the remaining access control entries. Many user classes can be added to an access control list for a target.

NOTE: OpenLDAP requires write access to a parent to create a new entry.

Because of this requirement, OpenLDAP requires more than one access control definition to implement the same access rights as in the DirX example.

Figure 30 shows a umc.slapd.conf with an explanation of the various parts.

Figure 30: Creation of an Access Control List Example in OpenLDAP

Netscape / iPlanet Directory Server

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.

ACIs take the following form:

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

where

<target> defines the object, attribute or filter you are using to define what resource to control access to. The target can be a distinguished name, one or more attributes, and or a single LDAP filter

version 3.0 is a required string that identifies the CAI version

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

<bind rules> identify the circumstances under which the directory login must occur for the ACI to take effect.

The UMCiDSa package includes the LDIF file (that is, access.ldif) that implements the SDX access control scheme.

Figure 31 shows the LDIF file for implementing the same kind of access level as previously depicted with an iPlanet/Netscape 4.13 directory.

Figure 31: Creation of Access Control List Example in iPlanet DS 4.13

Assigning Operators to an Operator Group

To add operators to an operator group:

1. Click on the operator group in the navigation pane.

The Operator Group pane appears.

2. Click the icon.

The Select Object dialog box appears.

3. Use the tools in the navigation bar to view the operators for this enterprise.
4. Highlight an operator, and click OK.
5. Click Add in the Main tab of the Operator Group pane.

Deleting Operators from an Operator Group

To delete an operator from an operator group:

1. In the Main tab of the Operator Group pane, select the operator in the Members field.
2. Right-click, and select Delete.