Automating account creation in on-prem AD with Power Automate

Automating user creation in the context of Microsoft 365 Cloud and an on-prem AD infrastructure with Azure AD Sync can be a tedious job. In this article, we will present how we automated the process of creating specific users

Automating account creation in on-prem AD with Power Automate

The following material is a technical deep dive into an automation solution provided by two of our Intelligent Workplace experts, Tudor Ispas and Catalin Palfi. For any further details concerning how this can help your business, do not hesitate to get in touch with us by filling in the contact form.

The context

Automating user creation in the context of Microsoft 365 Cloud and an on-prem AD infrastructure with Azure AD Sync can be a tedious job. In this article, we will present how we automated the process of creating specific users, such as test users, service accounts and admin accounts using Nintex Forms for SharePoint Online, Power Automate and a PowerShell script running against the domain.

This process hits all the requirements of any business:

  • a unified naming convention

  • proper license assignment

  • comprehensive tracking (owners, requested dates, purpose)

At a high-level glance, the process encompasses the following:

  • Accounts are requested via a Nintex form in a SharePoint Online list

  • Requestors fill in the required details based on the account type: service accounts, administrator accounts or test accounts

  • All requests go through an approval process

  • Accounts are created in Active Directory with the corresponding details (name, description etc.), placed in the owner's domain and in the correct OU

  • Service accounts are excluded from Conditional Access policies

  • If needed, test accounts are licensed in Office 365

  • All approved requests log via an API call a CR in the ticketing system

  • Once created, the account details are sent to the owner

  • Approved accounts are logged to three distinct SharePoint Online lists based on their type and removed from the initial list• Rejected accounts are moved to a specific list

As is applicable to any intricate process, breaking it down by thoroughly describing the steps and requirements can help better understand why it is important and, subsequently, how organizations can benefit from applying it to their enterprise IT management.

The solution requirements and steps

SharePoint Online lists:

a. The main SharePoint Online list is where the Nintex form resides and where users have access to log their requests.

b. Another 4 lists are needed for tracking (service accounts, admin accounts, test accounts and rejected requests)

These lists have specific columns:

sharepoint-online-lists-columns.png

The Nintex Form

The form enforces via regular expressions naming convention based on account type and double-checks the existence of users to avoid duplicates. It also populates dynamically certain fields which are relevant to an account type.

Service account form:

service-acc-form.png

Test account form

test-acc-form.png

Admin account form:

admin-acc-form.png

Power Automate workflow

The workflow is triggered every time a new item is added; it processes the information provided in the form and pushes via a Gateway a .csv file on the VM.

  • Approvals are needed for all requests

  • If the request is rejected the flow will send an email to the requestor, move the item to the rejected tracking list and then terminate the workflow

  • All account details that compile the parameters for account creation in AD are initialized as variables and changed along the way based on the account type

  • If a license is needed a condition sets the extensionAttribute1 to Licensed and the Email value of the account

  • The flow then pushes the .csv file on a specific path on the server with all the details needed for the account: FirstName, LastName, DisplayName, Username, UPN, Email, extensionAttribute1(licensing), AccountDescription, AccountOU, EmployeeType, AccountOwner, OwnerEmail, RequestorEmail, OwnerDisplayName

  • A Change Request is logged in the ticketing system on behalf of the requestor and closed automatically with an API call

  • After 2 hours the flow removes the request and moves the item to the corresponding list: service, test, or admin

workflow-1.pngworkflow-2.pngworkflow-3.pngworkflow-4.pngworkflow-5.pngworkflow-6_new-2.pngworkflow-7.png

The complete folder structure on the server where the account creation script runs.

This includes:

  • Archive: location where all processed csv files are moved

  • Create: location where the script adds headers to the csv files

  • Drop: location where the workflow pushed the csv files

  • EmailTemplate: location for the email template

  • Error: location where all failed processed csv files are stored

  • Logs: location for storing all logs

Once the csv file is pushed on the server via a Gateway, it gets picked up by a Scheduled task running each half an hour

The script:

  • Starts the logging process

  • Generates a random password

  • Picks up all files stored on under the Drop folder

  • Adds headers to all the csv files and moves the files to the Create folder

  • Sets the parameters based on the csv

  • Interrogates the global catalogue for the account owner domain so that it can place the requested account under the same domain

  • Creates the user based on the parameters, and sets the extension attributes (extensionAttribute1 and extensionAttribute2) and the accountType

  • In case of failure due to duplicate accounts it sends an email notification to the requestor and to IT, while the csv file is moved to the Error folder

  • In case of failure due to other reasons, IT is informed, and the csv file is moved to the Error folder

  • Once the user is created successfully, the script sends an email to the owner with the username and password in an HTML format

  • The processed files are moved to the Archive

  • Logs are sent to IT

After the process is completed and the users are synchronized to Azure AD, they are added to Office 365 groups as follows:

  • If the test user's extensionAttribute1 is set to Licensed the user is added to an Office 365 security group dynamically and licensed

  • If the service account's extensionAttribute2 is set to SVC, the user is added to an Office 365 security group dynamically and excluded from CA

If you are interested in more automations for your IT infrastructure to create a truly intelligent workplace for your team, our experts would love to help.