The purpose of reconciliation of IDM with target resources is to bring out inconsistencies that may exist on IDM and / or the target resources. Reconciliation also provides with the option of automatically fixing certain kinds of inconsistencies, though in the present case, reconciliation was run with the primary purpose of generating reports.
All the target resources were reconciled independently. It may be noted that since reconciliation on these resources was not run concurrently, and because no downtime was scheduled, it is possible that while the reconciliation activity was running, certain updates were made to IDM and the target systems as well.
Incremental Reconciliation process:
Incremental account reconciliation will occur on a pre-determined schedule to show the changes from the previous time the application was reconciled.An IdM adapter will be used to determine which data rows will correspond to the IdM user account.
Full Reconciliation Process:This process can be run any time whenever a full integrity check is needed. This process will ignore prior links and perform a full reconciliation between IdM and the applications. The following cases are examples of when this may be needed:
· Application upgrade
· Field or Schema change
· Application Database Refresh
Incremental Reconciliation process:
Incremental account reconciliation will occur on a pre-determined schedule to show the changes from the previous time the application was reconciled.An IdM adapter will be used to determine which data rows will correspond to the IdM user account.
Full Reconciliation Process:This process can be run any time whenever a full integrity check is needed. This process will ignore prior links and perform a full reconciliation between IdM and the applications. The following cases are examples of when this may be needed:
· Application upgrade
· Field or Schema change
· Application Database Refresh
From our understanding, for every user in the target resource, the reconciliation report may return one of the following statuses:
1. Confirmed: The Identity Manager user says that the account exists, and the resource agrees that the account exists
2. Deleted: The Identity Manager user says the account exists, but the resource says that the account does not exist.
3. Found: The Identity Manager user says the account may exist, and the resource says that the account does exist.
4. Missing: The Identity Manager user says the account may exist, but the resource says that the account does not exist.
5. Collision: Two or more Identity Manager users claim the same resource account.
6. Unassigned: The resource account matches exactly one Identity Manager user, but that user does not say anything about the account.
7. Unmatched: The resource account matches no Identity Manager user.
8. Disputed: The resource account matches more than one Identity Manager user.
Account Status | Comments |
Collision | This User has account Ids’ |
Confirmed | Account in IM matched to account in resource. And account is already linked. |
Deleted | User Movement in resource with out properly unlinking. |
Found | The user says the account may exist, and the resource says that the account does exist. |
Missing | Locked out Users and users that have been shown an error. |
Unmatched | Most of these Account Ids’ are Generic Ids’, Test Ids’, Backup Ids’, and Old Ids’ not in use. |
Unassigned | These account Ids exist on end resource but not have been linked with IM UserID. |
Actionable for Situations:
Deleted
- Unlink resource account from IM
- Create resource account for IM
Found
- Link the resource account to IM
Missing
- Unlink resource account from IM
- Create resource account for IM
Unmatched
- Create the user account in IM and link the resource account
- Delete the resource account
- Disable the resource account
- Do Nothing -- For System/Admin accounts
Confirmed
- No actions needed.
No comments:
Post a Comment