When midPoint detects an synchronization event it is categorized into one of the situations. The situation describes how the change relates to the midPoint state regarding the changed resource object (account), user and the midPoint policies.
The situations are described in the following table.
The resource object is linked to an appropriate focal object.
Change in account attributes only.
The resource object is linked to two or more focal objects.
Error in IDM business logic or inconsistent database. Should not happen. Do we need this situation?
The resource object has been deleted.
A legal account is manually deleted on the Resource.
A resource object is found on the resource (it exists), midPoint determines exactly one owner for that resource object and that owner does not have the resource object linked (yet).
The account was created on the resource using native administration tools. Initial (incremental) import.
A resource object is found on the resource (it exists) and midPoint cannot determine any owner for the object.
New account was created on the resource using native administration tools and the account has wrong username.
Two or more owners are determined for a single resource object.
An ambiguous account is created manually on the resource, e.g. using a username
The situations deal only with existence or non-existence of resource object (account) and with ownership of the account. In other words it deals only with "links". It does not deal with the legality of the account (whether the user should have the account). See Assigning vs Linking page for a more detailed explanation. The situations also does not deal with change in account attributes.
MidPoint is using the following algorithm to determine a situation:
Following table summarizes the differences among situations from the point of view of detected account operation and the number of owners (or potential owners).
Detected operation on account
Link exists (user has account)
Link does not exists, correlation&confirmation found users
2 or more