| Exit Print View | |
Sun OpenDS Standard Edition 2.2 Architectural Reference |
|
|
2. The Directory Server Access Control Model > Bind Rule Syntax > Defining Access Based on Value Matching (userattr Keyword) |
|
2. 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
3. Understanding the Directory Server Schema
4. Directory Server Index Databases
5. Understanding Directory Server Plug-Ins
6. Directory Server Replication
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.
|
|