Softerra Adaxes provides role-based administration model to extend Active Directory functionality and to simplify access management. Distributed security administration is implemented through Security Roles used to organize permissions and to distribute them between users and groups.
Each Security Role has a set of permissions delegated to some users on certain resources. Users or security groups to which Security Roles are assigned are called trustees. The objects to which these trustees can apply delegated permissions constitute the Security Role activity scope.
Security Roles can be assigned to trustees on whole domains, on members of groups and Business Units, on children of containers and organizational units, on specific objects or on Adaxes service Configuration Objects. Objects can be both included to and excluded from the Security Role assignment.
| Security Roles assigned on Configuration Objects delegate their trustees the corresponding permissions on Business Rules, Security Roles, Property Patterns, Managed Units and Managed Domains. |
The  icon indicates assigned Security Roles, and the  icon indicates unassigned Security Roles.
|
Permissions of Service Administrators are not restricted by Security Roles as security checks are not performed for users specified as service administrators. It means that service administrators have unlimited access to objects of Managed Domains and Adaxes service Configuration Objects.
Trustees can be users, security groups or Well-Known Security Principals. Well-Known Security Principals include:
Authenticated Users: a special system group that includes managed domain user and computer accounts the identities of which have been authenticated. This group does not include Guests (users from domains that are not managed by the Adaxes service).
Self: when you grant permissions to Self, you allow objects to perform operations on themselves.
Owner (Managed By): when you grant permissions to Owner, you grant them to the user or security group specified in the Managed By property of an object.
Manager: when you grant permissions to Manager, you grant them to the user or security group specified in the Manager property of an object.
Secretary: when you grant permissions to Secretary, you grant them to the user or security group specified in the Secretary property of an object.
Assistant: when you grant permissions to Assistant, you grant them to the user or security group specified in the Assistant property of an object.
| If Security Role trustees or objects on which a Security Role was assigned are renamed or moved, Security Roles are still effective for them. |
Parent Roles are used to facilitate security administration. When you specify a Parent Role for a Security Role, the Security Role inherits all permissions from the specified Parent Role. If the Parent Role also has Parent Roles, the permissions of these Roles are inherited too. Moreover, you can specify as many Parent Roles as you need.
If you do not want a Security Role to be effective for a certain period of time, you can disable it. The 
icon indicates disabled Security Roles. If a Parent Role is disabled, the permissions inherited from it by another Role remain enabled.
To simplify Security Roles management, built-in Security Roles are provided with Softerra Adaxes. Built-in Security Roles are created for some typical positions and tasks such as Human Resources Manager or Help Desk. Every built-in Security Role has a unified set of permissions necessary for that position or task. This set of permissions can be customized to meet your needs.
For information on built-in Security Roles and their assignment details, see Built-In Security Roles.
| Security Roles permissions are not written to the security information stored in Active Directory. These permissions are applied only when working via Adaxes service and are stored in it. |
See Also