<- .:uniform_password | Password synchronization ^ .:start | Documentation ^ .:synchronization | Synchronization -> {{tag> topic account personal_account technical_account service_account privileged_account technical_asset provisioning synchronization }} ====== 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. {{ :devel:documentation:accounts.png | Accounts linked to connected system objects}} 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. {{ :devel:documentation:protected.png | Protected state}} 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 ===== * [[:tutorial:adm:accounts|Accounts - linking accounts to objects ]] * [[.:accounts:dev:personal-other-accounts|Personal other accounts - zone and tier]] ===== Admin guide ===== * [[.:accounts:adm:accounts|Account management]] * [[.:accounts:adm:account-protection|Protected state of account]] * [[.:accounts:dev:personal-other-accounts|Personal other accounts - zone and tier]] ===== Devel guide ===== * [[..:documentation:accounts:dev:account-management|Account management]] * [[..:documentation:accounts:dev:protection-system|Protected state of account]] (to be deleted)