Delegation in a functional environment
In a functional environment there is a separate group of administrators for each function. So there may be a group for managing users, a helpdesk, domain administrators, and Exchange administrators. In case of a functional environment, you need to decide on a certain role for each function. These roles usually cross Organizational Unit boundaries so delegation is typically done at the root of the domain or domains. Typically a delegation model for this scenario would look something like the following:
Table 4: Delegation model in a functional environment
|
Domain / Read All Objects |
- All Objects - List
- All Objects - Read All Properties
- Domain - Write LDAP Server Property (permission to change Operational Domain Controller)
|
Authenticated Users |
|
Domain / User Admin |
- User Objects - Full Control
- Organizational Unit - Create/Delete User Objects
|
User Admin group |
|
Domain / Group Admin |
- Group Objects - Full Control
- Organizational Unit - Create/Delete Group Objects
|
Group Admin group |
Delegation in a hosted environment
In a hosted environment there is an admin group or set of admin groups responsible for each top-level Organizational Unit (OU). In this case administrators may not want others to see what is going on in their OU structure. Active Roles can accommodate this easily. Since except for the Active Roles administrators no one has any default rights, a delegation model may look something like the following:
Table 5: Delegation model in a hosted environment
|
Domain / Read Domain |
- Domain - List
- Domain - Read All Properties
- Domain - Write LDAP Server Property
|
Authenticated Users |
|
Top-level OU / OU Admin |
- All Objects - List
- All Objects - Read all Properties
- Organizational Unit - Create/Delete User/Group Objects
- User Objects - Full Control
- Group Objects - Full Control
|
OU Admin |
With this delegation model, everyone can see the domain and change the domain controller they are using for management. However, below that only the OU admin can see their associated OU. This keeps administrators from seeing or managing anything outside of their control.
More than likely a delegation model would incorporate features of both. For instance, you may have a hosted environment where each business unit is responsible for their own Active Directory management, with a central helpdesk to perform basic user and group management tasks.
Lastly is the issue of syncing permission to Active Directory. Although Active Roles enables you to accomplish this task, it is a better idea to keep all of the permissions within Active Roles for the following reasons:
-
This protects your Active Directory. Directory-enabled applications can be modified to use the Active Roles ADSI Provider allowing for granular access to only the data and areas that are needed. Doing so helps prevent malicious software from destroying data in Active Directory.
-
This ensures directory integrity. By forcing all administrators to use Active Roles, you ensure that all policies, such as naming standards, are correctly enforced.
-
This gives a complete auditing picture. By having all applications and administrators use Active Roles interfaces, you ensure that the Active Roles Data Collector can gather every action that happens in the directory, down to the attribute level.
Access Rules
Active Roles introduces claims-based authorization rules (access rules) to allow or deny access to Active Directory objects depending on the attributes of the identity attempting to access those objects. Built on the concept of Dynamic Access Control (DAC), this feature enables Active Roles to recognize and evaluate the attribute-based claims of the identity that requests access to data held in Active Directory.
Access rules improve access control management for Active Directory administration. With access rules, Active Roles adds more flexibility and precision in delegating control of Active Directory objects, such as users, computers or groups, through the use of claims (the Active Directory user and computer properties) in the Active Roles authorization model.
By using access rules, you can control access to Active Directory objects based on the characteristics of both the objects and the delegated administrators requesting access to the objects. This feature enables you to define and enforce very specific requirements for granting administrative access to Active Directory data. For example, you can easily restrict access of delegated administrators to user accounts whose properties (such as Department or Country) match the properties of the delegated administrator’s account in Active Directory.
Access rules help you create more complete access controls on Active Directory objects by comparing object properties with user and device claims. A domain controller issues claims to an identity that consist of assertions based on the properties of that identity retrieved from Active Directory. When an identity requests access to a particular object, Active Roles evaluates the claims of that identity and the properties of that object against the access rules, and then, depending upon the evaluation results, applies the appropriate Access Templates to make an authorization decision.
Understanding Access Rules
Access Rules enable administrators to apply access-control permissions and restrictions based on well-defined conditions that can include the properties of the target objects, the properties of the user who requests access to target objects, and the properties of the device from which the user requests access to target objects. For example, when the role or the job of a user changes (resulting in changes to the attributes of the user account in Active Directory), Access Rules can cause the user permissions to change dynamically without additional intervention from the administrator.
An Access Rule is an expression of authorization rules that can include conditions that involve user groups, user claims, device groups, device claims, and target object properties. When you apply an Access Template, you can use an Access Rule to determine the conditions that must be satisfied for the permissions resulting from the Access Template to take effect.
