The following sections describe the prerequisites of installing Active Roles:
The following sections describe the prerequisites of installing Active Roles:
Active Roles requires Microsoft .NET Framework 4.8.
The Administration Service requires Microsoft SQL Server or Azure SQL database server. You can install SQL Server on the Administration Service computer or on a different network computer. If you do not have Microsoft SQL Server deployed in your environment, download one of the versions officially supported by Active Roles (as listed in System requirements) from the Microsoft Download Center.
Azure SQL Database variants supported in Active Roles are Azure SQL database, Azure SQL Managed Instance, and Azure SQL Elastic Pool.
Now that you have access to SQL Server, you can install the Administration Service.
Use the following checklist to ensure that you are ready to install the Administration Service.
Item to Check |
Description |
Administration Service computer |
The Administration Service can be installed on any computer that meets the hardware and software requirements. It is not mandatory to install the Administration Service on a domain controller. However, the Administration Service computer must have reliable network connections with at least one of the domain controllers for each managed domain. |
SQL Server |
The Administration Service requires Microsoft SQL Server. One Identity recommends to have SQL Server and the Administration Service on different systems with reliable network connection. Administration Service can now be configured on Azure databases, namely Azure SQL database, Azure SQL Managed Instance and Azure SQL Elastic Pool. One Identity recommends to have proper network topology to allow the Azure database configuration. |
Administration Service account |
The Administration Service logs in with the account that you specify during installation. The account must have sufficient rights for Active Roles to function properly. For more information on the minimum required permissions, see Minimum required permissions for the Active Roles service account. Active Roles uses the Administration Service account when accessing a managed domain unless an override account is specified when registering the domain with Active Roles. Therefore, the Administration Service account must have the appropriate rights in any domain for which an override account is not specified. Additionally, the Administration Service account must have sufficient permissions to publish the Administration Service in Active Directory. Information about how to configure the Administration Service account and an override account can be found later in this document. |
Account used for connection to SQL Server |
When installing the Administration Service you may configure it to use; Windows authentication or SQL Server authentication or Azure AD authentication. If you choose Windows authentication, the connection is established using the Administration Service account. In this case, the service account must be, at minimum, a member of the db_owner fixed database role and have the default schema of dbo in the Active Roles database. If you choose SQL Server authentication, the connection is established with the login you are prompted to specify when installing the Administration Service. This login must at minimum be a member of the db_owner fixed database role and have the default schema of dbo in the Active Roles database. For connecting to Azure SQL database variants like SQL database and Elastic Pool database using SQL server authentication, the login must be a member of the dbmanager fixed database role and have the default schema of dbo in the Active Roles database. If you choose Azure Active Directory authentication, the connection is established with the login you are prompted to specify when installing the Administration Service. For more information on what permissions must be granted to the account for connection to SQL Server, see SQL Server permissions. |
Active Roles Admin |
Active Roles Admin is a group for which Active Roles does not perform permission checking. If the Administration Service itself has sufficient rights to perform a certain task, then Active Roles Admin can also perform that task using Active Roles. In addition, Active Roles Admin is authorized to perform any task related to the Active Roles configuration, such as adding managed domains and managing replication settings. Therefore, the membership in the Active Roles Admin group should be restricted to highly trusted individuals. By default, Active Roles Admin is the Administrators local group on the computer running the Administration Service. You can change this setting when installing the Administration Service. |
To properly perform operations on objects on behalf of delegated users, the Active Roles service account requires a number of permissions. One Identity recommends that you give the Active Roles proxy account the Domain Admin membership to ensure that Active Roles has all the required access.
You can separate the tasks managed by the Active Roles service account by using domain management to specify different accounts for the Active Roles service and for managing the domain.
The service account credential has five main roles:
Accessing local resources on the Active RolesAdministration Service host. This requires the Active Roles service account to be a member of the Administrators group on the computer running the Administration Service.
Creating the Service Connection Point in Active Directory.
After configured, the Administration Service attempts to publish itself in Active Directory, so that Active Roles clients can automatically discover the Administration Service instance.
NOTE: While this functionality is not critical, if the service publication permissions are not provided, Active Roles clients will not be able to automatically discover the Active Roles Administration Service instance. However, they can still connect to the Administration Service if they specify in Active Roles Console either the service name or the IP address of the computer running the instance.
For more information, see Service publication in Active Directory.
Running all script modules under the security context of the Active Roles service account. The permissions that custom scripts require will vary according to the needs of the scripts, so review them on a case-by-case basis as a best practice security model.
(Optional) Connecting to the Microsoft SQL database. This step might also require specifying an SQL authentication credential.
In some configurations, assigning these permissions to the service account is optional, as it requires specifying an SQL authentication credential and assigning the necessary permissions to that SQL authentication credential.
For more information on the necessary SQL Server permissions, see SQL Server permissions.
(Optional) Synchronizing native permissions to Active Directory. Perform this step only if Active Roles is configured to do so.
The Active Roles service account must have the Read Permissions and Modify Permissions rights on the Active Directory objects and containers where it is needed to use the Active Roles security synchronization feature.
NOTE: If you use the service account for domain management, you must also give the service account the permissions for domain management accounts.
NOTE: Due to a known issue (275523), in the Active Roles Console, in Active Directory > <domain-name> - Deleted Objects, opening the Advanced Properties of a deleted object and selecting the Show all possible attributes check box results in an error message and stops the Active Roles Service.
As a workaround, One Identity recommends adding your service account as a member of the Domain Admins group.
|
Permissions |
Requirement reason |
Affected features |
---|---|---|---|
SQL Server |
db_owner |
Required to use the Configuration and Management History databases. |
All Active Roles features that rely on the database (for example, virtual attributes, workflows, policies, Management History, and so on). |
db_creator |
Required by the Active Roles Service to create the Configuration and Management History databases. You can omit this permission if you pre-create the database. |
Creating the database with the Active Roles Installer during initial configuration. | |
db_datareader |
Required by the source database when importing databases. |
Database import | |
Active Roles Server Local Computer (lusrmgr.msc) |
Member of Administrators group on local computer |
Required by the Administration Service account to access local resources on the computer. |
Active Roles requires this permission to function properly. |
|
Permissions |
Requirement reason |
Affected features |
---|---|---|---|
ADSI Edit (adsiedit.msc) |
In the System/Aelita sub-container:
In the System container:
|
Required by the Active Roles Service to publish itself to Active Directory. These permissions are not mandatory, but they help clients automatically discover the Active Roles Service. |
Service publication |
Replicating directory changes on the following AD partitions:
|
Active Roles Service monitors the AD partitions with directory synchronization (DirSync), and requires this permission to enable domain management capabilities. |
Domain management capabilities | |
For the Microsoft Exchange container:
|
You can set this permission in the Configuration/Services/Microsoft Exchange container via ADSI Edit. It is required for Exchange management. You do not need to set this permission if the service account is a member of the Domain Admins or the Organization Management group. |
Exchange management tasks | |
For AD:
|
Required to modify system-provided AD permissions. |
Synchronizing system-provided permissions to AD. | |
Access to managed AD LDS instances |
Commands running under the Active Roles service account's context (for example, scheduled tasks or script modules) are limited by the service account's permissions. Set these permissions based on your needs for the tasks that Active Roles must perform. |
Managed AD LDS instance | |
Active Directory Users And Computers (dsa.msc) |
Full Control on msFVE-RecoveryInformation objects |
Required to access BitLocker recovery. |
BitLocker recovery |
Permissions to managed domain |
Commands running under the Active Roles service account's context (for example, scheduled tasks or script modules) are limited by the service accounts permissions. Set these permissions based on your needs for the tasks that Active Roles must perform. The permissions of the domain management account can also limit Active Roles capabilities. |
Managed domain | |
Account Operators security group |
Required for account management. |
Account management tasks | |
Exchange Server |
Recipient Management role group |
Required for Exchange management. For more information, see Manage role group members in Exchange Server in the Microsoft Exchange Server documentation. |
Exchange management tasks |
Enable to use remote Exchange Management Shell |
Required for Exchange management. For more information, see Enable Remote Exchange Management Shell for a User in the Microsoft Exchange Server PowerShell documentation. NOTE: This permission does not work with gMSA accounts. |
Exchange management tasks | |
CMD (Dsacls) |
View/Write permission for the Deleted objects container |
For view permission only, run the following command: dsacls "CN=Deleted Objects,DC=Domain,DC=com" /g DOMAIN\YourUser:LCRP For write permission, run the following commands: dsacls "CN=Deleted Objects,DC=Domain,DC=com" /g DOMAIN\YourUser:WPCC dsacls dc=Domain,dc=com /g "YourUser:ca;Reanimate Tombstones" |
Deleted objects container view |
File Servers |
Server Operators or Administrator group membership on file servers hosting home folders. |
Required to manage home folders within Active Roles. |
Home folder operations (for example, autoprovisioning or deprovisioning). |
After configured, the Administration Service attempts to publish itself in Active Directory, so that Active Roles clients can automatically discover the Administration Service instance.
NOTE: While this functionality is not critical, if the service publication permissions are not provided, Active Roles clients will not be able to automatically discover the Active Roles Administration Service instance. However, they can still connect to the Administration Service if they specify in Active Roles Console either the service name or the IP address of the computer running the instance.
Service publication requires that the service account have the following permissions in the domain of the computer running the Administration Service and in every managed domain as well:
Permissions on the System container:
Delete the serviceConnectionPoint objects
Write permission for the keywords attribute of the serviceConnectionPoint objects
Permissions on the System > Aelita container:
Create Container Objects
Create serviceConnectionPoint Objects
If the service account has Domain Administrator rights, it has the required permissions by default. Otherwise, provide these permissions to the account with the system-provided ADSI Edit tool of the Windows Server operating system.
To grant service publication permissions for Administration Service in Active Directory
Open the ADSI Edit console and connect to the Domain naming context.
In the console tree, expand the System container, right-click the Aelita subcontainer, then click Properties.
If the Aelita container does not exist, create it by right-clicking System, selecting New > Object, then in the Create Object wizard, selecting the Container class and entering Aelita for the cn value.
In Properties > Security, click Advanced.
In Advanced Security Settings > Permissions, click Add.
On the Permission Entry page, configure the permission entry:
Click the Select a principal link, and select the desired account.
Verify that the Type box indicates Allow.
Verify that the Applies onto box indicates This object and all descendant objects.
In the Permissions area, select the Create container objects and Create serviceConnectionPoint objects check boxes.
To close the Advanced Security Settings dialog, click OK.
To close the Properties dialog, click OK.
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Termini di utilizzo Privacy Cookie Preference Center