Employee Identity Lifecycle

Every organization repeats the same identity work: a person is hired, changes roles, moves departments and eventually leaves. Identity teams call it Joiner-Mover-Leaver. It is one of the highest-volume and highest-risk workflows in IT, because access is the front door to every system a company owns — and in most departments it is still a ticket and a checklist.

A typical joiner starts as an email from HR. A technician opens Active Directory Users and Computers, types the details, picks an OU, and often copies group memberships from "someone in the same team." Cloud apps, device policies and virtual desktops follow in other consoles. Every hand-off relies on someone reading the ticket correctly and remembering every step.

• Joiners wait for access, or inherit someone else's permissions through "copy user"
• Movers receive new access, but old access is rarely removed, so privileges accumulate over years
• Leavers depend on a ticket reaching IT on time; a missed step leaves a working credential behind a former employee

That asymmetry is why privilege creep survives diligent teams: nothing in a manual process asks for removal. The engine replaces the checklist with a model in which removal is not a separate step anyone has to remember. It is simply what happens when current access exceeds what HR data justifies.

Instead of scripting individual actions per event, the engine declares what access should exist for each person and reconciles reality to match. A transfer removes old access as naturally as it grants new access, because both fall out of the same comparison. The engine is Invoke-EmployeeIdentityLifecycle.ps1; the same entry point handles all four events, and the event type comes from the HR record, not from the operator.

Automation is only as good as the structure it acts on, so the directory was designed so that where an account lives and which groups it holds both follow directly from HR data. Department OUs mirror HR departments under an Employees OU, a Disabled Users OU acts as quarantine, and all OUs are protected from accidental deletion. The department decides the OU and the core groups every member needs. The job title adds role-specific entitlements on top. Changing policy is a configuration change, not a code change.

Every department also receives IAM-Intune-Corporate-Standard. AVD application groups are addressed as resource group and application group pairs in the policy file.

A naming prefix as a security control

Every automation-owned group starts with IAM-, and the engine only reads and changes memberships in groups with that prefix. Break-glass, built-in and hand-managed project groups stay outside its reach. That keeps automation predictable, makes ownership obvious to anyone browsing the directory, and bounds the damage any bug could do.

Managers as real directory objects

The HR record carries the manager's UPN, which the engine resolves to a distinguished name and writes to the manager attribute. That attribute is not decoration: it powers org charts, approval routing and access reviews downstream.

Compare-AccessSet takes current and desired group lists, normalizes and de-duplicates both, and returns Add, Remove and Keep. It has no side effects, the same function serves all four target systems, and it is the natural first target for unit tests. Every access decision the engine makes can be explained by pointing at two lists and their difference.

Scoping happens before the diff

Group sync reads the account's current memberships, filters them to the managed prefix, and only then computes the difference. Because the filter precedes the comparison, an unmanaged group such as Domain Users can never appear in the Remove list at all — it is not merely skipped at write time, it never becomes a candidate.

Seven layers, one job each

The 30 functions are grouped so that connectors can be added or swapped without touching lifecycle logic.

No connector writes to a directory directly. Each passes its change to Invoke-ManagedChange as a script block. In audit-only mode the function records the change as Planned and returns. Otherwise it asks ShouldProcess, runs the change inside a try/catch, and records Success, Skipped, or Failed with the exception message — re-throwing so the failure is not swallowed. Because there is exactly one path to a write, there is no way to change access off the record.

Honest drift reporting

Under -SkipCloud the engine still computes and prints the Entra and AVD plan. Pending cloud additions keep appearing on subsequent runs until a cloud run reconciles them. The engine never reports a state it did not produce.

Every run targeted corp.ventura.local from its domain controller using the ActiveDirectory module, with -SkipCloud set. OUs, managed groups and managers from the access model existed beforehand. All four HR records shared employee ID 10001, Sarah Johnson, exactly as one real employee's records would. After each run the account was checked from PowerShell with Get-ADUser and a group membership query, and visually in Active Directory Users and Computers — two independent views of every result.

What the role change proves

Idempotency. A naive script would remove and re-add every group on each run, adding log noise and brief access gaps. The engine saw the Finance groups were already correct and made no group writes; only the changed attribute was updated.

What the transfer proves

No creep. Old department access was removed in the same run the new access was granted, without anyone deciding to remove it. Nothing in the desired state justified keeping it.

Between full campaign runs, Reset-TestEmployee.ps1 deletes only the test account and verifies the deletion, leaving managers, groups and OUs in place, so the four tests can be repeated from a known clean state.

For a leaver, Get-DesiredAccess returns an empty target on every system and the Disabled Users OU as the destination. The desired state is not "remove these groups"; it is "hold nothing," and reconciliation does the rest.

Deleting an account destroys its SID, group history and ownership links. Disabling and quarantining keeps evidence for audits and legal holds, supports rehires, and gives the business time to hand over files. In the cloud path the same event also blocks Entra sign-in, revokes active sessions and removes AVD role assignments, because a disabled on-premises account does not by itself end a live cloud session.

The published report and this dossier were sanitized before release: the lab password, the Windows product ID, internal IP addresses and a profile photo were removed. The domain controller name, host name and lab domain remain visible, deliberately, as evidence the captures are from a real environment.

Engineering review: refinements from the test output

• Attribute writes run on every event, even when title and department are unchanged. Compare values before writing so the audit log records only real changes
• A terminated account keeps its manager and title. Clear the manager link, stamp a termination date, and hide the account from address lists
• The Cloud Engineer role adds cloud entitlements only. Role-scoped AD groups are already designed in the project README and need only a policy entry and two groups
• Tests are verified by reading output. Codify expected results as Pester assertions so the campaign becomes one automated regression suite