Quest ActiveRoles Server

(1)

TECH BRIEF

Deployment Best Practices

Written by

Quest Software, Inc.

Quest® ActiveRoles® Server

(2)

This document contains proprietary information protected by copyright. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose without the written permission of Quest Software, Inc. (“Quest”).

The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR

STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT,

CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document.

If you have any questions regarding your potential use of this material, contact: Quest Software World Headquarters

LEGAL Dept 5 Polaris Way

Aliso Viejo, CA 92656

www.quest.com

E-mail: [email protected]

Refer to our Web site for regional and international office information.

Trademarks

Quest, Quest Software, the Quest Software logo, AccessManager, ActiveRoles, Aelita, Akonix, AppAssure, Benchmark Factory, Big Brother, BridgeAccess, BridgeAutoEscalate, BridgeSearch, BridgeTrak, BusinessInsight, ChangeAuditor, ChangeManager, Defender, DeployDirector, Desktop Authority, DirectoryAnalyzer, DirectoryTroubleshooter, DS Analyzer, DS Expert, Foglight, GPOADmin, Help Desk Authority, Imceda, IntelliProfile, InTrust, Invirtus, iToken, I/Watch, JClass, Jint, JProbe, LeccoTech, LiteSpeed, LiveReorg, LogADmin, MessageStats, Monosphere, MultSess, NBSpool, NetBase, NetControl, Npulse, NetPro, PassGo, PerformaSure, Point,Click,Done!, PowerGUI, Quest Central, Quest vToolkit, Quest vWorkSpace, ReportADmin, RestoreADmin, ScriptLogic, Security Lifecycle Map, SelfServiceADmin, SharePlex, Sitraka, SmartAlarm, Spotlight, SQL Navigator, SQL Watch, SQLab, Stat, StealthCollect, Storage Horizon, Tag and Follow, Toad, T.O.A.D., Toad World, vAutomator,

vControl, vConverter, vFoglight, vOptimizer, vRanger, Vintela, Virtual DBA, VizionCore, Vizioncore vAutomation Suite, Vizioncore vBackup, Vizioncore vEssentials, Vizioncore vMigrator, Vizioncore vReplicator, WebDefender, Webthority, Xaffire, and XRT are trademarks and registered trademarks of Quest Software, Inc in the United States of America and other countries. Other trademarks and registered trademarks used in this guide are property of their respective owners.

Updated – December 2009 Software Version - 6.5

(3)

About this document

This document provides a brief overview of different ActiveRoles Server deployment scenarios, best practices guidance and ideas on ARS configuration and operation for an enterprise. The document contains descriptions of typical ActiveRoles deployment models, including centralized and distributed. The document is to be considered as complimentary to help documentation provided with the product install package available at ARS Product CD or at ActiveRoles Server web-page:

http://www.quest.com/activeroles-server/

Other sources of information include

ActiveRoles Server community site: http://activeroles.inside.quest.com/

ActiveRoles Server wiki: http://wiki.activeroles.inside.quest.com/index.php/Main_Page

(6)

Overview of ActiveRoles Server as Active

Directory management tool

Quest Software is one of leading software vendors which provides comprehensible and effective solutions in the area of AD management and compliance today.

The Quest Active Roles Server is a solution designed to provide Security, Administration and Provisioning for Active Directory leveraging a variety of different scale environments and business delegation models. List of challenges the IT department face today includes:

AD administrators struggle to keep up with requests to create, change or remove user access to various network resources.

With the advent of compliance regulations like the Sarbanes-Oxley Act (SOX), and the intense scrutiny they place on access to business-sensitive applications, organizations can no longer rely on numerous manual provisioning processes to maintain compliance.

Add to that the need to tightly delegate control of AD among various administrative groups, provide self-service capabilities to users to lighten the IT burden, and involve key people in IT processes through change approval, it‟s no wonder that today‟s AD administrators need help. ActiveRoles Server can help you automatically provision, re-provision and more importantly, deprovision users quickly, cost-efficiently and securely in AD and beyond. ActiveRoles Server provides strictly enforced role-based security, automated group management, change approval and easy-to-use web interfaces for self service, to achieve practical user and group lifecycle management for the Windows enterprise.

Get and Stay Compliant Through Identity Management

ActiveRoles Server helps you achieve and sustain regulatory compliance by implementing secure, automated and auditable internal controls over granting access to network resources. You can automate all aspects of the account management process, introducing human input via a change approval process when needed. This simplifies user and group provisioning, policy enforcement, segregation of duties and delegation of administrative privileges.

