Active Directory User Onboarding

Overview

The “AD User Onboarding” sample demonstrates a solution pattern for employee onboarding. Onboarding is a process through which a new employee or contractor is brought into an organization. Companies have sought to streamline and automate their onboarding process as a way to not only save money but also to improve the perception of their company by newly acquired resources. Additionally, automated onboarding processes will have more easily measured control objectives and be much easier to audit as a result.

The sample shown here is very simple. The onboarding process automated would normally include the following steps:

1. Receive notification about a new hire. This will include the persons First Name, Last Name, the hiring Department and the lifetime of their Windows account.

2. Provision a user into Active Directory. Create a login ID that is unique and in the following format: <First two letters of first name><Last Name><#> where <#> is a counter that reflects the number of <First two letters of first name><Last Name> combinations found. <#> is omitted if <First two letters of first name><Last Name> is a unique login ID.

3. Set the login expire date. Reset the password and unlock their account.

4. Send the login ID to HR so an employee number can be generated (send an email).

5. Send an email to the new hires department training lead so customized training for corporate policy can be scheduled.

The sample can typically be run with a little configuration (specifically, the AD activities will need to be configured to reflect a local AD environment). In the “0. Setup Folder” one will find a workflow called “0. Process Sample Data”. This workflow will trigger the onboarding process for a handful of users.

A workflow like this would generally be called from an external HR system, however in some cases vehicles such as an email form or periodic CSV upload have been observed. As such, the processing of the request (the “onboarding process”) has been abstracted from the receipt of the request. One simply has to trigger the workflow from a remote location through a mechanism such as the Opalis Remote Trigger.

The trigger for the Onboarding workflow looks like a standard trigger if it is called from another workflow. Note that certain aspects of onboarding have not been dealt with here, such as delivery of the account password, etc. These processes would be very unique to a given environment.

Top-Level Workflows

There is one top-level workflow that can be found in the “Active Directory” folder.

“1. Onboard User”

This very simple workflow shows how an onboarding process can be broken up into distinct steps. In this example the first step is to take a single user and create an account in Active Directory. The second step is to provision resources for their work assignment. They key here is that one doesn’t have to build huge workflows with complex logic. Rather, take the overall process and break it into more manageable chunks that can be more easily authored.

Child Workflows

There are 3 child workflows that support the top-line processes. These are small workflows called from the top-line workflow as needed to complete the transaction. They all perform some small but useful task and could possibly be re-used in other workflows. It is possible that these workflows might need to be edited to deal with local variations in the environment where the sample is run:

“1. Add User to Active Directory”

This is a simple example of how one can create a user account in Active Directory. This child workflow has very simple inputs: First Name, Last Name, Department and Account Lifetime. Given this information an account is created in Active Directory. Additional parameters could be added if they needed to be part of the account creation process. This is just an illustrative set of data designed for use I the sample.

Based on the lifetime of the account, one can compute an expiry date using the Foundation “Format Date/Time” Activity. Then a query to Active Directory is made using wildcard format <First two letters of First Name><Last Name> to see if this would be a unique account.

“Determine Account Suffix” is a “Map Published Data” Foundation activity. If there are no user that match the pattern, then the count of zero (“0”) is mapped to a blank (i.e. there is no account suffix). If the account is not Unique then the Count is mapped to the identical value (1, 2, 3, 4, etc…). There are probably many ways this could have been implemented but this one provides a good illustration of the “Map Published Data” Foundation Activity.

At this point in time the users account information is created in Active Directory and the account name is returned to the top-line workflow.

“2. Provision Resources”

This is a very simply workflow that accepts as input the provisioning data used in creating the users AD account as well as the account name. It sends an email to the HR department requesting an employee number be created. It also looks at the Department field of the newly created AD record and emails the departmental specific training lead to schedule corporate mandatory training with the new hire.

This workflow (made to be illustrative) could be updated to enable a great many processes. For example, one could integrate directly with the HR system to generate an employee number and update Active Directory accordingly.

Share this post :