|
|
|
The set protected-items command lets you protect specific subtrees, entries, or particular attributes in a subtree or entry. Use protected-items controls to protect some attributes in a part of the DIT.
This command denies (takes away) specified access rights that have been granted at the registered users and public users access level
Access rights denied at this access level can be granted by rules at the administrative users and super users access levels.
Access control rules are effective only if you enable access controls.
This command has the following format:
set protected-items [tag] = {
[users] [scope] [attrs = attribute-list] [perms = permission-list] [validity = [start hhmm end hhmm] [on day]]
};
(Optional) Defines a name for this rule.
(Optional) Identifies the users that are to be denied access to the item. Use one of the following:
Specifies that this rule restricts users' access to their own entry.
Specifies that this rule restricts users' access to the subtree beneath their own entry.
Specifies the user whose access this rule restricts.
Specifies the role whose access this rule restricts.
Specifies the access control group whose access this rule restricts.
Specifies the subtree of users whose access this rule restricts.
(Optional) Defines the part of the DIT that this rule applies to.
Use one of the following:
Specifies the entry that this rule protects.
If entry is specified and is not a leaf node then the user still has the right to use the entry in a path to a lower level entry, so normally you only specify entry if it is a leaf node.
Specifies the subtree that this rule protects.
(Optional) Defines the attributes or attribute set to which this rule applies, where attribute-list is a comma-separated list of attribute names.
If attrs is not specified, then the access rule applies to the whole entry.
If perms is not specified then the command will deny all permissions.
Normally you will not specify perms.
Denies users all permissions over the scope.
Denies users read permission over the scope. This has the same effect as specifying perms=all.
Denies users permission to add to the information defined in the scope.
Denies users permission to delete entries defined in the scope.
Denies users permission to change information defined in the scope.
Denies users permission to rename the entries defined in the scope.
(Optional) Defines the period during which this rule is valid. Use any of the following:
Defines the start and end of the period during which this rule is valid.
Defines the day on which this rule is valid, where day is a string like 12345 or 67 (1 is Monday).
Example: Protect a Subtree
The command in this example makes a subtree invisible:
set protected-items hide-finance-from-employees = {
group = employees"
subtree = <c AU"><o Democorp"><ou Finance">
};
Example: Protect an Entry
The command in this example could be used to hide some management information about a DSA definition stored within the directory:
set protected-items hide-schema-from-employees" = {
role = employees"
entry = <c AU"><o Democorp"><ou Schema">
};
The specified entry is invisible to members of the employees role (unless a higher precedence access control rule grants them some access).
Example: Protect Some Attributes
The command in this example protects the homePhone and userPassword attributes in any entries in the Democorp subtree that have these attributes.
These attributes are visible to any super users and administrative users that have the Democorp subtree in their scope, but the attributes are hidden from all other users:
set protected-items hide-passwords-and-home-phone" = {
subtree = <c AU"><o Democorp">
attrs = homePhone, userPassword
};
Example: Let Users View a Whole Entry and Modify Some Attributes
This example shows how to give users update access to most attributes within an entry but prevent the update of a small number of attributes.
This problem is made more complex because the list of attributes that can be updated can grow, for example, as more attributes are added to the entry.
A solution to this problem is to use the optional permissions in the access control rules. The following access rule will let all users in the subtree modify all attributes in their own entry:
set reg-user = {
own-entry
subtree = <o test>
perms = modify
};
To prevent update access to some of these attributes, use the following command:
set protected-items = {
own-entry
subtree = <o test>
attrs = attr1, attr2, ...
perms = modify
};
This prevents the user modifying the attributes listed, but it does not prevent read access. This is because the only permission denied is modify.
Example: Let Users Modify All Attributes in Their Own Entry Except "role"
In this example, the set reg-user rule gives users modification rights to all attributes in their own entry, and the protected-items rule takes away modification rights for just the role attribute. The result is that users can modify all attributes in their own entries except "role", which they can read:
set reg-user = {
own-entry
subtree = <o Democorp>
perms = modify
};
set protected-items = {
own-entry
subtree = <o DemoCorp>
attrs = role
perms = modify
};
Without the perms = modify in the set protected-items rule, the user would be denied all access to the role attribute (including read access).
| Copyright © 2011 CA. All rights reserved. | Email CA Technologies about this topic |