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 thepronounceable
pattern of thehttps://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.
Top comments (0)