2. The Directory Server Access Control Model > Compatibility With the Sun Java System Directory Server Access Control Model |
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="*")
3. Understanding the Directory Server Schema
4. Directory Server Index Databases
5. Understanding Directory Server Plug-Ins
6. Directory Server Replication
The ACI DN wildcard matching implementation supports the following usage:
Any number of wildcards can appear in Relative Distinguished Name (RDN) attribute values, where they match zero or more characters (similar to substring filters). For example, the bind rule matches the following DNs: uid=bob jensen,dc=example,dc=com and uid=bjensen,dc=example,dc=com:
userdn="ldap:///uid=b*jensen*,dc=example,dc=com"
It does not match the DN cn=bill jensen,dc=example,dc=com because the attribute type of the first RDN does not match.
A single wildcard can also be used to match any RDN attribute type. (The wildcard in this case can be omitted as a shorthand). For example, these two bind rules behave exactly the same:
userdn="ldap:///*=bjensen, dc=example, dc=com" userdn="ldap:///bjensen, dc=example, dc=com"
They both match the following DNs: uid=bjensen,dc=example,dc=com and cn=bjensen,dc=example,dc=com.
A single wildcard can be used to match exactly one RDN component, which can be single or multivalued). For example, the following bind rule matches the DNs uid=jensen,dc=example,dc=com and cn=smith,dc=example,dc=com:
userdn="ldap:///*,dc=example,dc=com"
A double wildcard can be used to match one or more RDN components. For example, the following bind rule matches the DNs uid=jensen,ou=people,dc=example,dc=com and uid=jensen,ou=sales,ou=people,dc=example,dc=com:
userdn="ldap:///uid=bjensen,**,dc=example,dc=com"