Orphaned account
|
Orphaned account management feature
This page is an introduction to Orphaned account management midPoint feature.
Please see the feature page for more details.
|
Orphaned accounts are those that exist on a resource, e.g., Active Directory, but which have no corresponding focus in midPoint that would be their owner. It is important to be aware of such accounts and deal with them appropriately as they can pose a serious security risk if left unattended. In this article, we explain the typical root causes behind existence of orphaned accounts, why awareness of them is important, what risks they pose, and how to deal with them.
What causes accounts to be orphans
Orphaned accounts typically appear when:
-
The correlation process fails to match a resource account to a midPoint focal object—the unmatched synchronization situation.
-
The authoritative source system (e.g., HR database) does not cover all the accounts held in the other connected systems. This may be, for instance, because HR department does not keep records of former employees but these are not removed from the other systems.
-
An account is created in a target system manually outside the usual provisioning flow, which is typically source system → midPoint → target systems.
As you can see, all the typical causes boil down to the situation when a target system is not in sync with the authoritative source system.
Why you should keep tabs on orphaned accounts
-
Security: Orphaned accounts are not just litter taking up space in your systems. They can represent a severe attack surface and serve as a foothold for attackers.
-
Data integrity: Orphaned accounts signal gaps between the authoritative identity store, such as the HR database, and the rest of your identity ecosystem, indicating that your IGA model is incomplete.
-
Governance & compliance: Some regulations require every account or service to have an owner; unowned accounts break required audit trails.
-
Operational hygiene: Detecting orphans early prevents the accumulation of "dead" accounts that clutter your systems and increase administrative overhead.
How can orphaned accounts be dangerous
An active orphaned account may retain high privileges without being transparently connected to any individual you can hold accountable. As such, it provides the aforementioned foothold for attackers. They may gain access to such an account in various ways because there is no one accountable for guarding the access credentials. You also have no way to enforce an updated password policy on accounts without owners.
Accounts without owners may also violate security policies and standards that mandate clear identity ownership and lifecycle control.
Last but not least, orphaned accounts may be misused to circumvent some policies, leading to shadow IT practices and loss of visibility over individual responsibility.
Not all orphaned account are bad
There are situation where maintaining orphaned accounts makes sense. It is not like you have to delete every identity that is not in midPoint. The important thing is that you know about such identities and have a process on maintaining them.
-
Service or system accounts that deliberately have no human owner (e.g., scheduled jobs, integration bots).
-
Pending onboarding – an account may be pre‑created in the target system awaiting the arrival of a new employee whose identity has not yet been imported.
-
Legacy applications that cannot be fully integrated with midPoint yet still require functional accounts.
How to deal with orphaned accounts
-
The first step is to detect the orphaned accounts. Correlate the resource identities and look for the unmatched synchronization situation in the resource account list.
-
If you have not just migrated to midPoint, you likely already have a recurring reconciliation task running. Before you proceed further, we suggest you suspend the task until you are done with the clean-up. In the meantime, you should run it only when you are sure it would not delete any account you wish to keep.
-
-
Examine the correlation results and decide for each unmatched account whether it is a valid identity or a truly stray one. There may be accounts you cannot classify at the moment—mark them in the next step for later resolution.
-
Mark the shadows of legitimate accounts as protected, and those you cannot classify immediately as correlate later. It is up to you which marks you use. The point is to protect the wanted orphans from automatic deletion. Do not mark the shadows of accounts you want to get rid of anyhow, they do not need the protection.
-
Once you have all orphaned accounts classified, i.e., either marked and protected, or left as they were, update the synchronization rules in order to automate removal of unwanted orphaned accounts during reconciliation (the Delete resource object reaction to the Unmatched situation).
-
Set up a dashboard displaying the number of unmatched accounts, so that you can monitor them and review the list regularly.
Summary
Understanding orphaned accounts is essential for maintaining a secure, compliant, and well‑governed IGA environment. MidPoint equips you with detection, analysis, and remediation capabilities. By regularly reviewing the unmatched accounts, applying clear policies, and distinguishing legitimate cases, you can mitigate security risks while preserving necessary exceptions.
See also
Compliance
This feature is related to the following compliance frameworks: