To uninstall Active Roles and its components
- On the system where Active Roles is installed, go to the Control Panel, and navigate to Programs| Programs and Features.
- In the list of installed programs, right-click on One Identity Active Roles, and click Uninstall/Change.
The Active Roles Setup window is displayed.
- Click Remove.
The Active Roles Setup - Ready to Remove dialog box is displayed.
- Click Remove, to uninstall Active Roles.
NOTE: Alternatively, click Modify to add or remove the Active Roles components. Click Repair to re-install the corrupt files in Active Roles.
Active Roles Setup includes the following components:
- Administration Service
- Console (MMC Interface)
- Web Interface
- Management Tools
- Synchronization Service
The Active Roles Release Notes document, included on the Active Roles distribution media, provides information about the hardware and software requirements for each of these components.
The Active Roles distribution media includes separate installation packages for additional components, such as Add-in for Outlook, Collector and Report Pack. The system requirements for these components are as follows:
Table 2:
Active Roles Add-in for Outlook requirements
Microsoft Office Outlook |
Microsoft Office Outlook 2010 or later (32-bit)
NOTE: The Active Roles Add-in for Outlook does not support the 64-bit version of Microsoft Office Outlook. |
Other Microsoft Office features |
- .NET Programmability Support for Microsoft Office Outlook
- Microsoft Forms 2.0.NET Programmability Support
|
Microsoft .NET Framework |
Microsoft .NET Framework 4.7.2 |
Table 3:
Active Roles Collector and Report Pack requirements
Operating system |
Any operating system listed in requirements for Active Roles Console |
SQL Server |
Any SQL Server version listed in requirements for Administration Service |
SQL Server Reporting Services |
Any SQL Server version listed in requirements for Administration Service |
Microsoft .NET Framework |
Microsoft .NET Framework 4.7.2 |
Active Roles ADSI Provider |
Management Tools of the current Active Roles version must be installed |
Use the following checklist to ensure that you are ready to install the Administration Service.
Table 4: Checklist: Deploying the Administration Service
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 on with the account that you specify during installation. The account must have sufficient rights for Active Roles to function properly.
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 at minimum be 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 later in this document. |
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. |
As Active Roles performs operations on objects on behalf of delegated users, the Active Roles service account requires adequate permissions. It is recommended that the Active Roles proxy account be given the Domain Admin membership to ensure that Active Roles has all the required access.
It is possible to separate the tasks managed by the service account from Domain management by specifying different accounts for the service and for managing the Domain.
The service account credential has five main roles, two of the roles are optional:
-
Accessing local resources on the Active Roles Administration Service host.
-
Creating the Service Connection Point in Active Directory- This functionality is non-critical and do not prevent the service from functioning as expected. Active Roles clients do not automatically discover the Active Roles Administration Service. Active Roles Clients will still be able to connect if the service name or IP address is available.
-
All script modules are executed under the security context of the Active Roles Service Account.
-
Connecting to the Microsoft SQL database- This is optional, as an SQL Authentication credential may also be specified.
- Synchronizing native permissions to Active Directory- This is required only if Active Roles is configured to do so.
Access to the Administration Service computer
The service account must be a member of the Administrators group on the computer running the Administration Service.
Service publication in Active Directory
The Administration Service attempts to publish itself in the Active Directory. This enables Active Roles clients to automatically discover the Administration Service. This functionality is non-critical and if permissions are not granted, this will not prevent the service from functioning as expected, instead Active Roles clients won't automatically discover the Active Roles Administration Service. They will still be able to connect if the service name or IP address is available. Service publication requires that the service account have the following permissions on the Aelita sub-container of the System container in the domain of the computer running the Administration Service:
-
Create Container Objects
-
Create serviceConnectionPoint Objects
-
Delete the serviceConnectionPoint objects in the System container
-
Write permission for the keywords attribute of the serviceConnectionPoint objects in the System container
Along with the mentioned permissions, the service account (or the override account, if specified), must have these permissions on the Aelita sub-container of the System container in every managed domain. If an account has the domain administrator rights, then it has the required permissions by default. Otherwise, provide the permissions to the account by using the ADSI Edit console. The following instructions apply to the ADSI Edit console that ships with Windows Server 2016, Windows Server 2019, or Windows Server 2022.
To grant permissions for Administration Service publication 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, and then click Properties. If the Aelita container does not exist, create it: right-click System, point to New, click Object, and then, in the Create Object wizard, select the Container class and specify Aelita for the cn value.
-
On the Security tab in the Properties dialog box, click Advanced.
-
On the Permissions tab in the Advanced Security Settings dialog box, 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.
- Click OK
-
Click OK to close the Advanced Security Settings dialog box, and then click OK to close the Properties dialog box.
All script modules are executed under the security context of the Active Roles Service Account
The permissions needed by custom scripts will vary according to the needs of the scripts, and ideally should be reviewed on a case-by-case basis as a Best Practice security model.
Connecting to the Microsoft SQL database
In some configurations, assigning these permissions to the service account are optional, as a SQL Authentication credential may also be specified and the necessary permissions then be assigned to that SQL Authentication credential. For more information on the necessary SQL Server permissions, see SQL Server Permissions topic.
Synchronizing native permissions to Active Directory
The service account must have the Read Permissions and Modify Permissions rights on the Active Directory objects and containers where it is desired to use the Active Roles security synchronization feature.