Stacked Identities

The Ghost Accounts That Almost Sank Our Okta Go-Live

—

by

Rohith Udupa
in , ,

We were replacing SailPoint with Okta for a global manufacturing giant.
200,000 employees. Multiple continents. A project with enough moving parts to make anyone reach for a second cup of coffee.

The Perfect Plan

From day one, the goal was clear:
Okta would own the identity lifecycle from start to finish.
HR → Okta → Active Directory & Applications.

Here’s how it was designed:

  • HR as the source of truth.
  • New hires flow into Okta.
  • Email generated right in Okta using Workflows — ensuring uniqueness.
  • Group rules & entitlements decide which apps and licenses they get.
  • Provisioning pushes accounts into AD and downstream systems.
  • No more relying on AD as the “creator” of accounts — Okta’s now the brain and the brawn.

It was beautiful on paper.
Fast. Automated. Governance built in.

Then We Hit the Wall

We were testing new hire onboarding when it started happening.
Provisioning errors. Email conflicts. People stuck in limbo.

At first, it seemed random — one new hire got in smoothly, the next hit an error.
Until the pattern emerged:

Out of every 10 new hires, 3 had email collisions.

The culprit? Inactive accounts in AD.

The Ghosts in the Directory

Here’s the thing about SailPoint — it happily imports everything, active or inactive.
Okta? It politely ignores inactive users when connecting to AD.

But AD… AD never forgets.

Buried deep inside were 30,000 inactive accounts from the last 2–3 years.
They were disabled, yes, but they still held their email addresses hostage.

So when Okta tried to create john.doe@company.com for a new hire, AD said:

“Sorry, taken.”

Okta had no clue that account existed.
Compliance had no visibility into those identities.
We had a shadow population we couldn’t govern.

The Fix Was Simple, But the Lesson Was Big

We pulled all 30,000 inactive AD accounts.
Created a CSV with usernames, emails, and status = deactivated.
Imported them into Okta as deactivated users — a one-time load.

Now:

  • Okta “sees” those accounts.
  • Email generation checks against them, avoiding duplicates.
  • Compliance teams can report on the full identity set — active and inactive.
  • New hires onboard without collisions.

Takeaway for Anyone Doing the Same

If you’re designing Okta as the LCM brain for HR → Apps,
don’t forget about the ghosts in AD.

Inactive accounts can:

  • Break your email generation logic.
  • Cause onboarding delays.
  • Leave compliance gaps that auditors will find.

Bring them into Okta before go-live — even if they’ll never log in again.

Because in identity, the dead aren’t really dead until you account for them.

Comments

Leave a comment