ActiveRoles Server automates user and group provisioning lifecycle tasks to reduce your administrative workload and increases user access control whether the user is a new hire, intra-organization transfer or termination. Ben Worthen, in his CIO magazine article, identified that, “Failure to segregate duties within applications, and failure to set up new accounts and terminate old ones in a timely manner…” is the number one IT control weakness among interviewed CIOs and auditors.

ActiveRoles Server provides the ability to deprovision rather than just delete or disable user accounts. ActiveRoles Server comes with default policies to automate some commonly-scripted deprovisioning tasks, and permits all provision policies to be tailored to an organization‟s specific needs.

Involve Decision-makers within Key IT Processes

ActiveRoles Server automates the ability to accept or deny operation requests (change approval) and to monitor the execution of those requests. This complements business rules to make provisioning and deprovisioning decisions based on application or data owners input.

Lower Administrative Costs

A dynamically configured Web interfaces enables users, business data owners and help desk personnel to perform appropriate administrative tasks on their own. This reduces support costs, while enabling the ability to maintain complete control of your Active Directory environment.

(7)

Extend Management Control

ActiveRoles Server extends management control functionalities and provides ability to automate variety of commonly used management tasks inside AD:

Query based management views: show all of the enabled identities, and business rules ensure and

enforce unique user and group identification.

Controlled Administration: Provides a unique administrative service that acts as a firewall around AD, so

you can reliably delegate control by defining administrative roles and associated permissions and rules that are strictly enforced. This is the only way to maintain compliance with security policies.

Automated Provisioning: Automates user and group provisioning, including account creation in AD,

mailbox creation in Exchange, and group population and resource provisioning in Windows, which helps you save valuable administrative time. ActiveRoles Server also automates re-provisioning and de-provisioning, helping to ensure an efficient administrative process over the lifetime of user account or group. This means that when a user‟s access needs to be changed or removed, updates in AD, Exchange and Windows are made automatically.

User Self-Service: With the simple assignment of service roles, end users can carry out

self-administrative tasks, such as modifying their personal data through a simple to use self-service Web interface. Due to the reliable enforcement of business roles and rules, ActiveRoles Server makes self-administrationsafe and secure, while allowing IT to manage (but not necessarily participate in) these time consuming tasks.

Workflow: Provides a rich workflow system for directory data management automation and integration.

Based on Microsoft‟s Windows Workflows Foundation technology, this system enables IT to define, automate and enforce management rules quickly and easily. Workflows extend the capabilities of ActiveRoles Server by delivering a framework that enables you to combine management rules such as provisioning and de-provisioning of identities in the directory, enforce policies on changes to identity data, route data changes for approval, provide e-mail notifications of particular events and conditions, as well as implement custom actions using script technologies such as Microsoft Windows PowerShell.

Auditing and Reporting: Provides a complete audit trail, showing who performed what actions and who

tried to perform actions that were not permitted. A rich suite of reports assists in change tracking and policy enforcement audits and Active Directory monitoring and analysis. By logging all actions in a centralized fashion, ActiveRoles Server enables administrators to quickly troubleshoot and investigate system issues.

Temporal Group Memberships: Automates the tasks of adding or removing group members that only

need group membership for a specific time period. Makes it possible to add or remove members from groups on a scheduled basis, ensuring that particular users are members of required groups for only the required periods of time.

A Complete and Extensible Solution: Manage key user assets, including AD accounts, Exchange

mailboxes and home directories. It provides a practical approach for managing the user lifecycle, including provisioning, re-provisioning and deprovisioning. You can also customize and extend ActiveRoles Server provisioning, management, security and automation through ActiveRoles Server support for custom scripts. These scripts are subject to the same roles and rules as users so you can be confident that they will be executed properly, by the correct people, and trigged by events you define. In addition to strong scripting support, several optional add-on applications (listed below) can be added to ActiveRoles Server to provide for advanced management capabilities.

Optional Add-On Applications for ActiveRoles Server (licensed separately):

ActiveRoles Quick Connect: Enables ActiveRoles Server to provision and deprovision from an

authoritative data source, automatically controlling user access. ActiveRoles Quick Connect extends ActiveRoles Server into the provisioning process on non-Active Directory connected systems for end-to-end identity, password and access synchronization. This saves administrative cost by eliminating effort and reduces errors through automation.

ActiveRoles Management Shell for Active Directory: Provides a set of predefined commands for

