Best Practicies: Distributed Deployment Scenario
This is a second post concering ActiveRoles deployment best practicies and as proviously I have described centralized deployment scenario, let’s now talk about distributed one, that is each site has its own ActiveRoles Server instance and each instance is deployed with its own Configuration DB/ Management History DB and Web Interface/IIS:
Management History DB
Management History DB’s will provide 7 day history of changes done to the AD objects.
Management History DB will be stored as a part of Configuration DB (per ActiveRoles admin service), like shown it the picture above. Approval Workflow is stored in Management History DB.
For complete long-history auditing of ARS activity and answering the question ‘Who did what against AD via ARS door?’ reporting should be implemented using EDM event log. To collect, long-term storage and report against the log it is recommended, for example, InTrust solution.
Data Collector is recommended only for scenario when all EDM Logs are close to Data Collector box, so it can pull them and store in reporting DB.
Concerns/limitations/notes
Note: If each ActiveRoles instance is managing all managed domains (AMERICAS, EMEA and APAC) then:
- Regionally local changes calls executed against locally located DC of local region domain will appear immediately and no additional slowdown expected
- Cross-site changes calls executed against locally located DC of remote region domains will appear/available in the remote region sites after replication - this is an additional slow-down (unless attribute is replicated via forced replication)
For details on attributes replication on scheduled basis (Description, sAMAccountName, UPN etc.) and via forced replication (userAccountControl: unlock, enable/disable, password reset etc.) see http://technet.microsoft.com/en-us/library/cc772726.aspx
This per-site deployment model will provide a more efficient and fast way for AD changes initiated via the ‘ARS door’ to take an effect by minimizing or eliminating wait time for cross-site AD replication.
All instances will provide the same AD access delegation workflow and can be treated as a single AD Delegation mechanism. Sharing the same configuration settings between instances will be achieved by means of SQL replication.
Presence of two Admin Services per site will provide failover and load balancing capabilities.
For Failover purpose each instance will be independent from a hardware and software standpoint by having its own dedicated Administration Service, Web Service and SQL.
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.
Sample scenario and technical background:
- user JSmith is a member of Help Desk Security Group which is granted a specific role access to AD through ARS Delegation workflow (to unlock accounts and reset passwords) on specific AD scope (OU=NYC Users).
- JSmith opens IE, browses to ARS Website, runs search for user JTailor, and unlock his account.
- In the background: IIS Web Service calls Admin Service. Admin Service checks JSmith access rights inside ARS workflow stored in SQL Configuration db and (if confirmed positive) runs search for user JTailor against DC and executes ‘unlock user account’ against the DC under ‘proxy’ ARS Service Account.
ActiveRoles Administration Service
ActiveRoles Administration Service runs as a windows service with the name “Quest Active Roles Administrative Service” under ARS Admin Service Account and controls Managed Domains that are registered in ActiveRoles Server.
ARS Administration Service utilizes the following objects and resources:
Domain Administrative Service Account
Domain Administrative Service Account is a proxy service account used for read/write access to DC
DirSync Domain Controller
DirSync DC is a domain controller that ARS Administration Service uses to communicate with Active Directory. By default, Administration Service selects any available (nearest) DC for a managed domain. When DirSync DC becomes unavailable, Service selects another DC, if “use any available DC (default)” or “use any available DC from this site” options are enabled.
DirSync DC is used by Service to load directory data, receive change notification events from AD, lookup information in AD and execute other AD operations. Also, Service uses DirSync DC by default for all client operations (requested by a particular connected client), unless client specifies preferred operational DC.
Operational Domain Controller
Operational DC is a DC, specified by client application that is used by Service to execute AD operations, requested by that client. When Operational DC becomes unavailable, ARS components display an error message and provide an ability to select another DC.
In this case it is recommended to choose nearest Operational DC in the site, if available.
User can select “Any writable Domain Controller” option which means usage of DirSync DC for that client. Operational DC context is stored between sessions by ARS components.
Changing Operational DC feature is similar to Active Directory Users and Computers MMC snap-in DC-focusing: the change request will be applied through the specified DC. Consideration is AD replication between regional sites. Choose the DC that ‘waits’ for the changes to be applied
ARS Administration Service utilizes Windows event log to trace activities, such as binds, change requests, restarts etc. Event log is one of compliance opportunities in ARS.
SQL Database
Total of six SQL database servers will be deployed across the world-wide company enterprise according to a distributed regional model: two instances in each of three major regions. Each Admin Service will have own dedicated SQL database server which will be deployed on the dedicated Windows Server for failover reasons.
Sharing the same configuration settings across all deployed ARS instances is achieved by means of SQL replication.
Each SQL Server will hold two databases: Configuration DB and Management History DB. By default Management History db is a part of Configuration db in order to reduce loading and size of Configuration db. For procedure how to split History DB from Configuration DB refer to section 8.3 of the current document.
Configuration DB contains whole AD Delegation Workflow: Access Templates, Policies, Managed Units Rules, Virtual Attributes, etc.
History DB contains Management History of AD Object (by default last 7 days) and Approval Requests Workflow.
There will be single database with assigned SQL Role Publisher and five databases with Subscribers roles. ARS Management MMC snap-in provides easy ‘one-click’ user interface to establish and break replication between databases:
- Promote Publisher (from Standalone). See section 8.4 of the current document for details
- Add Subscriber (to existing Publisher (makes Standalone to become Subscriber)
- Remove Subscriber (from Publisher (makes Subscriber to become Standalone)
- Demote Publisher (to become Standalone)
For performance tuning, please refer to ActiveRolesServer_6.1_Replication (English).pdf document, located at distribution CD. The document covers general SQL replication model, permissions, best practices and troubleshooting. Note that because of database replication is done on SQL side any SQL best practices are applied.
Before establishing replication make sure that SQL version and Service Pack level are the same on both sides.
Promoting Configuration DB to Publisher makes both Configuration DB and History DB to become Publisher. Later if needed it is possible to break History DB replication while Configuration DB is still replicating. This is performed by making History DB standalone while Configuration DB still being a Publisher. However, this approach is not recommended.
Replication Status Check: ActiveRoles Server displays the replication status and last action message information from the SQL Server. ARS uses continuous mode for replication, that is why its normal status is ‘In Progress’. If you see the last action message as ‘Waiting 60 second(s) before polling for further changes’ then consider it as replication has been finished.
Web Interface
Each deployed Admin Service will have one or more websites which provide an end-user Web interface for managing AD (to some extent this is similar to Active Directory User and Computers MMC snap-in).
Total of six Web Services will be deployed across the world-wide company enterprise according to a distributed regional model: two instances in each of three major regions. Web Services will be deployed on the same Windows Servers running the Administration Services or they can be installed on dedicated servers. In each region two Web Services will provide load balancing and failover capabilities. If each Administration Service will have one dedicated Web Service, later it will be possible to introduce another Web Server for the same Administration Service if performance needs speeding-up. Each Web Service will have several websites which share the same configuration settings replicated via SQL replication. So, it is sufficient to customize any single instance of the website and the changes will propagate across the whole ARS deployment to the rest of websites.
Customization: a big advantage of the Web User Interface is that it provides out-of-box customization capabilities so it can be configured to show or hide certain fields or attributes to the end-user including custom (extended) schema attributes.
Installing Website
There are three built-in Web Interface templates: Administration, Help-Desk and Self-Service. You can use these templates to create several customized instances of web interface for different purposes, i.e. several help desk sites with different customization.
Note, that websites configuration is stored in Configuration DB and replicated across SQL replication group.
If you want to create a new website with the same customized configuration, you need to run Web Interface Site Configuration utility and create a new website using ‘existing configuration’ schema.Microsoft Internet Explorer 6.0 and later is officially supported Web Interface browser.
Hardware
Total of twelve dedicated Windows Servers will be deployed across the world-wide company enterprise to install six ARS instances according to a distributed regional model: four servers in each of three major regions. Each ARS instance contains one server with Administration Service, Web Interface and SQL Server installed. Choice of the configuration was dictated by load balancing, performance, failover and disaster recovery reasons. If using SQL Server clustering, then it is recommended to have separate physical server for SQL Server.
Data Collector will be installed on dedicated SQL Server and will collect logs from all Admin Servers. Separate SQL server will be used to store reporting database.
This deployment scenario is recommended for large international companies, which offices are distributed across different geographical locations.