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.

Technically, in IdStory IdM an account is anything that provisions or synchronizes to a connected system - not only user logins. If you connect, for example, roles or tree nodes to synchronization from AD, each such entity gets its own account that appears in the Accounts agenda. These are typically visible only to the superadmin, so they should not confuse ordinary or even privileged users. The entity types listed in the filter of the Accounts agenda show everything that can have an account.

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.

Admin tutorials

Admin guide

Devel guide

Account management
Protected state of account (to be deleted)

← Password synchronization

Documentation

Synchronization →

Table of Contents