← Back to projects

Hybrid identity · Main case

Academic identity classification

Summary

The academic status needed to manage access was not represented in one consistent way in the directory. I built a daily process that gets data from the source system, classifies each identity and applies the result in a controlled way.

My role
Logic design, validation, deployment and monitoring.
Scope
Around 18,000 identities in the first production run.
Status
Automated and monitored during enrolment periods.
Environment
Oracle, Python, PowerShell and Active Directory.
Simplified flow No internal data or names
SourceOracle
ExtractionPython and validated CSV
ControlPowerShell
DirectoryActive Directory

The problem

The identities were used by different applications, but the directory did not have one classification that correctly represented the academic status of each account. This meant solving the same question in a different way for every integration.

The risk was not only technical: a wrong classification could give access to the wrong person. For this reason, the change needed limits, a previous review and traceability.

Decisions

Oracle as the data source
The classification is calculated from the available academic data, without creating new states inside the directory.
Separate extraction from changes
The process first creates a controlled CSV file. PowerShell validates the result and only then compares and applies changes in Active Directory.
Review first, apply later
With thousands of accounts, a small error could have a large impact. I added a dry run, a maximum number of changes, batch processing and logs.

Implementation

The first script reads from Oracle and prepares the data needed by the process. The second compares the expected status with Active Directory and decides which accounts should be updated, kept or excluded.

The process includes several safety checks:

  • Dry-run mode to review the result without changing accounts.
  • Data validation and separate handling of special accounts.
  • Maximum number of changes per run.
  • Batch processing to reduce the impact of an error.
  • Logs showing what changes, what is skipped and why.
  • Daily run after the academic system synchronisation.

Result

The first run updated around 18,000 identities and finished without errors. Accounts that matched the exclusion rules remained unchanged. The process continues to run every day.

During enrolment periods, I pay special attention to new accounts to detect incorrect classifications and adjust the logic before using the attribute for more automation.

≈18,000identities reviewed
Controlledaccounts covered by exclusion rules
0errors in the run