The following table lists a sample set of permission entries for a scenario of delegating administration of groups:
Table 11: Permission entries for delegating administration of groups
Domain |
Object Access |
Allow List |
Domain |
Object Property Access |
Allow Read All Properties |
Domain |
Object Property Access |
Allow Write LDAP Server (permission to change Operational Domain Controller) |
Organizational Unit |
Object Access |
Allow List |
Organizational Unit |
Object Property Access |
Allow Read All Properties |
Organizational Unit |
Child Object Creation/Deletion |
Allow Create/Delete Groups |
Group |
Object Access |
Allow List |
Group |
Object Property Access |
Allow Read All Properties |
Group |
Object Property Access |
Allow Write Members |
User |
Object Access |
Allow List |
User |
Object Property Access |
Allow Read All Properties |
This set of permission entries has several important characteristics:
-
It allows access to the Domain and the Organizational Unit object classes. This is because without access to the domain and the Organizational Units a delegated administrator cannot see the groups and users beneath. This access should always include the List and Read All Properties permissions.
-
It gives a delegated administrator the ability to create and delete group objects. This permission applies to the Organizational Unit object class.
-
It gives a delegated administrator the ability to see (List) groups, view any property of a group (Read All Properties), and add or remove members from a group (Write Members).
-
It gives a delegated administrator the ability to see (List) users and view any property of a user (Read All Properties). This is necessary for a delegated administrator to add users to a group.
For your delegation model to work correctly, you need to determine whether you have a functional or hosted 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 12: 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 |
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 13: 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.