Windows PowerShell, the new command line and scripting language developed by Microsoft. By using the ActiveRoles Management Shell for Active Directory to build your scripts, you can harness ActiveRoles

(8)

Server to leverage proven rules, roles, workflow and attestation features giving you a robust management option for Windows PowerShell and Active Directory.

ActiveRoles Self-Service Manager: Provides controls to let administrators empower application and data

owners to self-manage their resource access groups in a secure and compliant manner. By empowering the information owner, the burden of access management and compliance is moved from IT to the person who understands the business justifications for granting access.

(9)

Brief Technical Introduction to ActiveRoles

Server

ActiveRoles Server enables you to perform all tasks related to Active Directory administration from a single MMC- or Web-based interface.

Figure 1: ActiveRoles Server Components

Administration Service is a core component of the ActiveRoles Server instance which executes change requests against AD. End user binds to the service in one way or another and sends the AD change request. The service checks permission of the user account inside ARS Delegation Workflow and execute the request.

The ActiveRoles Server console, also referred to as the MMC Interface, is a comprehensive administrative tool for managing Active Directory and Microsoft Exchange. It enables you to specify administrative roles and delegate control, define administrative policies and automation scripts, easily find directory objects, and perform administrative tasks.

Via the Web interface, intranet users with sufficient administrative rights can connect to ActiveRoles Server to perform basic administrative tasks, such as modifying user data or adding users to groups. The Web interface provides departmental and help-desk personnel with the administrative capabilities they need. You may customize web interface in a way you need.

The ActiveRoles Server ADSI Provider operates as part of Presentation Components to enable custom user interfaces and applications to access Active Directory services through ActiveRoles Server. The ActiveRoles Server ADSI Provider translates clients‟ requests into DCOM calls and interacts with the Administration Service.

(10)

Centralized Deployment Scenario

Overview

Company is a leading global financial services organization with operations in more than 60 countries. Being a modern large scale world-wide enterprise, the company has an IT infrastructure which faces numerous advanced challenges in the areas of management and compliance making Active Directory (AD) management one of the most time-consuming IT tasks.

Historically, the first company‟s office was located in New York and as company grew by buying smaller companies main office hired more IT stuff to NYC IT department. Now almost 80% of IT staff is located at NYC office. Hi-speed and reliable connections are established with other company‟s locations.

For this ARS deployment Distributed Regional model is considered to be implemented. All ARS instances are going to be deployed at single data center (in NYC) and they will be managing all local and remote sites/domains.

SQL Database

In this case, ARS instance in NYC Data Center (or few for load balancing) are sharing single database. Management History database will provide 7 day history of changes done to the AD objects and could be stored as part of configuration database or as separate database (in case if you store data for longer time periods).

(11)

Web Interface

EMEA and APAC delegated administrators logon to main NA‟s Web Interface connected with NA‟s administration service that, in turn, utilize Operation DCs of the region the administrator come from. This model allows the change to happen immediately in the origin region.

Hardware

DC DirSync – APAC\DC in North America region. DC Operation – APAC\DC in APAC region. DC DirSync – EMEA\DC in North America region. DC Operation – EMEA\DC in EMEA region.

Concerns: not all rules applied immediately, because some rules must be applied based on trigger coming from DirSync DC which is waiting for replication from APAC\DC in EMEA to APAC\DC in North America.

Service Accounts

For information on configuring service accounts please refer to Configuring the Administration Service Account section of ActiveRoles Server Quick Start Guide and ActiveRoles Server Replication documents located at the distribution CD.

(12)

Distributed Deployment Scenario

Overview

Company is a leading global financial services organization with operations in more than 60 countries. Being a modern large scale world-wide enterprise, the enterprise has an IT infrastructure which faces numerous advanced challenges in the areas of management and compliance making Active Directory (AD) management one of the most time-consuming IT tasks.

Company‟s environment consists from 6 forests, 12 domain controllers and is distributed across three main geographical regions: APAC, EMEA and North America. Domain controllers are spreaded across all regions.

For this ARS deployment Distributed Regional model is considered to be implemented: each site has its own ARS instance.

SQL Subscriber Config db Management History db Failover/Load Balance ARS.AMERICAS.company.net Failover/Load Balance ARS.ASIAPAC.company.net Failover/Load Balance ARS.EMEA.company.net Americas\DC EMEA\DC ASIAPAC\DC

ARS instance #1 ARS instance #2

AMERICAS region – NYC site

ARS instance #3 SQL Subscriber Config db Management History db ARS instance #4 Americas\DC EMEA\DC ASIAPAC\DC ARS instance #5 Americas\DC EMEA\DC ASIAPAC\DC ARS instance #6 IE

