ActiveRoles is a third party product from Quest Software that allows Active Directory Administrators the ability to enforce workflow, approvals, and auditing on changes made to Active Directory accounts.
While ServiceNow provides out of the box Runbook Automation workflows for Active Directory, those companies requiring changes through ActiveRoles cannot benefit from the out of box AD automation packages.
The following Proof of Concept integration/automation application seeks to prove out the capability of ServiceNow to automated ActiveRoles just as it can do with Active Directory.
Pre-Requisites
This update set assumes you have Runbook Automation (RBA) installed on your ServiceNow instance. It also assumes that you have MID Servers installed on at least one Windows device and have it configured to execute Powershell v2.0 scripts.
The Windows device hosting the MID Server should have the “Quest ARS ADSI Provider” installed a well as the “ActiveRoles Management Shell distribution” application.
The user account running the MID Server process should have the rights required to execute the desired ActiveRoles commands.
It is recommended to test a few ActiveRoles commands in a PowerShell session on the device where the MID server is installed to verify that the PowerShell and Windows device are set up properly.
A good reference for the ActiveRoles PowerShell API can be found here: ActiveRoles PowerShell Command Reference.
Installation & Configuration
First, you will need to download and install the update set (available at the bottom of this article).
After you have loaded, previewed, and committed the update set into your instance, you will need to modify your Service Catalog to display the activities that are generated by this Proof of Concept automation.
To do this, simply browse to your Service Catalog and click the “Add Categories” link.
Select the “ActiveRoles Domain Management” category and select where you would like to place it within the catalog.
The Service Catalog should now show the ActiveRoles Domain Management category of requests.
To complete the configuration, browse to the “Integration – ActiveRoles” application that was created from the update set within your ServiceNow instance. Select the “Settings” module.
The Proof of Concept
Once your system is configured properly, you can demonstrate the ability to drive ActiveRoles activities by browsing to the Service Catalog and testing the various offerings in the ActiveRoles Domain Management category.
If we were to test the “Create an Active Domain User via ActiveRoles” catalog item, we would be presented with an order form like the one below.
Upon ordering this item, the following Workflow will be executed:
Of course this workflow is overly simplistic. In an actual implementation, we would add approvals, pass/fail conditions and rections, etc.
The UpdateSet does create reusable ActiveRoles activities in the Workflow Editor so that more complicated workflows can be created.
For the proof of concept, the response to the ActiveRoles request is only availabe in the ECC Queue. However, we do store the response in a workflow variable that is available within the workflow context so that error conditions or other branches in workflow logic can be configured to react to the response.
Here is what a create user call may yield in the ECC Queue as a response:
You could also check your Active Directory to ensure that the User was successfully created.
Update Set
This Proof of Concept application for ActiveRoles is freely available to download and install. It is recommended that you install this into a sandbox environment as this is not production ready code. However, it will give you a good feel for how you could develop your own ActiveRoles automation within ServiceNow.
