![]() ![]()
|
Introduction To Access Control ListsBackground
Access Control Information
The permission and bind rule portions of the ACI are set as a pair, and you can have multiple permission-bind rule pairs for each target. This allows you to efficiently set multiple access controls for a given target. For example: <target>(<permission><bind rule>)(<permission><bind rule>)... Targets
Targeting a Directory Entry When you target a directory entry, the ACIs you set apply to the target and all of its children. For example, if you target the entry ou=accounting, o=airius.com, the ACI will apply to all entries in the accounting branch of the Airius tree. Most often, you will want to place your ACIs on branch points in the directory rather than on individual leaf objects. You can also use wildcards when targeting a directory entry. For example, targeting uid=c*a, o=airius.com would target all directory entries with user ID attributes that start with c and end with a. Note however that you cannot wildcard the suffix portion of the distinguished name. For example, targeting uid=bjensen, o=*.com is not a legal command. If you are setting access control using the Server Manager, you target an entry using the Target field on the Access Control Rules form. Keep in mind that the entry you target must be at the same level or a child of the entry containing the ACI. For example, if the ACI attribute you are modifying resides on the ou=accounting, o=airius.com entry, you cannot target the uid=sarette, ou=people, o=airius.com entry because it is not a child of the accounting tree; rather it is within a separate branch of the Airius tree. Targeting Attributes In addition to targeting directory entries, you can also target one or more attributes included in the targeted entry. This is useful for 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 or salary information. You can specify that the target attribute either is (=) or is not (!=) equal to a specific attribute. The attributes you supply should be recognized members of your schema, although they do not have to be allowed by the object class of the targeted entry. If you are setting access control using the Server Manager, you specify one or more attributes to deny or allow access to by using the Attr field of the Access Control Rules form. As is true when targeting directory entries, you can also use wildcards when targeting an attribute. For example, to target all attributes that begin with the letter "u", you would set the Attr field to u*. Targeting using LDAP Filters In addition to explicitly targeting directory entries and attributes, you can also use LDAP filters to target a group of entries and/or attributes that match a certain criteria. When searching the directory, LDAP filters select the entries to be returned as a result of the search operation. The same is true when you use LDAP filters in ACIs, except that the entries and attributes returned are then targeted by the ACI. For example, if your target is o=airius.com, you could set the filter to target the ou=people and ou=groups trees. Without the filter, the ACI would apply to all entries below o=airius.com. However, with the filter, the ACI will only apply to the ou=people, o=airius.com and ou=groups, o=airius.com entries and their child entries. If you are setting access controls using the Server Manager, you can specify a target filter in the Filter field of the Access Control Rules form. Although targeting using LDAP filters can be useful when you are targeting entries and attributes that are spread across the directory, the results are sometimes unpredictable. Because search filters do not directly name the object that you are managing access for, it is easy to unintentionally allow or deny access to the wrong objects, especially as your directory becomes more complex. Additionally, filters can make it difficult for you to troubleshoot ACI problems within your directory. If you do use filtering, do so sparingly. Be sure to test your directory access thoroughly each time you change a filter so that you are certain what the results of the change mean for access to your directory. Permissions
By default all users are denied access rights of any kind. The exception
to this is the user defined in the Root DN parameter. This user is known
as the root or unrestricted user. The unrestricted user has full access
to your directory regardless of the permissions set for the directory.
For this reason, you must set some permissions for your directory if you
want any normal users to be able to access your directory. There are two
parts to setting permissions:
Allowing or Denying Access You can either explicitly allow access or you can explicitly deny access to your directory tree. When an LDAP client attempts to perform any kind of access to a directory entry, the Directory Server looks for access control information from the entry being accessed back to the top, or root, or the directory tree. When deciding whether to allow or deny access, you should keep the precedence rule in mind. Precedence rule If two permissions exist and are in conflict, the permission that denies
access always takes precedence over the permission that grants access.
When setting access control using the Server Manager, you specify whether to allow or deny access using the Action area. When setting access control using LDIF, you use the allow or deny keywords in the permission portion of the ACI statement to explicitly allow or deny access. Assigning Rights Rights detail the specific operations a user can perform on the directory
data. You can either allow or deny all rights or you can assign one or
more of the following rights:
When setting access control using the Server Manager, you specify which rights to allow or deny using the Rights area. When setting access control using LDIF, you use the rights keywords within the permission portion of the ACI statement to explicitly allow or deny access. Bind Rules
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: <keyword> = "<expression>"; <keyword> != "<expression>";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. Bind rules tell who can access the directory, when, and from where.
More specifically, bind rules specify the
Additionally, bind rules can be complex constructions that combine bind methods using Boolean operators. Each bind method is detailed in the following sections. User and Group AccessMost commonly, bind rules state who can access the directory. A bind rule may state thatAnonymous Access Anonymous access can be configured for the directory such that anyone can access it. In this situation, users do not need to provide a Bind DN or password to gain access. 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. If you are setting access control using the server manager, you can
define anonymous access by clicking Anyone (No Authentication) in the User/Group
area.
General Access You can use bind rules to indicate that the permission applies to anyone who has successfully bound to the directory. This allows general access while preventing anonymous access. If you are setting access control using the server manager, you can define general access by clicking Authenticated people only and All in the User/Group area. User Access You can use bind rules to specify that access to the targeted resource will be granted or denied only if the user binds using a specific DN. You can also specify groups of users by using the wildcard character (*). For example, specifying a user DN of uid=u*, o=airius.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. If you are setting access control using the server manager, you set
user access using the UserDN(S) field in the Users/Groups area.
Using LDAP URLs You can dynamically target users in ACIs using a URL with a filter as
follows:
"ldap:///<suffix>??sub?(filter)"For example, all users in the accounting and engineering branches of the Airius tree would be granted or denied access to the targeted resource dynamically based on the following URL: "ldap:///o=airius.com??sub?(ou=engineering)(ou=accounting)"Note: Do not specify a hostname or port number within the LDAP URL or the URL will be skipped. Parent Access Another special user access bind rule is the case in which a user is granted or denied access to the entry only if the Bind DN is the parent of the targeted entry. If you are setting access control using the Server Manager, you can set up parent access by entering parent in the UserDN(S) field in the Users/Groups area. Self Access Another special user access bind rule is the case in which you want to grant or deny users access to their own entries. In this case, access would be granted or denied if the Bind DN matches the DN of the targeted entry. If you are setting access control using the Server Manager, you can set up self access by entering self in the UserDN(S) field in the Users/Groups area. Group Access You can use bind rules to specify that access to a targeted entry will be granted or denied only if the user binds using a DN that belongs to a specific group. If you are setting access control using the server manager, you can
define specific groups using the GroupDN(s) field in the Users/Groups
Area.
Access Based on Attribute Value You can set a bind rule such that the ACI will apply only if the Bind DN matches a DN specified in a specific attribute of the targeted entry. The named attribute must be one that is expected to contain a full distinguished name. For example, you can specify that the Bind DN must match the DN in the manager attribute of the user entry. In this situation, only the user's manager would have access to the entry. If you are setting access control using the server manager, you can
specify that the Bind DN must match the DN in an attribute in the user
entry by typing the attribute name in the UserDnAttr field.
Access from a Specific Machine or Domain Using bind rules, you can indicate that the ACI is applicable only if the bind operation is arriving from a specific IP address or fully qualified DNS domain or hostname. This is often used to force all directory updates to occur from a given machine or network domain. You can also use the wildcard character (*) to denote multiple machines. For example, you could use a wildcard IP address such as 12.3.45.* to specify a specific subnetwork or 123.45.6.*+255.255.255.115 to specify a subnetwork mask. Or you could use a wildcard domain name such as *.airius.com to specify a specific DNS domain. If you are setting access control using the server a, you can define specific machines to which the ACI applies using the From Host area. Access at a Specific Time of Day or Day of Week You can also use bind rules to specify that the ACI will only apply at a certain time of day or on a certain day of the week. For example, you can set a rule that will allow access only if it is between the hours of 8 AM and 5 PM Monday through Friday. The time used is the time on the local host. There is no support for time-based bind rules in the Server Manager. However, if you are using the Server Manager to set access control, you can specify time-based bind rules using the Extra area (or Customized Expressions) to enter the LDIF. Access Based on Authentication Method You can also set bind rules that state that the ACI will apply only
if a client binds to the directory using a specific authentication method.
The authentication methods you can require are
If you are using the Server Manager to set access control, you can set up authentication-based bind rules using the User/Group area. Boolean Bind Rules Bind rules can be complex expressions that use the Boolean expressions AND, OR, and NOT to set very precise access rules. If you are using the Server Manager to set access control, you will need to use the Extra area (or Customized Expressions) to enter the LDIF commands if you want to use boolean bind rules. Evaluating Boolean Bind Rules Boolean expressions are evaluated in the following order:
Also, the Boolean OR and Boolean AND operators have no order of precedence and they are evaluated from left to right. However, the boolean NOT operator is evaluated before the Boolean OR and Boolean AND. Thus, in the following example the NOT operator is evaluated before the AND operator: <bind rule 1> and not <bind rule 2> |
Copyright © 2000
Sun-Netscape Alliance