Use Case

Ever encountered a situation where you are about deploy an App in a Windows Environment, and you realize you don't have an designated user account yet?

• You would ask your AD admin to create one for you (or do it yourself).
• Figure out a password with the correct complexity
• Note down the password (securely 😉) so that Team members can use it.

I assembled a script that takes a list of Users and a set of Environments (dev, test, prod, ...), which then either creates or updates the AAD User.
Passwords are auto-generated and backed in an Azure Keyvault -- this makes noting down passwords a thing of the past 🎉.
You can find the boilerplate script (or set of functions) here.

Note: This is meant to tailor to your business logic.

Explanation

In my example, I have a simple list of Services and Environments:

$Services = @(
@{ name = 'service_1' ; description = 'Service 1'},
....
)
$envs  =  @('Dev','Test','Acc','Stage','Prod')

The User Account Names are consctructed from the Service and Environment, so for example the account name for service_1 in development would be: svc_d_service_1

NOTE: Again, Account Name logic can be entirely different in your business

For each User Account, the main Function Set-ServiceAccountUser is called:

• it checks if the User exists
• if it doesnt exist, the User will be created.
• When an User needs to be created, it checks the Azure Keyvault whether it has a Password available, if not, a Password is auto-generated and stored in the Vault.
• If the User already exists, you can optionally update the password (in the Keyvault and AD) with the -updatePassword switch

Passwords are generated in the form of a wer-yui-wwer35 (three syllables plus 2 digits).

NOTE: Passwords logic can be found in the New-Password function. I'm using the pronounceable pattern of the https://makemeapassword.ligos.net api. This is totally customizable.

You will also notice that I use different Keyvaults for each Environment. You can find (and customize) the logic in the Get-VaultName Function.