Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Active Roles 8.0 LTS - Quick Start Guide

Introduction Active Roles Setup package Active Roles uninstallation System Requirements Deploying the Administration Service Deploying user interfaces Installing additional components Upgrade of an earlier version Performing a pilot deployment Deployment considerations Silent installation of Active Roles components Configuring Active Roles to Manage Hybrid Active Directory Objects Active Roles on Windows Azure VM

Availability and redundancy

One of the benefits of Active Roles is that administrators do not need permissions on Active Directory to perform user management and other tasks. This forces administrators to use Active Roles and assures secure administration with the enforcement of “Rules and Roles” provided by Active Roles. However, this lack of AD permissions might be a problem if the Administration Service becomes unavailable. The impact of this potential problem depends on the specifics of the situation, but the problem can be addressed with the following guidelines.

Major sites

Two guidelines should be followed for major sites:

  • Our customers typically deploy two Administration Services per major location/site where AD data administration and user management is performed. This redundant service solution would be effective if both the primary Administration Service and all connections to other sites failed.

    Again, organizations should use their administration framework and their experience with other management services, such as SMS, to determine the need for an Administration Service at a site.

  • Most customers do not place all of their Administration Services at one location/site. If access to that one location/site should fail, all Administration Service of AD would stop. Instead, they install Administration Services at two or sometimes more sites.

    In most scenarios, even if the server hosting the Administration Service fails, connections to other sites will be maintained. Administrators can access Administration Services at another site and force AD replication to make the changes appear on the local domain controller as soon as possible.

Remote sites

Three approaches can be used for remote sites where either no or only a low level of administration work is performed (e.g., creating a few users, updating employee information, or unlocking accounts). One or more approaches can be used, and they should eliminate the possible problem of administrators not having AD permissions and an Administration Service failing. The approaches used depend on business workflow.

  • If few AD administration tasks are performed at a site, then local administrators might access a remote Administration Service. Administrators at remote sites can access an Administration Service at a major location/site. If necessary, native Windows administrative tools can be used to force AD to replicate the changes so that they appear on the local domain controller as soon as possible.
  • If local administrators at a site do not normally need access to AD, then an Administration Service would not have to be installed in that site. An administrator at a major site can make changes for a user at a remote site, and if necessary forced replication can cause the changes to appear quickly at the user’s local domain controller.

    NOTE: With Active Roles user interfaces, the administrator can deliberately choose the domain controller where to apply the changes, thus eliminating data replication delays.

  • An organization might provide one or more administrators at each site with permissions to AD. For example, if a site has five administrators, one administrator would be given permissions to AD. This solution would be acceptable for most sites, except for small sites managed by very low-level administrators.

    NOTE: Active Roles allows administrators to push (synchronize) permissions from Active Roles to Active Directory, thus making it easier to manage permissions to AD.

Replication traffic

Active Roles employs the Microsoft SQL Server to maintain the configuration database. The replication capabilities of SQL Server facilitate the implementation of multiple equivalent configuration databases used by different Administration Services.

Replication traffic can be judged by considering what is replicated and what is not. Active Roles configuration information is replicated only if it is changed. This means that if administrators are not creating Managed Units, Access Templates, Policies and delegating permissions that often, there is not much replication traffic.

Locations and number of services

After considering the major factors that might influence the locations and number of Administration Services, organizations should have a network diagram that illustrates a high-level design for the Active Roles deployment.

The following high-level sample network diagrams illustrate potential Active Roles deployments using the guidelines described earlier.

Centralized

This diagram shows a centralized network and workflow (the ARS abbreviation refers to the Active Roles Administration Service).

In this centralized structure, all AD data management is done from the corporate headquarters by a group of network administrators and the Help Desk staff. The headquarters is a large campus location with several well-connected sites. Most employees work at the headquarters. Large remote sites will have networking personnel who are responsible for the tasks such as hardware and software setup and maintenance. Small remote sites are staffed by non-technical employees. Network maintenance for these sites is done by IT staff that travels to them or by contractors.

The number of Administration Services depends on the number of managed objects and administrators. In the diagram, there is one dedicated Active Roles Administration Service (Dedicated ARS) and two Administration Services on shared hardware. This number should assure both availability and redundancy. Other services on the shared hardware include printing and applications.

A small number of administrators use the Active Roles console, while the majority of administrators and all Help Desk personnel use the Web Interface.

Typically, customers do not install all Administration Services at one location, but in this case, one or both of the following business workflow and technical factors over rule that guideline:

  • The remote sites are lightly populated and require very little AD data management work.
  • It is determined that if the connection to the central site fails, the organization’s primary concern would be restoring the connection, not managing AD.

Distributed with no remote management

This diagram shows a distributed network and workflow (the ARS abbreviation refers to the Active Roles Administration Service).

Figure 2: Distributed network and workflow

In this scenario, AD data management is performed at major locations by a group of network administrators and the Help Desk staff. These locations can be campuses or single locations connected by LAN/WAN connections.

Large remote sites have networking personnel who are responsible for tasks such as hardware and software setup and maintenance. Small remote sites are staffed by non-technical employees. Network maintenance for these sites is done by IT staff that travels to them or by contractors.

Again, the number of Administration Services depends on the number of managed objects and administrators. In the diagram, there is one dedicated and one shared Administration Service per location. This setup assures both redundancy and availability at each major location and through out the network. If one Administration Service fails, the other Service at the location can be used. If both services at a location fail, AD data management can be done at the other location. As long as the connections function, administrators at the failed location can access the Administration Services at the functioning location.

At both locations a small number of administrators use the Active Roles console, while the majority of administrators and all Help Desk personnel use the Web Interface.

Distributed with remote management

This diagram illustrates a highly distributed network and workflow (the ARS abbreviation refers to the Active Roles Administration Service).

Figure 3: Highly distributed network and workflow

In this scenario, AD data management is performed at all locations. These locations can be campuses or single locations connected by LAN/WAN connections. The work is done by a group of network administrators and the Help Desk staff. Work group managers perform very low-level work such as access to specific file directories and distribution lists.

The number of Administration Services depends on the number of managed objects, administrators, and locations. In the diagram, there is one dedicated and one shared Administration Service at the large locations. This setup assures both redundancy and availability at each major location and through out the network. If one Administration Service fails, the other server at the location can be used. If both Administration Services at a location fail, AD management can be done at the other location. As long as the connections function, administrators at the failed location can access the Administration Services at the functioning location.

A third, midsize location has an Administration Service installed on shared hardware. Administrators at this location use a Web interface, so the hardware also hosts IIS. An Administration Service was installed at this location because the location had a significant number of users that needed AD management work and Help Desk support. Placing an Administration Service in this location balances the load on the services while improving redundancy and availability. If this location and the network grow, the need might develop for establishing connections and replication between the three largest sites.

Administrators at the smallest locations access the Administration Services at the large locations via the Web Interface. The reason for this is the number of users and administrators and their workload.

At both large locations a small number of administrators use the Active Roles console, while the majority of administrators and all Help Desk personnel and work group managers use the Web Interface.

Physical design

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.

Several software components must be considered when deploying Active Roles:

  • AR Service  The Active Roles Administration Service (AR Service) communicates directly with an Active Directory domain controller (DC), and is responsible for making all changes to Active Directory. The DC to which the AR Service speaks is selected automatically and can be changed by the Active Roles user. The ARS Service is also responsible for performing access checks to prevent non-authorized users from connecting to Active Roles interfaces and to ensure that authorized users are performing tasks according to the role they hold and the rules that have been put in place.
  • Console  the Active Roles console provides an MMC-based interface to configure Active Roles as well as perform administration of Active Directory. The Console only connects to the AR Service and is not capable of making changes directly in Active Directory.
  • Web Interface  Three Web Interfaces are provided with Active Roles out of the box: the Web Interface for Administrators; the Web Interface for Help Desk; and the Web Interface for Self-administration. During the setup of the Web Interfaces the administrator must make a decision to connect the Web Interface to a specific AR Service or allow the AR Service to be selected dynamically. All of the Web Interfaces connect only to the AR Service and are not capable of making changes directly in Active Directory.

The decision where to place servers running the Active Roles software components should leverage the strengths of the existing network and the associated IT Service structure.

Deploying for fault tolerance and load balancing

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.

Centralized deployment

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:

  • All the Active Roles (AR) instances are placed in a single location. Each instance is hosted on a server running the AR Service along with a Web server (IIS) running the Web Interfaces.
  • All Active Roles instances share the same database for storing the configuration and management history data (Configuration DB and Management History DB).
  • The EMEA and APAC branch offices use the Web Interface to perform administrative tasks, help desk operations or self-service actions.
DC focusing

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:

  • Regionally local changes calls are executed against locally-placed DC.
  • Cross-site changes calls are executed against DC located at the target site.

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.

Distributed deployment

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:

  1. Where will administration be performed?
  2. How are domain controllers placed?
  3. What is the interface of choice for the administrators?

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:

  • Each of the three sites has two Active Roles (AR) instances deployed, for the sake of fault tolerance and load balancing.
  • Each Active Roles instance is hosted on a server running the AR Service along with a Web server (IIS) running the Web Interface.
  • Each Active Roles instance has a separate database for storing the configuration and management history data (Configuration DB and Management History DB).
  • 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 (in terms of SQL Server replication).
  • Administration is performed using the Web Interface on a per-site basis, by connecting Web Interface clients (Web browsers) to any of the two AR instances deployed within the site.

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.

DC focusing

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:

  • The AR instance normally applies Active Directory data changes to a DC found in the local site. This DC is referred to as Operational DC.
  • The AR instance normally retrieves the data changes that occur in Active Directory from a DC found in the local site. This DC is referred to as DirSync DC.

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.

SQL database

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.

Web Interface

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:

  • Default site for Administrators
  • Default site for Help Desk
  • Default site for Self-administration

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:

  • Create a new Web Interface site with an existing configuration. This option only allows you to select a Web Interface site configuration that already exists in your Active Roles environment. Use this option when deploying a new Web Interface instance to add an existing custom Web Interface site to that instance.
  • Create a new Web Interface site with a new configuration. This option only allows you to select one of the three built-in website templates, and creates a new Web Interface site configuration based on the template you select. Use this option to create a new Web Interface site on one of your Web Interface instances. On the other instances the new site should be deployed by selecting the site configuration you have created.

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.

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation