The Directory Server Access Control Model
Access Control and Replication
To Target an Entry and Attributes
To Target Entries or Attributes Using LDAP Filters
To Target Attribute Values Using LDAP Filters
To Target a Single Directory Entry
To Specify the Scope of an ACI
To Target LDAP Extended Operations
Rights Required for LDAP Operations
Defining User Access (userdn Keyword)
Defining General Access (all Keyword)
Defining Anonymous Access (anyone Keyword)
Defining Self Access (self Keyword)
Defining Parent Access (parent Keyword)
Specifying Users With LDAP URLs
Specifying Users With Wildcards
Specifying Users With a Logical OR of LDAP URLs
Defining Group Access (groupdn Keyword)
Specifying a Group With a Single LDAP URL
Specifying a Group With a Logical OR of LDAP URLs
Defining Access Based on Value Matching (userattr Keyword)
Defining Access From a Specific IP Address (ip Keyword)
Defining Access From a Specific Domain (dns Keyword)
Defining Access at a Specific Time of Day or Day of Week (timeofday and dayofweek Keywords)
Defining Access Based on Authentication Method (authmethod Keyword)
Authentication Method Examples
Defining Access Based on a Connection's Security Strength Factor (ssf Keyword)
DIGEST-MD5 QOP Key Size Mapping
Compatibility With the Sun Java System Directory Server Access Control Model
All Attributes targetattr Rule (targetattr="*")
Distinguished Name (DN) Wildcard Matching
Understanding the Directory Server Schema
Understanding Directory Server Plug-Ins
The aci attribute has the following syntax:
aci: (target)(version 3.0;acl "name";permissionBindRules;)
where:
target specifies the entry, attributes, or set of entries and attributes for which you want to control access. The target can be a distinguished name, one or more attributes, or a single LDAP filter. The target is optional. When the target is not specified, the ACI applies to the entire entry where it is defined and all of its children.
version 3.0 is a required string that identifies the ACI version.
name is a name for the ACI. The name can be any string that identifies the ACI. The ACI name is required and should describe the effect of the ACI. Although there are no restrictions on the name, it is good practice to use unique names for ACIs. If you use unique names, the Get Effective Rights control enables you to determine which ACI is in force.
permission specifically states what rights you are either allowing or denying, for example read or search rights.
bindRules specify the credentials and bind parameters that a user has to provide to be granted access. Bind rules can also be based on user or group membership or connection properties of the client.
You can specify multiple targets and permission-bind rule pairs. This allows you to refine both the entry and attributes being targeted and efficiently set multiple access controls for a given target, as shown here:
aci: (target)...(target)(version 3.0;acl "name"; permissionBindRule; permissionBindRule; ...; permissionBindRule;)
The following example shows a complete LDIF ACI:
aci: (target="ldap:///uid=bjensen,dc=example,dc=com") (targetattr="*")(version 3.0; acl "example"; allow (write) userdn="ldap:///self";)
In this example, the ACI states that the user bjensen has rights to modify all attributes in her own directory entry.