Active Directory
On-prem identity and the full user lifecycle as automation - provision, sync, and a careful offboarding that disables first and deletes later, never the other way round.
What it is & why I use it
Active Directory is the identity source of truth for AutomationLab. It holds the users, groups, and service accounts the rest of the platform authorizes against, and it is the authoritative half of a hybrid setup: on-prem AD is where identities are born and changed, and those changes flow up to the cloud directory - not the reverse.
I run the whole user lifecycle as code: joining, group membership, and leaving are pipeline actions with approval gates, not a checklist someone follows by hand in a management console. Identity is too important - and too easy to get subtly wrong - to be a manual process.
How I use it in the lab
- Structured, automation-owned objects. Automation-managed users, groups, and service accounts live in a dedicated organizational-unit tree, so what the automation owns is clearly separated from everything else.
- Provisioning by pipeline. Creating a user creates the account, sets group membership, and lets the change sync to the cloud directory - one flow, repeatable, with the sensitive values pulled from the secrets manager at run time.
- Hybrid sync to the cloud. An identity-sync bridge keeps on-prem AD and the cloud directory aligned, with on-prem as the source of authority.
- Disable-first offboarding. Leaving is the highest-stakes action, so it is the most guarded: it requires four-eyes approval, disables the account immediately, and defers destructive cleanup to a later sweep.
Architecture
The lifecycle that matters most is offboarding, because it is the one that is destructive and hard to undo:
- Four-eyes approval. A deprovision is requested by one person and approved by a different, explicitly authorized one - the request and approval identities cannot be the same.
- Disable immediately. Access is cut at once by disabling the account, which is instantly reversible if the request was wrong.
- Delete on a delay. A later cleanup sweep performs the irreversible removal, leaving a recovery window between "access revoked" and "gone for good."
In action
Lessons learned & gotchas
- Disable before you delete - always. Immediate deletion on offboarding has no undo; a fat-fingered or malicious request is permanent. Disable-now / delete-later turns a mistake into a recoverable event and still cuts access instantly.
- Four-eyes belongs on the destructive action, in code. The rule that the requester cannot be the approver is only real when a pipeline enforces it - a policy in a document is not a control.
- Separate what automation owns. Keeping automation-managed objects in their own OU tree means a bulk action can never accidentally reach into identities it was never meant to touch.
- Service accounts are identities too. They need the same lifecycle discipline as users - scoped, tracked, and revocable - or they become the forgotten keys nobody rotates.
Impact
Active Directory is where the lab's identity discipline lives. Automating the lifecycle makes joins and leaves repeatable and reviewable; disable-first offboarding makes the riskiest action safe to get wrong; and treating on-prem as the single source of authority keeps hybrid identity from quietly drifting out of sync. Identity done carefully is what everything else gets to trust.
Code & further reading
Published lifecycle code is scrubbed of domain names, OU paths, usernames, addresses, and any secret references before it goes public.