EMEA region – LONDON site

ASIAPAC region – HONK KONG site

IIS IIS IIS IIS SQL Subscriber Config db Management History db SQL Subscriber Config db Management History db ARS Service ARS Service ARS Service ARS Service IIS SQL Subscriber Config db Management History db ARS Service IE IIS ARS Service

IE Replication Replication Replication SQL Publisher Config db Management History db

(13)

Each ActiveRoles instance is deployed with its own Configuration DB/ Management History DB and Web Interface/IIS

All SQL Configuration DBs/ Management History DBs are part of replication group.

Management History DB

Management History DBs 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

1) Cross-site management (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.

(14)

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.

Figure 4: DirSync 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.

(15)

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.

Figure 5: Operational DC - ARS Management Console

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.

(16)

Figure 7: Distributed Deployment Scenario - Administration Service DC Focusing

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)

(17)

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).

Figure 8: Distributed Deployment Scenario - Web Services/IIS

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

(18)

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.

For information on performance, please refer to the “Traffic” section of the current document.

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.

(19)

SQL version is SQL2K5 SP2 for all SQLs

Administration Service and Web Service Server version is W2K3 x64

ARS instance 1

- Region: NORTH AMERICA - Server: Server1

o Admin Service o Web Service /IIS

o Domain: ARSNA.COMPANY.NET o SQL instance: SQL1\instance1

 Publisher

 Configuration DB/Management History DB ARS instance 2

o Admin Service o Web Service /IIS IP Address:

o Domain: ARSNA.COMPANY.NET o Load Balancer:

o SQL instance: SQL2\instance  Subscriber to SQL1\instance

 Configuration DB/Management History db ARS instance 3

- Region: APAC - Server: Server3

o Admin Service o Web Service /IIS o IP Address:

o Domain: ARSAPAC.COMPANY.NET o Load Balancer

- Region: APAC - Server: Server4

o Domain: ARSAPAC.COMPANY.NET o Load Balancer

(20)

ARS instance 5 - Region: EMEA - Server: Server5

o Admin Service o Web Service /IIS o IP Address:

o Domain: ARSEMEA.COMPANY.NET o Load Balancer

- Region: EMEA - Server: Server6

o Domain: ARSEMEA.COMPANY.NET o Load Balancer

 Configuration DB/Management History DB Data Collector

o Data Collector

o Data Collector Database o SQL2K5

o SQL Reporting Services (SRS)

Reporting component - http://QuestKnowledgePortal (QKP)

Service Accounts

For information on configuring service accounts please refer to Configuring the Administration Service Account section of ActiveRoles Server Quick Start Guide and ActiveRoles Server Replication documents located at the distribution CD.

(21)

Other scenarios

Independent ARS Instance per-site

Recommended for vastly distributed environment with independent AD administration teams. The main idea is to have separate managed domains in remote locations.

ARS instances are installed on each of remote location, no replication between configuration databases are set, that is, all ARS instances are independent and are not aware of each other.

Central administration through Web Interface in this case is provided via single web page which contains links to all Web Interfaces.

Exchange Resource Forest

This scenario involves multiple account forests sharing the single Exchange organization, where Exchange servers are installed only in the Exchange forest. This configuration requires directory synchronization between all components, which is maintained by extension to the ARS – Exchange Resource Forest Manager:

Figure 10: Exchange Resource Forest Management

Because of limitations of Exchange 2007 PowerShell API, ARS should be installed at the same domain or forest as Exchange 2007. Also, Exchange Server 2007 SP1 Rollup 1 or higher is required. This is specific to Exchange 2007 and higher environments.

Information on deployment and configuration of ERFM solution can be found in ERFM Administration Guide document, available at ARS Product CD or at ActiveRoles Server web-page:

http://www.quest.com/activeroles-server/

Auditing and Reporting

Overview

ARS stores auditing data in two locations which are used for different purposes

Change History DB (short term change history storage used for a quick view of successful AD change requests. Default: all changes for last 7 days, configurable)

(22)

EDM Server Log (used to trace any activity happened inside Admin Service: established session binds to the service, AD change requests both successful and failed, restart, configuration changes and attempts, etc.)

From compliance standpoint EDM Server Log is the only one to be considered as fully compliant. Some reasons for this:

if History db is unavailable Admin Service will still accept and execute change requests against AD and the changes will not be traced in the DB but in EDM Server Log

