 |
Administrator's
Guide Netscape Directory Server |
| Previous |
Contents |
Index |
DocHome | Next |
Netscape Directory Server (Directory Server) provides you with the ability to control access to your directory. This chapter describes the access control mechanism.
This section includes the following topics:
To take full advantage of the power and flexiblity of the access control mechanism, while you are in the planning phase for your directory deployment, you should define an access control strategy as an integral part of your overall security policy. Refer to Netscape Directory Server Deployment Guide for tips on planning your access control strategy.
The mechanism by which you define access is called access control. When the server receives a request, it uses the authentication information provided by the user in the bind operation and the access control instructions (ACIs) defined in the server to allow or deny access to directory information. The server can allow or deny permissions such as read, write, search, and compare. The permission level granted to a user may be dependent on the authentication information provided.
Using access control, you can control access to the entire directory, a subtree of the directory, specific entries in the directory (including entries defining configuration tasks), or a specific set of entry attributes. You can set permissions for a specific user, all users belonging to a specific group or role, or all users of the directory. Finally, you can define access for a specific location such as an IP address or a DNS name.
Access control instructions are stored in the directory as attributes of entries. The aci attribute is an operational attribute; it is available for use on every entry in the directory, regardless of whether it is defined for the object class of the entry. It is used by the Directory Server to evaluate what rights are granted or denied when it receives an LDAP request from a client. The aci attribute is returned in an ldapsearch operation if specifically requested.
The three main parts of an ACI statement are:
The permission and bind rule portions of the ACI are set as a pair, also called an Access Control Rule (ACR). The specified permission is granted or denied depending on whether the accompanying rule is evaluated to be true.
If an entry containing an ACI does not have any child entries, the ACI applies to that entry only. If the entry has child entries, the ACI applies to the entry itself and all entries below it. As a direct consequence, when the server evaluates access permissions to any given entry, it verifies the ACIs for every entry between the one requested and the directory suffix, as well as the ACIs on the entry itself.
The aci attribute is multi-valued, which means that you can define several ACIs for the same entry or subtree.
You can create an ACI on an entry that does not apply directly to that entry but to some or all of the entries in the subtree below it. The advantage of this is that you can place at a high level in the directory tree a general ACI that effectively applies to entries more likely to be located lower in the tree. For example, at the level of an organizationalUnit entry or a locality entry, you could create an ACI that targets entries that include the inetorgperson object class.
You can use this feature to minimize the
number of ACIs in the directory tree by placing general rules at high
level branch points. To limit the scope of more specific rules, you
should place them as close as possible to leaf entries.
|
|
|
|
ACIs placed in the root DSE entry apply only to that entry.
|
|
|
|
|
To evaluate the access rights to a particular entry, the server compiles a list of the ACIs present on the entry itself and on the parent entries back up to the top level entry stored on the Directory Server. ACIs are evaluated across all of the databases for a particular Directory Server but not across Directory Servers.
The evaluation of this list of ACIs is done based on the semantics of the ACIs, not on their placement in the directory tree. This means that ACIs that are close to the root of the directory tree do not take precedence over ACIs that are closer to the leaves of the directory tree.
The precedence rule that applies is that ACIs that deny access take precedence over ACIs that allow access. Between ACIs that allow access, union semantics apply, so there is no precedence.
For example, if you deny write permission at the directory's root level, then none of the users can write to the directory, regardless of the specific permissions you grant them. To grant a specific user write permissions to the directory, you have to restrict the scope of the original denial for write permission so that it does not include the user.
When creating an access control policy for your directory service, you need to be aware of the following restrictions:
When you install the Directory Server, the following default ACIs apply to your directory information stored in the userRoot database:
Whenever you create a new database in the directory, the top entry has the default ACIs listed above.
The NetscapeRoot subtree has its own set of default ACIs:
The following sections explain how to modify these default settings to suit the needs of your organization.
You can create access
control instructions
manually using LDIF statements and add them to your directory tree
using the
ldapmodify utility. The following sections explain in detail how
to create the LDIF statements.
The aci attribute uses the following syntax:
aci: (target)(version 3.0;acl "name"; permission bind_rules;)
You can have multiple permission-bind rule pairs for each target. This allows you to set multiple access controls for a given target efficiently. For example:
target (permission bind_rule)(permission bind_rule)...
If you have several ACRs in one ACI statement, the syntax is of the form:
aci: (target)(version 3.0;acl "name"; permission bind_rules;... permission bind_rule;)
The following is an example of a complete LDIF ACI:
aci:
(target="ldap:///uid=bjensen,dc=example,dc=com")(targetattr=*)
(version
3.0;acl "aci1";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.
The following sections describe the syntax of each portion of the ACI in more detail.
The target identifies what the ACI applies to. If the target is not specified, the ACI applies to the entry containing the aci attribute and to the entries below it.
The general syntax for a target is:
The quotation marks ("") around expression are required. What you use for expression is dependent upon the keyword that you supply.
The following table lists each keyword and
the associated expressions:
Table 6-1
LDIF Target Keywords
In all cases, you must keep in mind that when you place an ACI on an entry, if it is not a leaf entry, the ACI also applies to all entries below it. For example, if you target the entry ou=accounting,dc=example,dc=com, the permissions you set will apply to all entries in the accounting branch of the example.com tree.
As a counter example, if you place an ACI on the ou=accounting,dc=example,dc=com entry, you cannot target the uid=sarette,ou=people,dc=example,dc=com entry because it is not located under the accounting tree.
Be wary of using != when specifying an attribute you want to deny. ACLs are logically ORed, which means that if you created two ACLs
acl1: (target=...)(targetattr!=a)(version 3.0; acl "name";allow (...)..
acl2: (target=...)(targetattr!=b)(version 3.0; acl "name";allow (...)..
the result would be to allow all values of the target attribute. The first ACL (acl1) will allow b and the second ACL (acl2) will allow a. The result of these two ACLs will be the same as the one resulting from using an ACL of the form:
acl3: (targetattr="*" ) allow (...) ...
Notice that nothing is denied. This could give rise to security problems.
When you want to deny access to a particular attribute, use deny in the permissions clause rather than using allow with (targetattr!=value). For example, usages such as these are recommended:
acl1: (target=...)(targetattr=a)(version 3.0; acl "name";deny (...)..
acl2: (target=...)(targetattr=b)(version 3.0; acl "name";deny (...)..
To target a directory entry (and the entries below it), you must use the target keyword.
The target keyword can accept a value of the following format:
target="ldap:///distinguished_name"
This identifies the distinguished name of the entry to which the access control rule applies. For example:
(target =
"ldap:///uid=bjensen,dc=example,dc=com")
You can also use a wildcard when targeting a distinguished name using the target keyword. The wildcard indicates that any character or string or substring is a match for the wildcard. Pattern matching is based on any other strings that have been specified with the wildcard.
The following are legal examples of wildcard usage:
Depending on the position of the wildcard, it can apply to the full DN, not only to attribute values. Therefore, the wildcard can be used as a substitute for portions of the DN. For example, uid=andy*,dc=example,dc=com targets all the directory entries in the entire example.com tree with a matching uid attribute and not just the entries that are immediately below the dc=example,dc=com node. In other words, this target matches with longer expressions such as uid=andy,ou=eng,dc=example,dc=com, or uid=andy,ou=marketing,dc=example,dc=com.
Some other valid examples follow:
In addition to targeting directory entries, you can also target one or more attributes included in the targeted entries. This is useful when you want to deny or allow access to partial information about an entry. For example, you could allow access to only the common name, surname, and telephone number attributes of a given entry. Or you could deny access to sensitive information such as passwords.
You can specify that the target is equal or is not equal to a specific attribute. The attributes you supply do not need to be defined in the schema. This absence of schema checking makes it possible to implement an access control policy when you set up your directory service for the first time, even if the ACLs you create do not apply to the current directory content.
To target attributes, you use the targetattr keyword. The keyword uses the following syntax:
You can target multiple attributes by using the targetattr keyword with the following syntax:
(targetattr="attribute1 || attribute2 ... || attributen")
Where attribute is the name of the attribute you want to target.
For example, to target the common name attribute you would use:
To target an entry's common name, surname, and uid attributes, you would use the following:
(targetattr = "cn || sn || uid")
The attributes specified in the targetattr keyword apply to the entry that the ACI is targeting and to all the entries below it. If you target the password attribute on the entry uid=bjensen,ou=Marketing,dc=example,dc=com, only the password attribute on the bjensen entry is affected by the ACI because it is a leaf entry.
If, however, you target the tree's branch point ou=Marketing,dc=example,dc=com, then all the entries beneath the branch point that can contain a password attribute are affected by the ACI.
By default, the entry targeted by an ACI containing a targetattr keyword is the entry on which the ACI is placed. That is, if you put the ACI
aci: (targetattr = "uid")(access_control_rules;)
on the ou=Marketing , dc=example,dc=com entry, then the ACI applies to the entire Marketing subtree. However, you can also explicitly specify a target using the target keyword as follows:
aci: (target="ldap:///ou=Marketing, dc=example,dc=com")(targetattr="uid")(access_control_rules;)
The order in which you specify the target and the targetattr keywords is not important.
You can use LDAP filters to target a group of entries that match certain criteria. To do this, you must use the targetfilter keyword with an LDAP filter.
The syntax of the targetfilter keyword is:
where LDAP_filter is a standard LDAP search filter. For more information on the syntax of LDAP search filters, see Appendix B, "Finding Directory Entries."
For example, suppose that all entries in the accounting department include the attribute-value pair ou=accounting, and all entries in the engineering department include the attribute-value pair ou=engineering subtree. To target all the entries in the accounting and engineering branches of the directory tree, you could use the following filter:
(targetfilter = "(|(ou=accounting)(ou=engineering))")
This type of filter targets whole entries. You can associate the targetfilter and the targetattr keywords to create ACIs that apply to a subset of attributes in the targeted entries.
The following LDIF example allows members of the Engineering Admins group to modify the departmentNumber and manager attributes of all entries in the Engineering business category. This example uses LDAP filtering to select all entries with businessCategory attributes set to Engineering:
dn:
dc=example,dc=com
objectClass:
top
objectClass:
organization
aci:
(targetattr="departmentNumber || manager")
(targetfilter="(businessCategory=Engineering)")
(version 3.0;
acl "eng-admins-write"; allow (write)
groupdn
="ldap:///cn=Engineering Admins, dc=example,dc=com";)
You can use access control to target specific attribute values. This means that you can grant or deny permissions on an attribute if that attribute's value meets the criteria defined in the ACI. An ACI that grants or denies access based on an attribute's value is called a value-based ACI.
For example, you might grant all users in your organization permission to modify the nsRoleDN attribute in their own entry. However, you would also want to ensure that they do not give themselves certain key roles, such as "Top Level Administrator." LDAP filters are used to check that the conditions on attribute values are satisfied.
To create a value-based ACI, you must use the targattrfilters keyword with the following syntax:
(targattrfilters="add=attr1: F1 && attr2: F2 ... && attrn: Fn,del= attr1: F1 && attr2: F2 ... && attrn: Fn")
When creating an entry, if a filter applies to an attribute in the new entry, then each instance of that attribute must satisfy the filter. When deleting an entry, if a filter applies to an attribute in the entry, then each instance of that attribute must also satisfy the filter.
When modifying an entry, if the operation adds an attribute, then the add filter that applies to that attribute must be satisfied; if the operation deletes an attribute, then the delete filter that applies to that attribute must be satisfied. If individual values of an attribute already present in the entry are replaced, then both the add and delete filters must be satisfied.
For example consider the following attribute filter:
(targattrfilters="add=nsroleDN:(!(nsRoleDN=cn=superAdmin)) && telephoneNumber:(telephoneNumber=123*)")
This filter can be used to allow users to
add any role (nsRoleDN
attribute) to their own entry, except the
superAdmin role. It also allows users to add a telephone number
with a 123 prefix.
|
|
|
|
You cannot create value-based ACIs from the Server Console.
|
|
|
|
|
Targeting a single directory entry is not straightforward because it goes against the design philosophy of the access control mechanism. However, it can be done:
You can use the targetattr keyword to specify an attribute that is only present in the entry you want to target, and not in any of the entries below your target. For example, if you want to target ou=people,dc=example,dc=com, and there aren't any organizational units (ou) defined below that node, you could specify an ACI that contains:
A safer method is to use the targetfilter keyword and to specify explicitly an attribute value that appears in the entry alone. For example, during the installation of the Directory Server, the following ACI is created:
aci: (targetattr="*")(targetfilter=(o=NetscapeRoot))(version 3.0; acl "Default anonymous access"; allow (read, search) userdn="ldap:///anyone";)
This ACI can apply only to the o=NetscapeRoot entry.
The risk associated with these method is that your directory tree might change in the future, and you would have to remember to modify this ACI.
Permissions specify the type of access you are allowing or denying. You can either allow or deny permission to perform specific operations in the directory. The various operations that can be assigned are known as rights.
You can either
explicitly allow or deny access permissions to your directory tree. For
more guidelines on when to allow and when to deny access, refer to the Netscape Directory
Server Deployment Guide.
|
|
|
|
From the Server Console, you cannot explicitly deny access, only grant permissions.
|
|
|
|
|
Rights detail the specific operations a user can perform on directory data. You can allow or deny all rights, or you can assign one or more of the following rights:
Rights are granted independently of one
another. This means, for example, that a user who is granted add rights
can create an entry but cannot delete it if delete rights have not been
specifically granted. Therefore, when planning the access control
policy for your directory, you must ensure that you grant rights in a
way that makes sense for users. For example, it doesn't usually make
sense to grant write permission without granting read and search
permissions.
|
|
|
|
The proxy mechanism is very powerful and must be used sparingly. Proxy rights are granted within the scope of the ACL, and there is no way to restrict who an entry that has the proxy right can impersonate--that is, when you grant a user proxy rights, that user has the ability to proxy for any user under the target; there is no way to restrict the proxy rights to only certain users. For example, if an entity has proxy rights to the dc=example,dc=com tree, that entity can do anything. So, make sure you set the proxy ACI at the lowest possible level of the DIT; see Proxied Authorization ACI Example. For a general overview, see "Proxy Authentication" in chapter 7, "Designing a Secure Directory," in the Netscape Directory Server Deployment Guide.
|
|
|
|
|
This section describes the rights you need to grant to users depending on the type of LDAP operation you want to authorize them to perform.
The permissions you need to set up to allow users to search the directory are more readily understood with an example. Consider the following ldapsearch operation:
% ldapsearch -h host -s base -b "uid=bkolics, dc=example,dc=com " objectclass=* mail
The following ACI is used to determine whether user bkolics can be granted access:
aci: (targetattr = "mail")(version 3.0; acl "self access to mail"; allow (read, search) userdn = "ldap:///self";)
The search result list is empty because this ACI does not grant access to the objectclass attribute. If you want the search operation described above to be successful, you must modify the ACI to read as follows:
aci: (targetattr = "mail || objectclass")(version 3.0; acl "self access to mail"; allow (read, search) userdn = "ldap:///self";)
In an ACI statement, the syntax for permissions is:
where rights is a list of 1 to 8 comma-separated keywords enclosed within parentheses. Valid keywords are read, write, add, delete, search, compare, selfwrite, proxy, or all.
In the following example, read, search, and compare access is allowed, provided the bind rule is evaluated to be true:
aci:
(target="ldap:///dc=example,dc=com")
(version 3.0;acl "example";
allow (read,
search, compare)
bind_rule;)
Access Control and the modrdn Operation
To explicitly deny modrdn rights using ACIs, you must target the relevant entries but omit the targetattr keyword. For example, to prevent the cn=helpDeskGroup,ou=groups,o=example.com group from renaming any entries in the set specified by the pattern cn=*,ou=people,o=example.com, you would add the following ACI:
aci:
(target="ldap:///cn=*,ou=people,o=example.com")
(version 3.0;
acl "Deny modrdn rights to the helpDeskGroup";
deny(write)
groupdn="ldap:///cn=helpDeskGroup,ou=groups,o=example.com";)
Depending on the ACIs defined for the directory, for certain operations, you need to bind to the directory. Binding means logging in or authenticating yourself to the directory by providing a bind DN and password, or, if using SSL, a certificate. The credentials provided in the bind operation and the circumstances of the bind determine whether access to the directory is allowed or denied.
Every permission set in an ACI has a corresponding bind rule that details the required credentials and bind parameters.
Bind rules can be simple. For example, a bind rule can simply state that the person accessing the directory must belong to a specific group. Bind rules can also be more complex. For example, a bind rule can state that a person must belong to a specific group and must log in from a machine with a specific IP address, between 8 a.m. and 5 p.m.
Bind rules define who can access the directory, when, and from where. More specifically, bind rules can specify:
Additionally, bind rules can be complex constructions that combine these criteria by using Boolean operators. See Using Boolean Bind Rules for more information.
Whether access is allowed or denied depends on whether an ACI's bind rule is evaluated to be true. Bind rules use one of the two following patterns:
where equal (=) indicates that
keyword and
expression must match in order for the bind rule to be true, and
not equal (!=) indicates that
keyword and
expression must not match in order for the bind rule to be true.
|
|
|
|
The timeofday keyword also supports the inequality expressions (<, <=, >, >=). This is the only keyword that supports these expressions.
|
|
|
|
|
The quotation marks ("") around expression and the delimiting semicolon (;) are required. The expressions you can use depend on the associated keyword.
The following table lists each keyword and
the associated expressions. It also indicates whether wildcard
characters are allowed in the expression.
Table 6-2
LDIF Bind Rule Keywords
The sections that follow contain further detail on bind rule syntax for each keyword.
User access is defined using the userdn keyword. The userdn keyword requires one or more valid distinguished names in the following format :
userdn = "ldap:///dn [|| ldap:///dn ]...[||ldap:///dn ]"
where dn can be a DN or one of the expressions anyone, all, self, or parent:
userdn = "ldap:///anyone" -- defines anonymous access
userdn = "ldap:///all" -- defines general access
userdn = " ldap:///self" -- defines self access
userdn = " ldap:///parent" -- defines access for the parent entry
The userdn keyword can also be expressed as an LDAP filter of the form:
|
|
|
|
If a DN contains a comma, the comma must be preceded by a backslash (\) escape character.
|
|
|
|
|
Granting anonymous access to the directory means that anyone can access it without providing a bind DN or password and regardless of the circumstances of the bind. You can limit anonymous access to specific types of access (for example, access for read or access for search) or to specific subtrees or individual entries within the directory.
From the Server Console, you define anonymous access through the Access Control Editor. See Creating ACIs from the Console.
You can use bind rules to indicate that a permission applies to anyone who has successfully bound to the directory; that is, all authenticated users. This allows general access while preventing anonymous access.
From the Server Console, you define general access on the Access Control Editor. For more information, see Creating ACIs from the Console.
Specifies that users are granted or denied access to their own entries. In this case, access is granted or denied if the bind DN matches the DN of the targeted entry.
From the Server Console, you set up self access on the Access Control Editor. For more information, see Creating ACIs from the Console.
Specifies that users are granted or denied access to the entry only if their bind DN is the parent of the targeted entry.
You cannot set up parent access control using the Server Console.
You can dynamically target users in ACIs using a URL with a filter as follows:
userdn = "ldap:///<suffix>??sub?(filter)"
For example, all users in the accounting and engineering branches of the example.com tree would be granted or denied access to the targeted resource dynamically based on the following URL:
userdn =
"ldap:///dc=example,dc=com??sub?(|(ou=engineering)
(ou=accounting))"
|
|
|
|
Do not specify a hostname or port number within the LDAP URL. LDAP URLs always apply to the local server.
|
|
|
|
|
For more information about LDAP URLs, see Appendix C, "LDAP URLs."
You can also specify a set of users by using the wildcard character (*). For example, specifying a user DN of uid=u*,dc=example,dc=com indicates that only users with a bind DN beginning with the letter u will be allowed or denied access based on the permissions you set.
From the Server Console, you set user access from the Access Control Editor. For more information, see Creating ACIs from the Console.
This section contains
examples of the
userdn syntax.
userdn = "ldap:///uid=*,dc=example,dc=com";
The bind rule is evaluated to be true if the user binds to the directory using any distinguished name of the specified pattern. For example, both of the following bind DNs would be evaluated to be true:
uid=ssarette,
dc=example,dc=com
uid=tjaz,ou=Accounting,
dc=example,dc=com
whereas the following bind DN would be evaluated to be false:
cn=Babs Jensen, dc=example,dc=com
userdn="ldap:///uid=bj,c=example.com || ldap:///uid=kc,dc=example,dc=com";
The bind rule is evaluated to be true if
the client binds as either of the two supplied distinguished names.
userdn != "ldap:///uid=*,ou=Accounting,dc=example,dc=com";
The bind rule is evaluated to be true if
the client is not binding as a UID-based distinguished name in the
accounting subtree. This bind rule only makes sense if the targeted
entry is not under the accounting branch of the directory tree.
The bind rule is evaluated to be true if the user is accessing the entry represented by the DN with which the user bound to the directory. That is, if the user has bound as uid=ssarette,dc=example,dc=com and the user is attempting an operation on the uid=ssarette,dc=example,dc=com entry, then the bind rule is true.
If you want to grant all users in the example.com tree write access to their userPassword attribute, you would create the following ACI on the dc=example,dc=com node.
aci: (targetattr =
"userPassword") (version
3.0; acl "write-self"; allow (write) userdn = "ldap:///self";)
The bind rule is evaluated to be true for any valid bind DN. To be true, a valid distinguished name and password must have been presented by the user during the bind operation.
For example, if you want to grant read access to the entire tree to all authenticated users, you would create the following ACI on the dc=example,dc=com node:
aci:(version 3.0;
acl "all-read"; allow
(read) userdn="ldap:///all";)
The bind rule is evaluated to be true for anyone; use this keyword to provide anonymous access to your directory.
For example, if you want to allow anonymous read and search access to the entire example.com tree, you would create the following ACI on the dc=example,dc=com node:
aci: (version 3.0; acl
"anonymous-read-search"; allow (read, search) userdn =
"ldap:///anyone";)
The bind rule is evaluated to be true if the bind DN is the parent of the targeted entry.
For example, if you want to grant write access to every user's child entries, you would create the following ACI on the dc=example,dc=com node:
aci:(version 3.0; acl "parent access"; allow (write) userdn="ldap:///parent";)
userdn =
"ldap:///dc=example,dc=com???(|(ou=engineering)
(ou=sales))";
The bind rule is evaluated to be true if the user belongs to the engineering or sales subtree.
Members of a specific group can access a targeted resource. This is known as group access. Group access is defined using the groupdn keyword to specify that access to a targeted entry will be granted or denied if the user binds using a DN that belongs to a specific group.
The groupdn keyword requires one or more valid distinguished names in the following format :
groupdn="ldap:///dn[|| ldap:///dn]...[|| ldap:///dn]"
The bind rule is evaluated to be true if
the bind DN belongs to the named group.
|
|
|
|
If a DN contains a comma, the comma must be escaped by a backslash (\).
|
|
|
|
|
From the Server Console, you can define specific groups using the Access Control Editor. For more information, see Creating ACIs from the Console.
This section contains
examples of the
groupdn
syntax.
groupdn = "ldap:///cn=Administrators,dc=example,dc=com";
The bind rule is evaluated to be true if the bind DN belongs to the Administrators group. If you wanted to grant the Administrators group permission to write to the entire directory tree, you would create the following ACI on the dc=example,dc=com node:
aci: (version 3.0;
acl
"Administrators-write"; allow (write)
groupdn="ldap:///cn=Administrators,dc=example,dc=com";)
groupdn = "ldap:///cn=Administrators,dc=example,dc=com" || "ldap:///cn=Mail Administrators,dc=example,dc=com";
The bind rule is evaluated to be true if the bind DN belongs to either the Administrators or the Mail Administrators group.
Members of a specific role can access a targeted resource. This is known as role access. Role access is defined using the roledn keyword to specify that access to a targeted entry will be granted or denied if the user binds using a DN that belongs to a specific role.
The roledn keyword requires one or more valid distinguished names in the following format :
roledn = "ldap:/// dn [|| ldap:/// dn]... [|| ldap:/// dn]"
The bind rule is evaluated to be true if
the bind DN belongs to the specified role.
|
|
|
|
If a DN contains a comma, the comma must be escaped by a backslash (\).
|
|
|
|
|
The roledn keyword has the same syntax and is used in the same way as the groupdn keyword.
You can set bind rules to specify that an attribute value of the entry used to bind to the directory must match an attribute value of the targeted entry.
For example, you can specify that the bind DN must match the DN in the manager attribute of a user entry in order for the ACI to apply. In this case, only the user's manager would have access to the entry.
This example is based on DN matching. However, you can match any attribute of the entry used in the bind with the targeted entry. For example, you could create an ACI that allowed any user whose favoriteDrink attribute is beer to read all the entries of other users that have the same value for favoriteDrink.
The userattr keyword can be used to specify which attribute values must match between the entry used to bind and the targeted entry. You can specify:
The LDIF syntax of the userattr keyword is as follows:
userattr = "attrName # bindType"
or, if you are using an attribute type that requires a value other than a user DN, group DN, role DN, or an LDAP filter:
userattr = "attrName # attrValue"
The following sections provide examples of the userattr keyword with the various possible bind types.
The following is an example of the userattr keyword associated with a bind based on the user DN:
The bind rule is evaluated to be true if the bind DN matches the value of the manager attribute in the targeted entry. You can use this to allow a user's manager to modify employees' attributes. This mechanism only works if the manager attribute in the targeted entry is expressed as a full DN.
The following example grants a manager full access to his or her employees' entries:
aci:
(target="ldap:///dc=example,dc=com")(targetattr=*) (version 3.0;
acl
"manager-write"; allow (all) userattr = "manager#USERDN";)
The following is an example of the userattr keyword associated with a bind based on a group DN:
The bind rule is evaluated to be true if the bind DN is a member of the group specified in the owner attribute of the targeted entry. For example, you can use this mechanism to allow a group to manage employees' status information. You can use an attribute other than owner as long as the attribute you use contains the DN of a group entry.
The group you point to can be a dynamic group, and the DN of the group can be under any suffix in the database. However, the evaluation of this type of ACI by the server is very resource intensive.
If you are using static groups that are under the same suffix as the targeted entry, you can use the following expression:
userattr = "ldap:///dc=example,dc=com?owner#GROUPDN"
In this example, the group entry is under the dc=example,dc=com suffix. The server can process this type of syntax more quickly than the previous example.
(By default, owner is not an allowed entry in a user's entry. You would have to extend your schema to allow this attribute in a person object.)
The following is an example of the userattr keyword associated with a bind based on a role DN:
userattr = "exampleEmployeeReportsTo#ROLEDN"
The bind rule is evaluated to be true if
the bind DN belongs to the role specified in the
exampleEmployeeReportsTo attribute of the targeted entry. For
example, if you create a nested role for all managers in your company,
you can use this mechanism to grant managers at all levels access to
information about employees that are at a lower grade than themselves.
|
|
|
|
This example assumes that you have added the exampleEmployeeReportsTo attribute to the schema and that all employee entries contain this attribute. It also assumes that the value of this attribute is the DN of a role entry. For information on designing your schema, refer to Netscape Directory Server Deployment Guide. For information on adding attributes to the schema, see Creating Attributes.
|
|
|
|
|
The DN of the role can be under any suffix in the database. If, in addition, you are using filtered roles, the evaluation of this type of ACI uses a lot of resources on the server.
If you are using a static role definition and the role entry is under the same suffix as the targeted entry, you can use the following expression:
userattr = "ldap:///dc=example,dc=com?employeeReportsTo#ROLEDN"
In this example, the role entry is under the dc=example,dc=com suffix. The server can process this type of syntax more quickly than the previous example.
The following is an example of the userattr keyword associated with a bind based on an LDAP filter:
The bind rule is evaluated to be true if the bind DN matches the filter specified in the myfilter attribute of the targeted entry. The myfilter attribute can be replaced by any attribute that contains an LDAP filter.
When you use the userattr keyword to associate the entry used to bind with the target entry, the ACI applies only to the target specified and not to the entries below it. In some circumstances, you might want to extend the application of the ACI several levels below the targeted entry. This is possible by using the parent keyword and specifying the number of levels below the target that should inherit the ACI.
When you use the userattr keyword in association with the parent keyword, the syntax is as follows:
userattr = "parent[inheritance_level]. attrName#bindType"
or, if you are using an attribute type that requires a value other than a user DN, group DN, role DN, or an LDAP filter: