Identity Lifecycle Automation: From Manual Ticket to Zero-Touch Provisioning

The problem: when identity is a manual process

In an organization with over 1,000 employees and continuous turnover, manual IT identity management is a concrete operational risk. Every new hire requires: account creation, license assignment, group configuration, credential delivery. Every exit requires: access blocking, license revocation, group removal, documentation.

When all this happens via email tickets, problems are inevitable:

Long times: 2-4 hours for a complete onboarding, with IT becoming the bottleneck
Human errors: accounts with wrong permissions, forgotten licenses, unassigned groups
Orphaned accounts: former employees with active access for days or weeks after the end of the relationship — the most serious security risk
Zero audit trail: no structured trace of who did what, when, and with what outcome
Inconsistent configurations: each operator creates accounts slightly differently

This article describes the system I designed and implemented to solve these problems: an end-to-end architecture that automates the entire identity lifecycle, from the HR trigger to device delivery, with full audit trail and GDPR/NIS2 compliance.

System Architecture

The system is composed of three distinct layers that work together:

Two employee categories, two paths

The system distinguishes two types of personnel with completely different requirements:

| | GROUND (ground staff) | CREW (flying staff) | |---|---|---| | Identity type | On-premises | Cloud-only | | Directory | Active Directory + Exchange | Entra ID | | Provisioning | PowerShell via Kerberos | Microsoft Graph API | | Credentials | AD Password + Remote Mailbox | Cloud password + TAP | | Offboarding | Disable → OU DISMISSED (Day 30) | Disable → Delete cloud (Day 30) |

This distinction is fundamental: ground staff maintain on-prem identities for compatibility with legacy systems, while flying staff are managed entirely in the Microsoft cloud.

Onboarding: from HR trigger to ready account

The onboarding flow is completely automated and is divided into six sequential steps:

Step 1 — Input validation

The workflow receives employee data (first name, last name, department, role, manager) from the onboarding queue, fed by a synchronization with the HR database. The first step validates the payload: mandatory fields present, correct email format, existence of the department in the configured mapping. If something is wrong, a notification is sent to the requester — no account is created with incomplete data.

Step 2 — Account creation

GROUND: a PowerShell script creates the account in Active Directory in the correct OU, sets display name, UPN, internal number, and forces password change at first logon. The operation takes place via Invoke-Command with Kerberos authentication — the Linux container does not have native AD cmdlets, so every operation goes through a remote session on the domain controller.

CREW: the workflow calls the Microsoft Graph API to create the user directly on Entra ID. Immediately after, the user is added to the flying staff group.

Step 3 — Cloud identity synchronization

For GROUND staff, the workflow waits for the AD Connect sync propagation to Entra ID. A polling on the Graph API with retry and exponential backoff verifies the availability of the cloud user before proceeding. Only when the identity is confirmed to be present in both systems, the flow continues.

Step 4 — License assignment

Via the Microsoft Graph API, the Microsoft 365 license configured for the department is assigned. License profiles are mapped in an updatable configuration node without modifying the workflow — just change the mapping, no need to rewrite the flow.

Step 5 — Groups and Teams configuration

The user is automatically added to security groups, distribution lists, and Microsoft Teams teams based on their department. The department→groups mapping is centralized and maintainable.

Step 6 — Credential delivery and handoff

Temporary credentials are delivered via a one-time link service (TTL 24h for the user, 7 days for IT) that includes the password and instructions for the first login. In parallel:

A summary report is sent to the IT team
A notification email is sent to the new employee's manager
The generated corporate email is written to the HR record to close the loop

Average time from start to finish: less than 8 minutes, compared to the 2-4 hours of the previous manual process.

Offboarding: the most critical process

An active account of a former employee is an immediate security risk. Offboarding is designed with a conservative philosophy: never force, never delete arbitrarily, always verify before acting.

Day 0 — Immediate block

When a leave event enters the queue, the system acts within seconds:

GROUND: a PowerShell script disables the AD account and prepares it for moving to the dismiss OU.

CREW: Graph API resets the random password, revokes all active sessions (revokeSignInSessions), and disables the account on Entra ID. Access to all cloud services is immediately interrupted.

Before any action, the group state is saved in a JSON snapshot — this allows for quick reactivation if the employee returns (e.g., a renewed fixed-term contract).

Day 30 — Definitive dismiss

GROUND: a daily job checks candidates for moving (disable completed + 30 days passed). Before moving, it performs a live check on AD to ensure the account is still disabled — if it has been reactivated in the meantime, the move is canceled and the item is flagged as an anomaly. The account is moved to a dedicated OU that excludes it from Entra Connect sync → Microsoft automatically deletes the cloud identity and mailbox. The AD object is never deleted: it remains disabled indefinitely for audit purposes.

CREW: a daily job checks candidates for cloud deletion (30 days from leave + 30 days from disable). Before each deletion, a live GET on Entra ID is performed to confirm that accountEnabled=false. Only if confirmed, the DELETE moves the object to the native Entra ID recycle bin (recoverable for 30 days from the M365 Admin Center). At the total 60-day mark, Microsoft performs the permanent purge.

Reactivation

If an employee returns within 30 days, the system automatically restores the account from the group snapshot saved on Day 0. No recreation, no manual reassignment — the identity becomes operational again with the original permissions.

Operational dashboard

The dashboard is a separate web application, protected by SSO with Microsoft Entra ID and mandatory MFA. Access is restricted to a named security group; every action is tracked with the identity of the authenticated operator.

Real-time KPIs

The dashboard shows an aggregated view that merges HR data, provisioning status, and assigned assets:

Total records in queue
Pending ready for execution
Pending scheduled in the future
Completed
Errors (with exception detail and failed step)
Daily hires
Assigned devices and prepared PCs

Operations from the dashboard

| Operation | Description | |---|---| | Device assignment | The operator enters the laptop's service tag; the system records the association with timestamp and operator | | TAP (Temporary Access Pass) | Generates a one-time Entra ID pass for the first passwordless login | | Password reset | Secure reset with credential delivery via one-time link + email | | PC configuration completion | Password reset + IT notification + email to the employee with instructions | | PDF delivery report | Automatic generation of the device delivery document, ready for signature |

Savings calculation

Provisioning time

| Metric | Before (manual) | After (automated) | Savings | |---|---|---|---| | Complete onboarding | 2-4 hours | ~8 minutes | ~95% | | Offboarding (access blocking) | 30-60 min | <60 seconds | ~98% | | New device setup | 3-4 hours | ~25 minutes (Autopilot) | ~85% | | IT operational load | 3-4 hours/week | ~30 min/week | ~85% |

Security

| Metric | Before | After | Improvement | |---|---|---|---| | Orphaned accounts post-leave | Frequent (days/weeks) | Zero since deployment | Total elimination | | Access revocation time | Hours-days | <60 seconds from trigger | Critical reduction | | Audit trail | Absent | Complete (operator, timestamp, outcome) | Total traceability | | Inconsistent configurations | Common | Standardized by department | Guaranteed consistency |

Cost

The system runs on existing infrastructure (VMs, Docker containers, already active M365 licenses). The only additional cost is development and maintenance time — no recurring costs for third-party software.

Compliance: GDPR and NIS2

The system implements a defense-in-depth strategy across four independent layers:

GDPR (EU Reg. 2016/679)

Art. 5 — Storage limitation: accounts disabled and licenses revoked at the end of the employment relationship. Zero orphaned accounts is a compliance requirement before even being a technical KPI
Art. 25 — Privacy by design: dashboard access restricted to a named group, separate DB users with minimal permissions, every action logged with operator identity. Principle of least privilege applied at every level of the stack
Art. 32 — Security of processing: SSO with mandatory MFA, no anonymous access, end-to-end TLS encrypted transmission
Art. 33 — Breach notification: the structured log allows precise reconstruction of who had access to what and in which time frame — information required in notifications to the Data Protection Authority within 72 hours

NIS2 (EU Dir. 2022/2555)

The air transport sector is classified in Annex I as an essential sector, with stricter security obligations.

Art. 21 — Risk management: automatic deprovisioning with access revocation in less than 60 seconds drastically reduces the post-termination exposure window
Identity and access management: standardized provisioning eliminates inconsistent configurations; every account is named, traceable, and centrally revocable
Logging and auditing: the structured log on PostgreSQL with configurable retention provides the operational evidence required in case of inspection or incident response

Resilience and error handling

The system is designed to fail safely (fail-closed), not silently:

Retry with exponential backoff on Graph API operations (rate limit, timeout)
Manual fallback: if a step fails after retries, the operation is suspended and an IT notification is sent with instructions for intervention — no account is left in an inconsistent state
Idempotency: each step verifies the state before acting, avoiding duplications in case of re-execution
Partial rollback: if license assignment fails, the workflow notifies and keeps the account without licenses instead of deleting it
Live check before destructive actions: every offboarding verifies the current state on AD/Entra before proceeding — if the account has been reactivated in the meantime, the action is canceled
TEST_MODE: a centralized flag allows testing the entire flow without side effects — emails redirected to a test address, destructive actions converted to mocks

Technology stack

| Component | Technology | |---|---| | Orchestration | n8n (custom image with PowerShell + Kerberos) | | Dashboard | Python Flask + Gunicorn | | Database | PostgreSQL 15 | | Dashboard authentication | oauth2-proxy + Microsoft Entra ID SSO | | Reverse proxy | Caddy (automatic TLS) | | Containers | Docker Compose | | Active Directory | PowerShell + WinRM via Kerberos | | Cloud identity | Microsoft Graph API | | Licenses and groups | Microsoft Graph API | | Email | Microsoft Graph API (application permissions) | | Credential delivery |