Bind RulesChapter 6 Managing Access Control 229The bind rule is evaluated to be true if the bind DN belongs to the role specified inthe exampleEmployeeReportsTo attribute of the targeted entry. For example, ifyou create a nested role for all managers in your company, you can use thismechanism to grant managers at all levels access to information about employeesthat are at a lower grade than themselves.The DN of the role can be under any suffix in the database. If, in addition, you areusing filtered roles, the evaluation of this type of ACI uses a lot of resources on theserver.If you are using a static role definition and the role entry is under the same suffix asthe 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 servercan process this type of syntax more quickly than the previous example.Example with LDAPURL Bind TypeThe following is an example of the userattr keyword associated with a bindbased on an LDAP filter:userattr = "myfilter#LDAPURL"The bind rule is evaluated to be true if the bind DN matches the filter specified inthe myfilter attribute of the targeted entry. The myfilter attribute can be replaced byany attribute that contains an LDAP filter.Example with Any Attribute ValueThe following is an example of the userattr keyword associated with a bindbased on any attribute value:userattr = "favoriteDrink#Beer"The bind rule is evaluated to be true if the bind DN and the target DN include thefavoriteDrink attribute with a value of Beer.NOTE This example assumes that you have added theexampleEmployeeReportsTo attribute to the schema and that allemployee entries contain this attribute. It also assumes that thevalue of this attribute is the DN of a role entry.For information on designing your schema, refer to Red HatDirectory Server Deployment Guide. For information on addingattributes to the schema, see “Creating Attributes,” on page 377.