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.

Centralized scenario means that all ARS instances are  deployed at single data center (say, in North America) and they  manage all local and remote sites/domains (EMEA and APAC, for example), as shown at the picture:

In this case ARS instance in Notrh America (NA) data center (or few for load balancing) are sharing single database. Management History database will provide 7 day history of changes  and is stored as part of configuration database.
As you can see, ARS Service and Web Interface are installed either on separate servers or co-located at one physical server.

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.
This deployment is reccomended for medium- sized companies, or companies with centralized help desk.
In our next post we would provide some best practices on deploying ARS in de-centralized environment with help desk spread across geographical locations.

What about Identity and access management for the cloud? As companies are going to build their business applications in the cloud the essential problem appears: centralized authorization and solution for access management.

Let’s take Microsoft Azure Platform as an example. As you might know, there are two components for the Platform:

• Windows Azure
• Azure Services

Windows Azure allows you to store data remotely and provides runtime for your applications. Pretty clear, right? Now, what about Azure Services? It is formed by several components that you can use in a way you need:

• .NET services
• Access Control Services – authentication and authorization engine, remote decision point for applications (claim-based)
• Service Bus – application messaging exchange
• Workflow Services - manage and execute the interactions between services
• SQL Services
• Live Services – for using Live identities and framework
• Sharepoint Services (future) - write code in SharePoint that uses Web Services to make calls to Azure services.

We have particular interest in the Access Control Services. Authentication in Azure is based on claims. So if you present superadmin claim and target application trusts your claim provider you are assigned superadmin role in the application. But the world is cruel. Application owners do not want users to wear superadmin’s hat, they just want to allow them only what they are supposed to do. And users simply do not know what tokens target application consumes. All that they have is a claim with group membership in Active Directory.

In this case Azure team suggests using claim transformation for authentication and authorization. That is, when you present your ‘group=Sales’ claim it gets transformed to ‘role=Salesman’ application-specific claim. There is a special MMC snap-in that allows you to define these transformations in drag-and-drop fashion:

You can find a detailed description of this technique here:
http://blogs.msdn.com/vbertocci/archive/2009/03/17/a-visual-tour-of-the-net-access-control-service-part-2-fun-with-scopes-and-issuers.aspx

This method works well for applications with few roles defined but I dare not speak about centralizing authorization of ten apps with thousands of scopes defined, because in this case you will end up with a classic problem which is known since the beginning of identity management trend – role proliferation, also known as “role explosion” (where the number of roles exceeds the number of users). Tools for identity management are critical for success – you will probably need workflow to approve role membership or periodically verify it.

So, what we have is a lack of authorization mechanisms for identity and access management for cloudy applications. There is a standard called XACML that seems to solve authorization tasks, but is needs a lot of work to suite cloud IAM tasks.

To become a really useful solution, cloud needs to be “identity management aware” - externalize authentication, authorization, and even audit data. Identity and access management tools for Cloud is an unoccupied niche for both cloud vendors and ISV, so you are to expect solutions in this area pretty soon, as Cloud gains maturity. Stay tuned!

That’s about it. Feel free to drop a line for clarification.