Eliminating Process Redundancy with UMRA

BACKGROUND

In a recent implementation for a US state government I used Tools4ever UMRA to consolidate enterprise-level audit logging for various processes – password resets, user provisioning, etc. The idea here was to take these common processes that require audit compliance, but are enabled by different systems (that keep their own logs), and centralize their logging in a SQL server table with common  schema.  Later, this table would be used for auditing and reporting.

UMRA ARCHITECTURE

The reason UMRA is the perfect tool for this is due to it’s architecture – it runs as a Windows service under a privileged Active Directory account.  All projects and actions contained within the service are stateless, so elastic server farms can be set up. Interop capabilities are exposed over a COM interface, which is very easy to work with. Also, we can easily make wrappers over the COM interface, for sake of being more friendly towards external systems – i.e. an HTTP web service.

“AUDIT LOG” UMRA PROJECT

The idea behind this project is to make it easy for whoever executes it to take full advantage of the logging schema.  When it comes to audit logging, there are really 3 pieces to it: (1) the action (2) the user performing the action – “actor” (3) the user against whom the action is being performed – “subject”. You can then break them down further – action’s details (code, text, new/old value, etc.) and user information (username, display name, location, IDs, etc.).

That’s a lot of data to deal with and UMRA lets us encapsulate this to a simple interface – a simple “Audit Log” project which could take in just 2 variables – Action Code and Subject Username, and fill in the rest by itself. Also, the project is flexible enough to allow passing all possible DB schema variables.

USING THE PROJECT

Ultimately, various external systems can easily call the project to enable centralized audit logging throughout the enterprise:

• Modern web-service-based web applications – via writing IIS WebMethod wrappers for calling the UMRA project
• Legacy ASP web applications – via executing the COM object directly
• Batch scripts – also via COM
• Other UMRA projects – through UMRA itself

Ultimately, you end up with just 1 place for all system auditing needs.  Also, you can produce extensive reports off the audit table. Also, since the Audit Log is a UMRA project, it’s very easy to modify it to include additional functionality.  Want to send an email to admin, whenever a Domain Admins accounts’ password is getting changed? 3 lines of UMRA “code”.

UMRA in Web Scenarios – Failover & Scalability

BACKGROUND

For the last few months I’ve been working on a web portal that uses Tools4ever UMRA as “workhorse” in the background.  Technically, the layers look like this:

1. Browser (I use ExtJS4 extensively)
2. Web Server (IIS7.5, though I’ve done similar on IIS6 on S2k3)
3. ASP.NET (C#)
4. COM (for talking to UMRA)
5. UMRA

In this large scale implementation, over 40,000 people would potentially be using the portal for managing their (and others’) AD accounts.  Daily traffic is estimated at 1,600 users. Also, the application is “mission critical” and high availability is a requirement.

WEB FARM

To meet the requirements, our Client provided us with L4 switch with failover/load balancing, sticky sessions, and SSL offloading.  Our job was to implement a web farm that looks something like this:

 …oh did I mention Tools4ever SSRPM was also a part of this?

100% REDUNDANCY

We are able to achieve a true failover system due to the following:

• UMRA & SSRPM do not cache NETBIOS names; they are resolved upon every query
• UMRA & SSRPM allow custom Active Directory Domain Controller to be specified by IPs; we configured every web server instance to point to its own dedicated DC
• UMRA & SSRPM are stateless by design, just like AD itself, so we can have a user working on one web server switch over to a different web server seamlessly (sans the login prompt), if their first server fails
• Replicated DFS is used whenever file system resources are utilized (i.e. viewing generated reports)
• Failover-safe MSSQL server instance is used for any SQL storage & processing