all failed change attempts to compromise AD and Admin Service Security are recorded only into EDM Server Log, but not in the History DB.

all configuration settings changes inside ARS which can compromise ARS and AD security, including changes of AD Management proxy account are recorded into EDM Server Log

Data Collector vs. InTrust

Data Collector is a native ARS component for collecting and reporting against EDM Server logs from all Admin Services.

InTrust is a separate Quest product designed for collecting, long term storage and reporting against Event Logs including EDM Server event log. Agent-side compressed log collection technology provides a very efficient way for collecting logs from remote parts of an environment into a central long term dedicated file share storage.

For large scale environments with ARS deployed across number of remote sites it is expected that Data Collector will be an inefficient means for EDM Server log collections if AD management activity is very intense because It will try to access remotely Admin Service EMD Server event log and pull it through network with no compression.

Data Collector

Data Collector will collect ARS related data into separate ARS Auditing DB.

Input parameters: SQL database, administration service, account which will be used to access database and EDM Server Logs.

Options available to collect:

a) Active Directory – collects brief snapshot of AD: users, groups, OUs, computers, domains information. Required to display where Access Templates and policies are applied. To collect this information more quickly, provided that there is no need to see linked information, focus the collection to an empty OU, for example.

b) Policy Compliance Information – Collector will make Administration Service to trigger policy compliance check against all object in the specified AD scope

c) EDM Server Event Log – Collector will try to gather logs from all Administration Services in replication group.

Quest Knowledge Portal is SQL Reporting Services based website, that provides front user interface to run pre-defined reports (ARS Report pack) against collected data. To launch Quest Knowledge Portal open the URL: http://<MyQKPServer>/QuestKnowledgePortal

Quick Connect

QuickConnect is an application that synchronizes identity related data across multiple identity datasources (called connected systems) and Active Directory utilizing ActiveRoles platform either by schedule or by initiating sync actions on demand.

(23)

Figure 11: Quick Figure Figure Connect Sync Engine

It is recommended to deploy QC Sync Engine close to both ActiveRoles administration service and connected systems.

If your QuickConnect instance is indented to frequently handle bulk time-consuming operations consider deploying it to dedicated physical server for best performance.

SPML Provider

Installing ARS SPML Provider opens a possibility to perform provisioning actions in ARS or Active Directory/AD LDS based on SPMLv2 open protocol requests. SPML Provider is a web application which receives SPML SOAP requests, parses it and sends to ActiveRoles server or Active Directory/AD LDS (while using proxy mode):

Figure 12: SPML Provider

Though there are no significant limitations, for best performance consider installing SPML Provider onto a server with ARS instance the provider serves for. Also, for handling long time-consuming mass operations dedicated server is recommended.

(24)

Metrics

Performance and Metrics

Estimation was done based on resource usage calculator document available at ARS Product CD or at ActiveRoles Server web-page:

http://www.quest.com/activeroles-server

Also, this document is available at ActiveRoles Server wiki web-site:

http://wiki.activeroles.inside.quest.com/index.php/ARS_Product_Documentation_-_Resource_Usage_Calculator

Management History DB and EDM log size estimation:

Expected stress loading:

Manual Changes: about 200-400 changes to AD objects per day Bulk Changes (per night): about 2000 changes of AD object per request Number of AD object = 8M

EDM Event Log

0.7KB Event Size per 1 attribute change

Basic estimation, no approvals: (2000/scheduled + 500/manual) /1d x 365days x 0.7KB/1record = 0.6GB

Management History DB

18KB record per 1 attribute change. By default History db contains last 7 days changes done to any object. Basic estimation, no approvals: (2000/scheduled + 500/manual) /1d x 365days x 18KB/1record = 16GB per 1 year with given intensity of management.

Note: Approval-related data is stored in Management History DB

Management History UI Limitations

There are 2 UI commands that present change history data in Snap-in and Web UI: Change History command on any object and User Activity command on user accounts. When client application requests change history information, ARS Service only returns the last 1000 records (so, last 1000 changes for an object or last 1000 changes initiated by a person). Client display only 25 records per page and provides Back/Next buttons to browse through pages.

Configuration DB

0.9GB

Administration Service Memory Usage

280 MB/Estimated and 365MB/Observed (with All Forests are registered + No MU, spikes up to 500MB)

Traffic Workflow

Overview

Network traffic and the way ARS executes changes and quick search against AD are core factors to be considered during ARS deployment planning in a large scaled enterprise. Understanding of the factors brings insight on stress loading on different components and how to distribute available hardware across the deployment, where to expect a cause of performance degradation and potentially where to add new hardware if needed.

(25)

Traffic Flow Diagram

Schematic and approximate presentation of network traffic workflow

Figure 13: Traffic Flow Diagram

In the picture above network traffic metrics are chosen in relative numbers in respect to the traffic generated by connection of Admin Service listening DirSync DC which is taken as 100%.

IE client – Web Service (10%): IE opens ARS Website and sends AD change requests to Admin Service

(though Web Service) and Web Service sends compiled html pages to a Client back returning answers from Admin Service (show AD object properties, Quick Search results etc.)

Web Service – Administration Service (ARS Management Console – Admin Service) (30%): Web

Service sends requests to Admin Service, receives results back (like OU browsing, AD Object Properties, Quick Search results etc.), compiles html pages and offloads them IE client

Administration Service – Operational DC (25%): (DC-focusing) All AD browsing and change requests

are sent to the Operational DC (like OU browsing, AD Object Properties, Quick Search results, Changes applied, etc.)

(26)

Administration Service – DirSync DC (100%): Administration Service listens for DirSync DC

permanently in order to track changes related to ARS configuration (like Dynamic Groups, Managed Units Membership update, etc.)

Administration Service – SQL Configuration db (1%): when user binds to Admin Service (via Website,

ARS Console or ADSI Provider Script) ARS finds out what permissions (stored at Configuration DB) user has inside ARS delegation workflow (view, read, write, modify, etc.)

Administration Service – SQL Configuration db (10%): when user successfully applies change to AD a

Change History record is added into the Management History DB.

SQL Replication, SQL1 – SQL2,3,4,5,6 (1%+10%): Configuration DB and Management History DB are

replicated in order to enforce integrity across all deployed ARS instances.

Based on the traffic workflow diagram it is recommended to have Administration Service and DirSync DC to be on the same high-speed network.

Web Client: Settings and Configuration

(27)

Note that „Number of objects to displayed per page‟ and „Number of pages to retrieve for object list‟ are the parameter which might affect search capabilities if set too large. It is recommended to keep parameters low as it is (say 20-50 x 5-10). The setting can be changed during session and stored at IE cookies (if cleared then setting returns to default 20 x 5).

(28)

Fault tolerance

Overview

A total of six ARS instances will be deployed across three major regions: North America, APAC and EMEA. Each region, for failover purpose, will have two ARS instances installed on dedicated hardware. Each instance will have its own dedicated Admin Service and Web Service (installed on Server1) and SQL (installed on Server2). The two regional websites will be load balanced for performance reasons which will also contribute in failover scenario. Below, fault tolerance mechanisms are described for each of ARS infrastructure components.

Fault Tolerance – SQL Server

SQL cluster technology for database high availability is supported by ARS. Current deployment will have

only the SQL Publisher installed on the SQL Cluster.

DB mirroring SQL technology for database high availability will be supported in ARS 6.5.

If Configuration db is unavailable then the following error will be recorded in the EDM Server Log:

Event ID: 2512 Event description:

Connection to database has been lost.

%n%nActiveRoles Server Administration Service has lost connection to configuration database. Administration Service is making attempts to connect to configuration database.

%nDetails: %1 %nDatabase: %2 %nSQL Server: %3

%nNext attempt to connect: In %4 minutes or later

%n%nThis issue does not affect the directory management function of the Administration Service. All operations related to Active Directory management will work as expected.

%n%nUntil after connection is restored unavailable are all the functions of Administration Service that require access to configuration database. These include: (1) collecting change history and user activity related data; (2) retrieving and updating configuration data; (3) retrieving changes to configuration data made by other Administration Services (both directly and via replication); (4) retrieving and updating virtual attributes stored in configuration database.

If SQL and Admin Service are installed on different machines or

If SQL and Admin Service are on the same machine and Configuration Database is not Available while SQL Server is still running

Every 10 min the Admin Service tries to re-establish a connection to the Configuration DB.

If ARS console session has been established already, then the session is still available and AD changes are applied to AD successfully, while certain information is not available when DB read action is required (like the Advanced Pane showing Access Templates and Policy Links, etc.)

New ARS console session fails with error: „Connect to Admin Service Failed…‟ (due to a failed check against an account trying to establish connection to Administration Service)

If a Web Client session has been already established, then the session is still available and AD changes are applied to AD successfully until the session expires on IIS (an error will be thrown reporting connection failure.)

(29)

New ARS console session fails with error reporting connection failure.

