The client for this automation example is a state government agency responsible for providing legal advice and representation to customers across a large and diverse jurisdiction.
At the time of the project covered in this case study, the client had completed the early stages of a service improvement program. A dedicated IT Service Management toolset had been implemented to optimise ITIL processes around incident, major incident, and configuration management. This had delivered noticeable improvements in service support around IT break/fix activities.
The selected ITSM solution featured a sophisticated and flexible workflow platform. The client had used this functionality to implement automated processes around the creation and modification of user accounts, as well as mailbox management. These were managed by sending tasks to relevant teams who would then perform their tasks manually.
Defining the problem
The initial scope of the project was relatively straight forward – the client wished to improve productivity across account management by swapping out manual tasks in favour of automated actions. These actions would take information from the request – such as the planned username, user OU, or mailbox requirements – and push these through to third party systems via integration, to automate the entire task and remove the need for manual involvement.
The client had recently moved their ticketing/workflow solution into AWS to simplify administration and maintenance. However, the Active Directory resources required to complete objectives for automation were located on-premises and were securely firewalled, making integration difficult.
Review findings
Following a review the following was determined:
The main automation system (Alemba Service Manager) was located on AWS
Active Directory resources were on-premises, firewalled, and
Applications, mailboxes are within Office.com
The client also maintained an Azure subscription, mainly used for the provisioning of computer/VM resources.
Solution
The major challenge was the need to connect resources from the ASM cloud server to the client’s on-premises Active Directory implementation. While ASM does make a fully featured AD connector readily available out-of-the-box, this is currently designed to support in-network integration only.
Azure to on-premises integration
Azure Logic Apps are Microsoft Azure’s solution for developing low-code automations within the cloud. Typically, these are used to create repeatable workflows which orchestrate integrations between resources running within an Azure subscription.
Figure 1 (below) shows a typical logic app that initiates a process when a specific HTTP request is received, and then (depending upon conditional logic) works through various steps to send different emails using Azure Exchange.
Figure 1: Typical Azure Logic App (image from Microsoft)
Logic Apps provide a comprehensive low-code solution for Azure orchestration – however difficulties arise when the cloud/on-premises boundary must be crossed.
To address this Microsoft has provided Azure Runbook Workers – these leverage the Azure VM Extension framework to allow for secure integration between on-prem servers and the Azure environment, which allow Logic Apps to be delivered into the local environment where they can be configured to access internal resources.
Figure 2 (below) shows this process in some detail:
An HTTP post is sent to a specific webhook
This webhook is associated with an Azure Logic App Runbook
The Runbook is in turn configured against an on-prem Hybrid Worker, which transfers the information from the Azure Runbook to the on-prem instance, where it can run with access to its required resources.
Figure 2: Azure Hybrid Runbook worker operation
From Amazon Web Services, to Azure, to on-prem, and back again
The client’s situation was even more complex than the typical scenarios that Hybrid Runbook Workers are designed for. Specifically - their workflow automation system wasn’t available from within Azure, because it happened to be located on AWS. So, our solution space included two separate cloud environments, as well as the on-premises environment.
Thankfully, later versions of the ASM Workflow Automation platform have included a highly capable webhook solution. This allows for the creation of webhook tasks within the process can make HTTP calls to and from the system. This was key to the eventual solution, which is shown in Figure 3, below.
Figure 3: AWS to Azure to on-premises integration
The solution works as follows:
Requests are initiated by customers from the client’s self-service web portal, which initiates an automated workflow
At the point where on-premises integration is required, a workflow task fires off an HTTP request to Azure via a webhook
Azure then initiates the Logic App Runbook process, which executes the runbook code on the on-prem hybrid runbook worker to make the relevant changes in the local environment
On completion, a second runbook is executed to process the result of the first (this returns a success/failed state)
Finally, an HTTP POST is made back to the AWS-based webhook to continue the workflow.
Result
Through this project the client has been able to fully automate several repetitive technical tasks, including:
Creation of new user accounts in all AD user Ous
Updating user attributes, including account expiry date, and account enabled/disabled state
Moving users between OUs
Adding and removing users to (and from) groups
Allocating Office 365 / Office.com resources, including mailboxes
This has saved hours of effort for requests like modify access, adding/removing mailboxes and general onboarding.