Chat now with support
Chat mit Support

Active Roles 8.2 - Feature Guide

Introduction About Active Roles
Main Active Roles features Technical overview of Active Roles
About presentation components Overview of service components About network data sources About security and administration elements About Active Directory security management Customization using ADSI Provider and script policies About dynamic groups About workflows Operation in multi-forest environments
Examples of use
Administrative rules and roles
About Managed Units About Access Templates About Access Rules About rule-based autoprovisioning and deprovisioning
Configuring and administering Active Roles Overview of Active Roles Synchronization Service Support for AWS Managed Microsoft AD FIPS compliance LSA protection support STIG compliance

Deployment considerations for Access Templates

Active Roles utilizes role-based delegation for assigning administrative permissions. The advantage of this model is that a role can be created once and delegated to multiple groups of users that fit that role. If a change is needed, an update to the role will take effect for everyone. These roles are known in Active Roles as Access Templates.

When doing delegation with Active Roles, consider the following:

  • Active Roles administrators (Active Roles Admins) have full control throughout the system and cannot be denied access anywhere within Active Roles. Everyone else starts with nothing and permissions are added from the ground up.

  • Permissions are cumulative. You must adhere to the following permission precedence. The permission on top has the highest precedence:

    1. Explicit Deny

    2. Explicit Allow

    3. Inherited Deny

    4. Inherited Allow

  • Keep your permission model as simple as possible. Sometimes this means giving users all read/write permissions and denying the ability to write a few fields.

  • Do not use the default (built-in) Access Templates as they cannot be modified. Instead, copy those Access Templates and move them to a new container. This way all of the Access Templates you are using are stored within a particular structure.

There are three basic types of permissions that can be added to an Access Template:

  • Object access: With this permission type, you can set permissions that affect an object as a whole. For example, Move, List and Deprovision are object permissions.

  • Object property access: These are used to control access to individual attributes of an object, such as the object description, samAccountName, or homeFolder. With this permission type, you can delegate granular rights over an object. However just because the rights that can be delegated can be granular does not mean that they should. For instance, if a helpdesk operator needs to be able to manage a large set of user properties, it makes more sense to delegate read/write for all properties as this is one permission entry instead of delegating read/write for every individual attribute since each attribute would need to have its own permission entry.

  • Child object creation/deletion: With this permission type, you can set permissions for creation or deletion of objects. For instance, to set up an Access Template that allows creation of users, you should add a permission entry that applies to the Organizational Unit and Container object classes, and contains a Create child objects permission for the User object class.

The following sections give a sample set of the permissions necessary for certain delegation scenarios:

Delegation of Organizational Unit administration duties

The following table lists a sample set of permission entries for a scenario of delegating administration duties for Organizational Units:

Table 2: Permission entries for delegating administration of Organizational Units

Object Class

Permission Type

Attribute or Permission

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 Users

User

Object Access

Allow List

User

Object Property Access

Allow Read/Write All Properties

User

Object Property Access

Deny Write Employee ID

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 users beneath. This access must include the List and Read All Properties permissions.

  • It gives a delegated administrator the ability to create and delete user objects. This permission applies to the Organizational Unit object class.

  • It gives a delegated administrator the ability to see (List) users and modify any property except Employee ID.

Delegation of group administration

The following table lists a sample set of permission entries for a scenario of delegating administration of groups:

Table 3: Permission entries for delegating administration of groups

Object Class

Permission Type

Attribute or Permission

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.

Delegation in functional and hosted environments

For your delegation model to work correctly, you need to determine whether you have a functional or hosted environment.

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen