DanpLab · Lab NoteArchitettura operativa

Identity Lifecycle Automation: HR-governed onboarding, rehires and offboarding

The real identity lifecycle architecture: HR as the source of truth, separate GROUND and CREW paths, idempotent queues, two-stage offboarding, rehires and an operational device dashboard.

6 min readBased on real operational use
automationmicrosoftsecurityidentity governance

Why identity lifecycle cannot depend on tickets

Manual account creation and decommissioning expose an organization to delays, inconsistent configurations and residual access. This system moves the process into a governed flow: events originate in the HR system, are normalized and queued, then executed idempotently with an explicit state and a verifiable outcome.

The procedure covers hires, fixed-term contracts, terminations and rehires. The project was developed within an ISO 27001-certified IT department and was included among the operational evidence assessed during the certification audit.

Sensitive details—hosts, tenant identifiers, technical accounts, addresses and internal paths—are intentionally not published.


Architecture: HR, orchestration and target systems

SOURCE OF TRUTH — HR Database SQL Server → hires_queue + leaves_queue LAYER 1 — AUTOMATION ORCHESTRATION n8n Engine orchestrator PowerShell + Kerberos Graph API Microsoft 365 PostgreSQL audit + state Active Directory + Exchange on-prem GROUND · PowerShell + Kerberos Entra ID + Exchange Online + Intune CREW / Microsoft 365 · Graph API state + KPI LAYER 2 — OPERATIONAL DASHBOARD Flask + Gunicorn → SSO Entra ID → KPI real-time onboarding queue · devices · signatures · returns LAYER 3 — AUDIT & COMPLIANCE Audit trail PostgreSQL · HR↔AD/Entra reconciliation · Reports · GDPR/NIS2

The system uses:

  • the HR database as the source of truth for hires, terminations and contract expiry;
  • self-hosted n8n for scheduling, routing, notifications and error handling;
  • PostgreSQL for operational queues, states, timestamps, snapshots and last errors;
  • PowerShell over Kerberos for Active Directory and hybrid Exchange;
  • Microsoft Graph API for cloud identities and service communications;
  • an IT dashboard as the operational interface for onboarding and devices, not as the source of identity events.

Each event moves through explicit states (pending, done, skipped, error). Re-running a workflow must not duplicate identities or repeat completed operations.

Two populations, two paths

| | GROUND staff | CREW staff | |---|---|---| | Identity | Hybrid | Cloud-only | | Primary directory | On-premises Active Directory | Microsoft Entra ID | | Mailbox | Remote Mailbox in a hybrid Exchange scenario | Cloud mailbox associated with the identity | | Provisioning | PowerShell Remoting with Kerberos | Microsoft Graph API | | Offboarding stage 1 | Disable AD and remove groups | Disable the Entra ID account | | Offboarding stage 2 | Move to an OU excluded from synchronization | Controlled deletion in Entra ID |

HR source of truth hires_queue → is_crew? GROUND (on-prem) PowerShell + Kerberos Invoke-Command → DC Create AD User OU + groups + UPN Remote Mailbox Exchange on-prem → AD Connect sync → Entra ID CREW (cloud-only) Graph API app registration Create Entra User UPN + password + profile Add to Group Personale Navigante → attributes + verified groups OTS

Scheduling and onboarding

Hiring events are imported with a configurable lead time before the start date, allowing account creation and workstation preparation before the employee’s first day. At termination, the disablement phase is scheduled.

HR-governed onboarding · configurable lead time before start HR eventhire · leave · expiry Normalizeidempotency key Queuestate + schedule GROUNDAD + Remote Mailbox CREWEntra ID via Graph CloseHR + OTSreports Dashboard IT: checklist · device preparation · delivery · signature · return

1. Intake and normalization

The HR procedure returns hires, terminations and fixed-term contract expiry. The workflow normalizes the data, selects the GROUND or CREW branch, prepares candidate identifiers and uses an idempotency key tied to person, action and effective date. Collisions are resolved during provisioning against the actual target systems.

2. GROUND provisioning

The workflow creates the AD user and Remote Mailbox in the correct OU, sets organizational attributes and, for fixed-term contracts, the account expiry date. The final identifiers returned by the script are saved in the queue. A separate idempotent step applies default groups.

3. CREW provisioning

The workflow validates the required role and attributes, creates the cloud user through Graph and waits for propagation. Membership of the flying-staff group is verified with retries; other groups may be dynamic and depend on identity attributes.

4. Closing the HR loop and delivering credentials

