This section covers two typical installation configurations for Active Roles. In both installations the architecture is designed to maximize the effectiveness of the Active Roles software based on how the network is configured and how administrative duties are assigned.
In the same way Active Directory is not fault tolerant with a single domain controller Active Roles would not be fault tolerant when a single server running the AR Service is deployed. It is critical that at least two servers running the AR Service be deployed to have a fault-tolerant Active Roles environment. None the less, even in the worst case scenario where all AR Service instances fail, Active Directory will continue to function normally. The only result of a complete failure is that day-to-day administration or help desk functions may be interrupted until a server running the AR Service is brought back on-line.
An additional benefit of deploying multiple AR Service instances is that both the Console and the Web Interfaces will fail-over to a new AR Service if the first one becomes unresponsive. The user experience is slightly different depending upon which interface the user is using when the AR Service fails. Within the Console the user will notice the AR Service has failed and will only have to use the Connect command to get automatically connected to the next available AR Service. Users of the Web Interface will have a more seamless transition as the Web Interface fails over automatically to the next AR Service. One important item to note is that automatic failover only works if the option to use any available Administration Service was selected during the Web Interface setup.
It is possible to deploy the Web Interface and AR Service components on separate servers, for security concerns or business reasons. However, when the Web Interface and AR Service are deployed on separate servers, basic authentication is normally used to authenticate the Web Interface users, causing the user credentials to be transferred over the network in clear text. In this case we highly recommend that a secure (SSL) channel be configured on the server running the Web Interface to encrypt traffic between the server and the Web browser. However it is best to keep the AR Service and Web Interface components together, on the same server, for integrated authentication and better performance.
The first installation configuration is known as the Centralized model. In this model administration is controlled from a single larger site. In the centralized model the deployment places servers in one physical location. This allows all the AR Service instances to share a single configuration and management history database, or replicate their configuration changes to a partner, providing a fault tolerant configuration. While a centralized deployment may involve smaller physical locations or branch offices, administration is probably not usually performed from those locations.
Figure 4: Centralized deployment of Active Roles
This diagram illustrates a centralized deployment of Active Roles with the following characteristics:
Normally, the Active Roles Administration Service (AR Service) itself chooses the Active Directory domain controller (DC) to communicate with, which is the nearest DC by default. With a centralized deployment model, this means that the AR Service will select DC found in the same location where the corresponding AR instance resides, so even the regionally local changes calls (those submitted from the EMEA or APAC location) are performed against DC located in North America (rather than a locally-placed DC) thereby causing an additional slow-down due to Active Directory replication latency.
The preferred behavior would be as follows:
The appropriate choice of DC would ensure that the changes appear on the target site without an Active Directory replication related slow-down. Active Roles users can choose an appropriate DC by using the Change Operational DC command on the menu for the domain object, in the Active Roles console or Web Interface. If operational DC is explicitly specified by the user, the AR Service submits the change requests to that DC instead of the nearest DC.
The second installation configuration is the Distributed model where servers are deployed by analysis of how the network is configured and how administrative duties are assigned and performed.
In a distributed environment there are three primary criteria for the determination of the placement of Active Roles:
If both administrators and domain controllers reside in the same physical location, the AR Service should be placed in that location. In this situation either the Console or the Web Interface could be used by the administrators. However, if the Web Interface is the primary interface of choice, it is important to ensure that the AR Service the Web Interface connects to points to a domain controller in the same location so that changes are not passed over a WAN connection.
If the administrators reside in one location and domain controllers reside in another, the determining factor would be WAN reliability.
It is important to understand that the AR Service writes all administrative changes to a domain controller to which it has been associated. The critical point here is that Active Roles client applications never interface directly with a domain controller. Consequently it is more important that the AR Service be located close to its associated domain controller than where the client application is deployed in relation to the domain controller.
However, from either the Console or the Web Interfaces it is possible to choose a specific domain controller to which the AR Service writes the changes.
This diagram illustrates a distributed deployment of Active Roles with the following characteristics:
Total of six Active Roles instances are deployed across the world-wide enterprise, with two instances located in each of three major regions—North America, EMEA (Europe, Middle East and Africa), and APAC (Asia Pacific). This per-site deployment model provides an efficient way for Active Directory data changes initiated via Active Roles to take effect by minimizing wait time for cross-site Active Directory replication.
All Active Roles instances provide the same Active Directory access delegation workflow and can be treated as a single delegation mechanism. Sharing the same configuration settings between instances is achieved by means of SQL replication.
Each region has two Active Roles instances for failover and load balancing purposes. For failover purposes each instance is independent from a hardware and software standpoint by having its own dedicated AR Service, Web Interface (IIS) and SQL Server. This deployment is flexible in regards to hardware extension: new hardware can be added into the project for load balancing or troubleshooting purposes without changing the deployment.
The AR Service normally selects the nearest Active Directory domain controller (DC) to communicate with. Therefore, the AR instance located in a given site normally communicates with a DC found in than site. This has the following implications:
By default, the AR Service chooses the same domain controller to hold the role of both the Operational DC and DirSync DC.
Figure 5: Active Roles Service - DC focusing
The AR Service is permanently listening to the DirSync DC for changes related to Active Roles dynamic configuration objects, such as Dynamic Groups and Managed Units. Every operation that involves the retrieval or modification of Active Directory data, requested by Active Roles client interfaces or by AR Service internal logic, is performed against this DC. The user can specify another DC for the client operations, by using the Change Operational DC command in the Active Roles console or Web Interface.
Each 10 minutes the AR Service validates the availability of the selected DirSync DC. If the AR Service identifies that the DC is not available, it selects another DC. Until the AR Service selects another DC, every user of Active Roles who does not explicitly specify the Operational DC will receive an error when trying to perform any operation with Active Directory.
If you have a single DC in the same site with the AR Service, and that DC becomes unavailable for some reason (for example, it was restarted), then the AR Service will select a DC from other site. After the DC in its home site becomes available, the AR Service will switch back to DC in its home site.
If you have multiple DCs in the same site with the AR Service, it will not randomly switch from one DC to other each 10 minutes. When other than the current DC is identified as the nearest DC, the AR Service will switch to the new DC only if the new one is in its home site and the current DC is located in another site, so the AR Service never switches between 2 available DCs in the same site.
By default, the AR Service selects any nearest available DC for a managed domain. This behavior can be configured on a per-Service or per-domain basis. To configure this behavior, use the DirSync Servers tab, on the property sheet for a Managed Domain object in the Configuration/Server Configuration/Managed Domains folder on the property sheet for an Administration Service object in the Configuration/Server Configuration/Administration Services folder, in the Active Roles console). If you choose the Only specified domain controller option and the specified DC becomes unavailable, the AR Service will not switch to other DC and the domain will be unavailable for management. For more information, refer to Active Roles Help: click Help on the DirSync Servers tab, or press F1 in the DirSync Server Selection dialog box that appears when you click Change on the DirSync Servers tab.
Total of six SQL Server instances are deployed across the world-wide enterprise to host the Active Roles database, with two instances located in each of three major regions—North America, EMEA, and APAC. Each AR instance has a separate SQL database. The databases are synchronized by means of SQL Server replication function. One of the database servers holds the Publisher role while the others are Subscribers to that Published.
Figure 6: Active Roles using SQL database
Active Roles normally uses the same database to store both the Configuration and Management History data. The Configuration data applies to the delegation and workflow related objects, such as Access Templates, Police Objects and Managed Units. The virtual attributes created with Active Roles are also stored as part of the Configuration data. The Management History data comprises history of changes that were made to directory objects via Active Roles. In addition, the approval, temporal group membership, and deprovisioning tasks are stored as part of the Management History data. Given a large volume of Management History data, it may be advisable to create a separate Management History database (see “Centralized Management History Storage” in the Active Roles Administration Guide).
Active Roles uses SQL Server merge replication to synchronize the Configuration and Management History data among the databases. One of the databases is configured on the SQL Server instance that holds the Publisher role; the remaining databases are configured as Subscriber role holders. The instructions on how to configure replication can be found in the Active Roles Administration Guide (see the “Configuring Replication” chapter). Separate instructions are provided in connection with replication of the Management History data (see “Replication of Management History Data” in the Active Roles Administration Guide). To successfully configure replication, ensure that all your SQL Server instances run the same version of SQL Server. If a SQL Server Service Pack is installed on one of the instances, the same Service Pack must be installed on all the instances.
Each of the six AR instances has a separate Web Interface installation, with the AR Service and Web Interface components running together, on the same server. A design where both the AR Service and Web Interface are installed on a single server takes advantage of integrated authentication, which allows domain users to access the Web Interface without being prompted for their user name and password.
Figure 7: Active Roles Web interface deployment
Total of six Web Interface instances are deployed across the world-wide company enterprise, with two instances installed in each of three major regions. In each region two Web Interface instances provide load balancing and failover capabilities. Initially, each AR Service has one dedicated Web Interface instance; later it will be possible to introduce another Web Interface instance for the same AR Service if performance needs to be increased.
Each Web Interface instance comprises several websites. The website configuration is synchronized among the Web Interface instances by means of SQL database replication (the website configuration settings are stored as a part of Active Roles configuration data). This allows you to customize a website on a single Web Interface instance and be sure that the replication function will apply the customization changes across all Web Interface instances.
The Web Interface provides rich customization capabilities out of the box, so Web Interface sites can be easily configured to show or hide certain fields or attributes to the end-user, including custom (extended) schema attributes. It is also possible to add or remove commands, create new forms or customize existing pages by adding forms (tabs) and form fields (entries).
The Web Interface ships with three built-in website templates:
You can use these templates to create new Web Interface sites and then customize each of the new sites as needed. Thus, you may deploy multiple Help Desk sites, having each customized individually. To create new Web Interface sites and site configurations Active Roles provides the Web Interface Sites Configuration wizard. You can open the wizard from the Start menu on any server running the Web Interface. The wizard is mainly intended to:
When deploying a new Web Interface instance, it is important to understand that only three default Web Interface sites are installed out of the box. To add a custom Web Interface site to a newly installed Web Interface instance, you should use the Web Interface Sites Configuration wizard.
Launches the Setup wizard.
Comma-separated list of Active Roles components to install.
Comma-separated list of Active Roles components to remove.
Path to the desired install folder.
ActiveRoles.exe /quiet /install /IAcceptActiveRolesLicenseTerms
ActiveRoles.exe /quiet /install ADDLOCAL=Service,Console /IAcceptActiveRolesLicenseTerms
ActiveRoles.exe /quiet /install ADDLOCAL=Console TARGETDIR=D:\Active Roles\ /IAcceptActiveRolesLicenseTerms
ActiveRoles.exe /quiet /modify ADDLOCAL=Web
ActiveRoles.exe /quiet /modify REMOVE=Console
ActiveRoles.exe /quiet /repair
ActiveRoles.exe /quiet /uninstall
ActiveRoles.exe /quiet /forceuninstall
ActiveRoles.exe /quiet /uninstall /forcerestart
ActiveRoles.exe /quiet /repair /forcerestart
When a user signs up for a Microsoft cloud service such as Azure Active Directory, details about the user’s organization and the organization’s Internet domain name registration are provided to Microsoft. This information is then used to create a new Azure AD instance for the organization. The same directory is used to authenticate sign in attempts when you subscribe to multiple Microsoft cloud services.
The Azure AD instance of the organization, also called the Azure AD tenant, stores the users, groups, applications, and other information pertaining to an organization and its security. To access the Azure AD tenant, we need an application that is registered with the tenant. Active Roles uses this application, also called the Azure AD application, to communicate to Azure AD tenant after providing the required consent.
The Active Roles Web Interface and Management Shell can be used to perform the Azure AD configuration tasks. The new feature in Active Roles enables you to add or modify existing tenants and applications to the management scope through the web interface and Management Shell.