Accounts
Account types
Accounts on connected systems come in several kinds, and it helps to name them consistently. IdStory IdM distinguishes the following account types:
- Personal account - an account bound to a person. Typically the user's main working account; a user can have only one primary personal account on a single system.
- Personal other account - also bound to a person, but a user can have several of them on one system (for example a test account with different permissions or attributes than the main personal account).
- Technical account - an account with no direct binding to a person; its attributes are not provisioned from any identity. It has guarantors and can be linked to a technical asset.
- Service account - a subset of technical account under which a service or an application runs.
- Privileged account - not a separate group of accounts, but a flag that the account has higher permissions than an ordinary user. A privileged account can be either personal or technical. Where the line between an ordinary and a privileged account is drawn differs per customer, and neither a personal other account nor a technical account is automatically privileged.
These types are not mutually exclusive - a single account can combine several characteristics, as the examples below show.
| Example account | Primary personal | Personal other | Technical | Service | Privileged | Note |
|---|---|---|---|---|---|---|
| `jane.doe` | ✅ | ❌ | ❌ | ❌ | ❌ | Main working account of a specific person |
| `test.jane` | ❌ | ✅ | ❌ | ❌ | depends on permissions | Personal account of Jane used for testing |
| `test.user01` | ❌ | ✅ | ❌ | ❌ | depends on permissions | If it has a specific owner and is not shared |
| `jdoe-admin` | ❌ | ✅ | ❌ | ❌ | ✅ | Jane's personal administrative account |
| `svc_sql` | ❌ | ❌ | ✅ | ✅ | depends on permissions | Account for running a service or application |
| `idm_sync` | ❌ | ❌ | ✅ | depends on usage | often ✅ | Connector / synchronization account of IdStory IdM |
| `api_crm` | ❌ | ❌ | ✅ | ❌ | depends on permissions | Integration account for API communication |
| `robot_invoice` | ❌ | ❌ | ✅ | ❌ | depends on permissions | Account used by a robot or automation |
| `svc_backup` | ❌ | ❌ | ✅ | ✅ | ✅ | Service account with elevated rights |
Technical assets
@since IdM 15
A technical asset is the equivalent of an identity for technical accounts - it is the object that technical accounts belong to. For example, if the application `Redmine` has accounts in Git, Google Drive and Slack, there should be a technical asset `Redmine` in IdStory IdM with these technical accounts subordinated to it.
Grouping technical accounts under a technical asset lets you manage them centrally: you can define a single group of Redmine administrators who automatically get access to all of its technical accounts, or who take part in the approval of those accounts - without configuring anything on each account separately.
Accounts and connected systems
An entity called Account is used in IdStory IdM to represent object in connected system. In other words object on connected system is linked to IdStory IdM entity like Role via Account entity.
CzechIdM supports linking objects to CzechIdM entities during Synchronization. Moreover administrators can link them manually e.g. to correct the data state after e.g. AD admins did some unwanted change. Linking objects and entities via accounts allows CzechIdM to support interesting features:
- Identities can have multiple accounts, for example to manage test or system objects on connected systems.
- Objects on connected systems can be renamed. E.g Group in MS AD can move (changed their DN)
- Accounts can be in Protected state.
Protected state of accounts
In protected state objects linked to affected account are not deleted from connected systems. Thus
- Administrators can set CzechIdM to move objects to archive or trash rather than deleting them
- Objects are kept in the archive for a define period of time, after that CzechIdM will delete them in a standard way. If the time period is not defined, objects are not deleted ever.
Protected state can be used on systems on which it is not desired to delete objects instantly for example MS Exchange. This way users can get some time to move their mails before mailboxes are deleted.
Read more
Admin tutorials
Admin guide
Devel guide
- Protected state of account (to be deleted)