After successful provisioning, the corporate email address is synchronized back to HR using different rules for first-time hires and rehires. Temporary credentials are not persisted by the dashboard: they are delivered through one-time links, with a shorter validity for the employee and a separate operational window for IT. Exceptions remain visible in reports and the queue.


Rehires: reactivate when safe, recreate when required

A rehire within the configured operational window, in the same branch, reuses the existing identity:

  • GROUND: restore the original OU when needed, re-enable the account and recover groups from the snapshot;
  • CREW: re-enable the cloud account and realign its attributes;
  • mark the termination record as reactivated, preventing later removal stages from touching the account.

Outside the configured window, or when the employee moves between GROUND and CREW, the system performs a new provisioning operation.


Two-stage offboarding

Offboarding separates the reversible access block from deferred removal. Nothing is deleted immediately.

TERMINATIONHR event PHASE 1immediate reversible block PHASE 2live check + removal RECOVERYnative restore window GROUND Disable ADsnapshot OU + groupsremove memberships Move to excluded OUonly if still disabledAD object retained CREW Disable Entra IDgroups unchangedidempotent outcome DELETE via Graphonly if still disablednative recycle bin Rehire within configured window → reactivate · exclude later removal

Phase 1 — access block

At termination, the account is disabled immediately. For GROUND, original groups and OU are saved in a snapshot and group memberships are removed. For CREW, the Entra ID account is disabled; an already absent account is handled idempotently.

The result and any error are recorded per identity. An error is never forced and does not stop the rest of the batch.

Phase 2 — controlled removal

After an observation period from the termination date—and only after checking the account’s live state:

  • GROUND: if the account is still disabled, it is moved to the OU dedicated to dismissed identities and excluded from Entra Connect. The AD object is retained, disabled, for audit purposes;
  • CREW: Graph confirms that the user exists and remains disabled before DELETE. An enabled account is treated as an anomaly and is not touched. Deletion moves the user into the native Entra ID recycle bin.

Minimum recovery window

The minimum recovery window covers the entire period between disablement and final removal, plus Microsoft’s native mailbox restore period—providing overall coverage designed to handle rehires without losing identity or data.


IT dashboard and device lifecycle

The dashboard is a separate application protected by Entra ID SSO, restricted to the operator group, with operator identity recorded for every write. It complements identity automation while managing a distinct domain: device preparation, delivery, signature and return.

Available capabilities

  • onboarding KPIs and queue, with a checklist per person;
  • PC preparation, GROUND password reset, TAP and one-time credential delivery;
  • device delivery, return or a combined operation for any employee;
  • touch/mouse signature, signed PDF, email and SharePoint archive;
  • pending signatures, signed forms, returned devices and spare PCs.

In development

  • delivery-form conditions adapted to the actual operation;
  • classification of devices not yet present in the HR catalogue;
  • missing-return notifications;
  • in-app operating guidance covering data, responsibilities and controls.

Planned

  • rapid reassignment from returned and spare pools;
  • periodic reporting of devices waiting to be cleaned;
  • assisted wipe and removal from Entra ID, Intune and AD, with explicit human confirmation.

The dashboard does not perform silent destructive operations: planned capabilities that touch devices or directories require explicit confirmation and per-step audit evidence.


Guardrails, observability and audit

  • HR as source of truth: IT does not create or disable accounts manually in the ordinary flow.
  • State queues and idempotency: every event can resume safely without duplication.
  • Live verification: actual AD or Entra ID state is checked before removal.
  • Dual time threshold: final removal occurs only when both the termination event and the account’s effective disablement are sufficiently consolidated over time, preventing premature removal after corrections or last-minute rehires.
  • Rehire exclusion: a reactivation blocks every later removal stage.
  • Isolated errors and retries: one exception does not block the batch and remains available for review.
  • Separation of privilege: distinct technical identities and applications for directory, cloud and mail delivery.
  • TEST_MODE and dry-run: test tables, redirected recipients and simulated destructive actions.
  • Evidence: phase timestamps, group snapshots, HR synchronization outcome, daily reports and n8n execution history.

A periodic read-only reconciliation compares HR, AD and Entra ID to identify active accounts or missing events, without automatically turning an anomaly into a destructive action.


Operational outcome

The value is not a promotional “seconds-to-complete” number, but a repeatable control:

  1. hires are prepared before their start date;
  2. terminations enter a governed and observable queue;
  3. rehires preserve the identity when they fit the defined window;
  4. final removals are deferred, preceded by live checks and recoverable;
  5. identity, credentials and assets produce separate but correlated evidence.

That combination—HR source, explicit state, GROUND/CREW separation, two-stage removal and audit evidence—is what makes the lifecycle reliable and defensible during an audit.