Exit Print View

Sun OpenDS Standard Edition 2.0 Architectural Reference

Get PDF Book Print View

Document Information

The Directory Server Access Control Model

Access Control Principles

Access Control Overview

ACI Structure

Directory Server Global ACIs

ACI Evaluation

ACI Limitations

Access Control and Replication

See Also

ACI Syntax

ACI Syntax Overview

Defining Targets

Targeting a Directory Entry

To Target Attributes

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 Controls

To Target LDAP Extended Operations

Defining Permissions

To Allow or Deny Access

To Assign Rights

Rights Required for LDAP Operations

Permissions Syntax

Bind Rules

Bind Rules Overview

Using Boolean Bind Rules

See Also

Bind Rule Syntax

Bind Rule Syntax Overview

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

Excluding Specific 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)

Bind-Type Format

Attribute-Value Format

USERDN Bind Type Example

GROUPDN Bind Type Example

LDAPURL Bind Type Example

Attribute Value Example


Inheritance Example

Add Permissions

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

TLS Cipher Key Size Mapping


Compatibility With the Sun Java System Directory Server Access Control Model

Global ACI

All Attributes targetattr Rule (targetattr="*")

Distinguished Name (DN) Wildcard Matching

Privilege Subsystem Impact

The targetscope Keyword

LDAP Modify Increment

Macro Support

The roledn Keyword

Understanding the Directory Server Schema

Index Databases

Understanding Directory Server Plug-Ins

Directory Server Replication

Root Users and the Privilege Subsystem

Supported Controls and Operations

Add Permissions

If you use the userattr keyword in conjunction with all or add permissions, you might find that the behavior of the directory server is not what you expect. Typically, when a new entry is created in the directory, the directory server evaluates access rights on the entry being created, and not on the parent entry. However, in the case of ACIs using the userattr keyword, this behavior could create a security hole, so the directory server's normal behavior is modified to avoid it.

Consider the following example ACI:

aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0; acl "manager-write"; allow (all)
userattr = "manager#USERDN";)

This ACI grants managers all rights on the entries of employees that report to them. However, because access rights are evaluated on the entry being created, this type of ACI would also allow any employee to create an entry in which the manager attribute is set to their own DN. For example, disgruntled employee Joe, cn=Joe,ou=eng,dc=example,dc=com, might want to create an entry in the Human Resources branch of the tree to use (or misuse) the privileges granted to Human Resources employees.

He could do this by creating the following entry:

dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com
objectclass: top
cn: Trojan Horse
manager: cn=Joe,ou=eng,dc=example,dc=com

To avoid this type of security threat, the ACI evaluation process does not grant add permission at level 0, that is, to the entry itself. You can, however, use the parent keyword to grant add rights below existing entries. You must specify the number of levels below the parent for add rights. For example, the following ACI allows child entries to be added to any entry in the dc=example,dc=com that has a manager attribute that matches the bind DN:

aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0; acl "parent-access"; allow (add)
userattr = "parent[1].manager#USERDN";)

This ACI ensures that add permission is granted only to users whose bind DN matches the manager attribute of the parent entry.