If SQL and Admin Service are on the same machine and SQL Server is stopped

Administration Service stops because when you have SQL Server and ARS Services on the same machine, ARS Service Setup sets dependency of ARS Service with SQL Server.

Both opened and new sessions to the Admin Service via ARS Console or Web Client fail with an error. Examples:

Error: The RPC server is unavailable.

An error has occurred during the last operation. Error: The RPC server is unavailable.

Object: CN=Ron Nelson,OU=Users,OU=COMPANY,DC=ad,DC=forest

Error: The ActiveRoles Administration Service is not available on <my domain>. Access is denied

(30)

Figure 16: Samples of Failed Attempts to Open New Session

If Management History db is unavailable then Admin Service is still available for client and browsing and changes to AD are applied successfully and stored in the EDM Server log. Change History Menu is blank. Changes applied to AD are not traced in History DB and are not shown in Change History Option after the DB is back online.

If the Publisher SQL Agent is stopped, Administration Service is still accessible for clients and changes can be applied to AD. Note that replication will not happen and Replication Status will be reported as „Unknown‟ for both Configuration and History DBs.

(31)

Figure 17: Replication status 'Unknown'

Fault Tolerance – Administration Service

Admin Service becomes unavailable. If underlying Admin Service becomes unavailable, then a client

trying to access the website receives the error: „Error: The ActiveRoles Administration Service is not available on <my domain>. Access is denied.‟

Figure 18: ‘Administration Service is not available’ error.

Upon receiving the error message the user may go directly to another balancer website which is focused to another Admin Service expected to be functioning:

http://<MyRegionMyArsServer>/<MyArsWebsite>

Note that such behavior is due to the fact that each ARS website is “linked” to a particular Administration Service. Other options available for focusing Website to Admin Service:

a) Particular Administration Service (current) b) Any Administration Service

(32)

DirSync DC (DC-focusing): The Admin Service is permanently listening to the DirSync DC for AD

changes related to ARS configuration workflow (Dynamic Groups, Managed Units membership, etc.) The Administration Service periodically checks for DirSync DC status. If current DC becomes unavailable then the Admin Service will ask AD for another „best DC‟ and switch to it. The DirSync DC parameter is set on Managed Domain properties and provides fault tolerance options:

Any Available DC (ADSI API call asks AD for „best available DC‟) Any DC in the site

Specified DC (not recommended)

Figure 19: DirSync DC Options

Operational DC (DC-focusing): all browsing and change requests against a Domain are applied to the

DC. By default, the Operational DC is the same as the identified DirSync DC. If Operational DC becomes unavailable during session it can be changed from a client to a different available one.

Fault Tolerance – Web Interface

Two regional ARS websites will be load balanced via the Web Load Balancer. Each Website can be focused to specific Admin Service (used in current deployment) or to any available Admin Service (not used in current deployment)

Website is unavailable: Load Balancer will redirect client to an available balancer website. If redirection

fails then upon receiving the error message the user may go directly to another balancer website which is expected to be functioning:

(33)

Tips, Questions and Answers

Below is list of tips, typical questions and answers on ARS configuration and operation tasks.

Disaster recovery

For information on disaster recovery best practices, please refer to the following wiki article:

http://wiki.activeroles.inside.quest.com/index.php/ARS_Operations_and_Configuration_FAQ#Disaster_Re covery

Management History: Database settings

(34)

Figure 21: Executing Clean up Manually

Management History: How to Split History DB from Configuration db

To see how to split management history database from configuration database refer to the following article:

http://wiki.activeroles.inside.quest.com/index.php/How_to_Split_History_db_from_Configuration_db

Please, note that provided install scripts must be run and no user friendly interface available at ARS Console.

(35)

Management History: Replication role management

New Subscriber gets overwritten by Publisher data: when joining new Configuration and Management history db into a replication group as a Subscriber, all current information will be overwritten by data from Publisher.

Figure 22: Replication Role Management

Ports: Open Communication Ports for ActiveRoles Server

Requirement

For information on what ports should be enabled while configuring your firewall, please refer to solution SOL30256 or the following wiki article:

http://wiki.activeroles.inside.quest.com/index.php/ARS:Communication_Ports

Web Client: disable Change Operational DC option

To disable Change Operations DC option on Web Client, so end user cannot change operational DC via WI during session you need to customize Menu „Domain‟:

http://<myARSIIS>/<myARSWebsite>

Customization > Customization Tasks > Menu Domain > Change Operational DC | Remove

Secured OU: separate proxy account for access

[Q] Because of compliance purposes domain should have Secured OU, that - is a special OU which is out of scope of regular management.

(36)

- nobody has access to the OU except dedicated accounts

- Domain Admins, Enterprise Admins, ArsProxyAccount should have no rights over the OU - Domain\svcARSSecuredOUManager should have full right over the OU

Is that possible via ARS?

[A] Managing separate OUs under separate account is not feasible with ARS. Instead, install a separate Standalone ARS instance to manage the Secured OU, that is treat OU as separate security content (domain).

For security isolation purposes Microsoft recommends standalone domain, which is perfectly supported by ARS (with separate domain credentials). Please, refer to the following article:

http://technet.microsoft.com/en-us/library/bb727032.aspx

ARS Service Account: how to lock it down?

[Q] We generally try to practice limiting powerful service accounts such as domain admin to logon to one or two servers, and then deny interactive logon for that account on those servers. Can we do this with the ARS Service account?

[A] Put ARS Svc Account into secured OU and setup group policy to lock all required ARS Svc permissions.

ARS Svc Account

- member of ARServer\Local Admin (inheriting required permissions, like run as service, act as a part of OS

- deny specified logon types

ARS Domain Proxy Account (accesses managed domain) - domain admin

(37)

Common troubleshooting activities

Figure 23: Restart ARS Administration Service

(38)

(39)

5 Polaris Way, Aliso Viejo, CA 92656 | PHONE800.306.9329 | WEB www.quest.com | E-MAIL [email protected]

If you are located outside North America, you can find your local office information on our Web site TECH BRIEF

About Quest Software, Inc.

Now more than ever, organizations need to work smart and improve efficiency. Quest Software creates and supports smart systems management products—helping our customers solve everyday IT challenges faster and easier. Visit www.quest.com for more information.

Contacting Quest Software

PHONE 800.306.9329 (United States and Canada)

If you are located outside North America, you can find your local office information on our Web site.

E-MAIL [email protected] MAIL Quest Software, Inc.

World Headquarters

5 Polaris Way

Aliso Viejo, CA 92656

USA

WEB SITE www.quest.com

Contacting Quest Support

Quest Support is available to customers who have a trial version of a Quest product or who have purchased a commercial version and have a valid maintenance contract.

Quest Support provides around-the-clock coverage with SupportLink, our Web self-service. Visit SupportLink at https://support.quest.com.

SupportLink gives users of Quest Software products the ability to: • Search Quest’s online Knowledgebase

• Download the latest releases, documentation, and patches for Quest products • Log support cases

• Manage existing support cases

View the Global Support Guide for a detailed explanation of support programs, online services, contact information, and policies and procedures.

Quest ActiveRoles Server

Deployment Best Practices

Written by

Quest Software, Inc.

Quest® ActiveRoles® Server

Trademarks

Contents

About this document

Overview of ActiveRoles Server as Active

Directory management tool

Get and Stay Compliant Through Identity Management

Involve Decision-makers within Key IT Processes

Lower Administrative Costs

Extend Management Control

Brief Technical Introduction to ActiveRoles

Server

Centralized Deployment Scenario

Overview

SQL Database

Web Interface

Hardware

Service Accounts

Distributed Deployment Scenario

Overview

Management History DB

Concerns/limitations/notes

ActiveRoles Administration Service

Domain Administrative Service Account

DirSync Domain Controller

Operational Domain Controller

SQL Database

Web Interface

Installing Website

Hardware

Service Accounts

Other scenarios

Independent ARS Instance per-site

Exchange Resource Forest

Auditing and Reporting

Overview

Data Collector vs. InTrust

Data Collector

Quick Connect

SPML Provider

Metrics

Performance and Metrics

Management History DB and EDM log size estimation:

EDM Event Log

Management History DB

Management History UI Limitations

Configuration DB

Administration Service Memory Usage

Traffic Workflow

Overview

Traffic Flow Diagram

Web Client: Settings and Configuration

Fault tolerance

Overview

Fault Tolerance – SQL Server

Fault Tolerance – Administration Service

Fault Tolerance – Web Interface

Tips, Questions and Answers

Disaster recovery

Management History: Database settings

Management History: How to Split History DB from Configuration db

Management History: Replication role management

Ports: Open Communication Ports for ActiveRoles Server

Requirement

Web Client: disable Change Operational DC option

Secured OU: separate proxy account for access

ARS Service Account: how to lock it down?

Common troubleshooting activities

About Quest Software, Inc.

Contacting Quest Software

Contacting Quest Support