Modules - Technical accounts [tech]

The Technical Accounts module in Identity Management (IdM) is designed to help manage accounts that are not tied to a specific user identity, but instead serve a technical or system purpose.

These accounts – often referred to as technical accounts – are used by systems, applications, or devices to communicate with other systems, access services, or perform automated tasks. For example, a projector or printer account accessing the network, or an integration scenario where Application A retrieves data from System B using a technical account.

Unlike regular user accounts, technical accounts:

• are not directly linked to a person in IdM,
• are not used for interactive login by end users,
• are assigned a guarantor – a responsible person or role who oversees the account’s usage, security, and lifecycle.

The module allows administrators and guarantors to:

• create and manage technical accounts,
• set permanent passwords,
• define and update attributes based on configurable rules,
• track ownership and changes over time,
• ensure secure and transparent use across the organization.

"Compatible with the product" means that this is the recommended product version

• Supported operations on Technical Accounts in IdM - This section provides an overview of all operations that can be performed with technical accounts within IdM

• Installation – Describes the installation process and basic configuration of the Technical Accounts module.

• Getting Started – Includes the initial steps required for the user to start working with the module.

• Types of Users - Provides a brief overview of the different user roles involved in working with the Technical Accounts module. It outlines each role’s responsibilities, permissions, and how they interact with technical accounts within the system.

• Tasks – Includes specific workflows (tutorials) on how to perform various actions in the module – for example, how to identify an account’s guarantor, how to assign or remove a role from a technical account, or how to gain access to a subordinate’s account.

• Troubleshooting – Helps address the most common issues users may encounter when working with the module.

• Glossary – A glossary of terms used in the documentation and within the module itself.

Operations that can be performed with technical accounts within IdM:

• CREATE of a technical account in the target system via a wizard in IdM.

• UPDATE of managed attributes (e.g., description, extended attributes, etc.) and their propagation to the end system.

• MEMBERSHIP on the target system for the given technical account, controlled through IdM.

• Approving of role request in IdM for the technical account – the process may be subject to approval, for example by the role guarantor, etc.

• CHANGE PASSWORD of the technical account.

• Assig guarantor in the IdM to the technical account – the guarantor then gains the authorization to perform the listed operations.

• Report of all managed technical accounts in IdM in .xls (Excel) format.

The technical account serves as the owner of the account in the target system. This allows you to manage it without having an identity which owns it.

A technical account can also have guarantors, either directly (an identity), or by role. A guarantor is a user who is responsible for managing the account, and making sure that correct attributes and roles are set for it. This also allows you to apply permissions and allow guarantors to only the technical accounts for which they are guarantors.

A technical account can either be created by synchronization from a target system (if the account already exists), or a new account can be created via the wizard. Technical accounts can be managed via standard provisioning mapping but some attributes will require manual management.

Two processes ensure the state of technical account:

• EndTechnicalAccountProcess invalidates technical accounts where validTill already past,
• StartTechnicalAccountProcess will validate them if date is between validFrom and validTill.

This section describes the installation process of the Technical Accounts module, including its activation, required prerequisites, access rights configuration, and integration with target systems. It serves as a starting point for administrators when introducing the module into the IdM environment.

• @since 2.1.0
• The configuration property defines attributes of the account on the system that will be added to the technical account entity report. If you want to define multiple attributes, separate them with a comma.

# list of attributes from account connector object added to technical account entity report
idm.sec.tech.account.report.connector.object.attributes=

• @since 1.0.0
• Technical account guarantor role. This is product provided role with permission configuration.
• Configuration property has default value techAccountGuarantorRole.

idm.sec.tech.role.guarantor=techAccountGuarantorRole

• @since 1.0.0
• System owner technical account role. This is product provided role with permission configuration.
• Configuration property has default value techAccountSystemOwnerRole.

idm.sec.tech.role.systemowner=techAccountSystemOwnerRole

In your connected system, chances are that you already have some technical accounts and want to start using the IdM to manage them. Follow this tutorial to synchronize these technical accounts in IdM.

Have a standard system supporting provisioning. Any system can be used (MS AD, database…). The only things that need to be configured are mapping and roles.

Open the detail of the system and select Mapping. Click add new.

Create the mapping and select the entity type "Technical account". The account type selected must be "Technical".

After that, finish the mapping configuration as needed (and as usual). Since technical accounts are created via a wizard, you don't need to use scripts covering every potential scenario. During the creation process, users can manually set the values for the account.

If you want to use roles representing permissions in the target system (e. g., MS AD groups), you will have to create a separate set of roles. You can use standard synchronization for this. As of 13.0., however, during synchronization, these roles will not be assigned to the accounts.

In this step, you will create the technical account objects in the IdM using a standard synchronization. This is a relatively standard synchronization but you will have to make sure that identifiers are unique (which they should be in the target system anyway). Technical accounts themselves don't get many attributes which makes synchronization mapping easier. At the synchronization mapping detail, select your provisioning mapping as Connected mapping. The mapping should be created like this:

In the mapping configuration, you only need to fill the identificator of the technical account (typically the __NAME__ attribute).

Then, create a new synchronization and run it. New technical accounts will be created.

You can finish their configuration after they are synchronized. We recommend you at least set the guarantors for the accounts (since this information is unlikely to be available in the system, you probably cannot synchronize it).

A technical account can either be created by synchronization from a target system (if the account already exists), or a new account can be created via the wizard. This allows you to configure the details of the technical accounts.

Navigate to System > Accounts, click the Add button. Select "Technical account" from the windows.

Select your system, user type (needs to be a provisioning mapping), and the guarantor.

Click Next. Now you can edit the attribute values for the accounts. If you have mapping configured, you will see the default values. Make sure that the UID (typically __NAME__) is unique. Any value you change will be managed manually and will not be changed based on the mapping.

Click Next. You can now review the attribute values for the account.

If you are happy with them, click Next again. The account will be created. You can exit the wizard now.

Using the Technical Accounts module, you can perform various tasks related to managing technical accounts. These tasks cover different aspects of technical account management and are typically divided among specific types of users.

Each user type is responsible for a defined set of tasks. Tasks are assigned based on user responsibilities and assigned permissions (see permissions/evaluators section).

By selecting a specific user type, you can learn more about:

• the user’s function within the Technical Accounts module,
• the tasks assigned to that user type,
• how those tasks are carried out in practice.

This task structure, based on user types, ensures clear accountability, transparent processes, and simplifies the management of technical accounts within the organization.

Admin user type refers to a user who usually has the superAdminRole with the APP_ADMIN permission. This user can perform all operations and is not restricted by any permissions in IdM. Typically, this identity does not have an account in any connected system and is used only for technical access to IdM.

The Admin's tasks in the Technical Accounts module may include:

• ✏️creating and configuring systems for managing technical accounts,
• ✏️creating and setting up roles for other user types,
• 🚨handling incidents and providing support,
• ⛓️‍💥synchronizing and initially linking technical accounts with identities in IdM,
• ✏️creating new technical accounts.

Technical account guarantor user type is defined by permissions in specific roles assigned by the IdM administrator. Typically, the user has a role that includes permissions for managing technical accounts and their assigned roles. Common permissions (evaluators) include:

• TechnicalAccountByGuaranteedRoleEvaluator
• RoleRequestByTechnicalAccountGuarantorEvaluator
• RoleRequestByTechnicalAccountGuarantorEvaluator
• TechnicalAccountByGuarantorTransitiveEvaluator

For a description of permissions, see the section below.

The user's tasks may include:

• ✏️managing their own technical accounts,
• 🔑creating role requests to modify assigned roles for their technical account,
• 🔍viewing the status of role requests for their technical account,
• 🔍viewing currently assigned roles for their technical account.

Own technical account" means a technical account where the user is set as the guarantor.

The system owner is a user type who usually has permissions to configure and manage a system for which they are responsible. Their permissions typically include:

• access to system configuration (including mapping changes and manual synchronization runs),
• viewing the provisioning queue and its archive.

This user’s tasks may include:

• 🚨resolving issues with data provisioning to the system (e.g. system downtime, certificate changes, critical provisioning errors),
• ✏️performing bulk operations on the provisioning queue (e.g. deleting or restarting operations),
• 🔍monitoring the current status of connected systems.

A role guarantor is a user or a group of users who are responsible for a specific role or a set of roles in IdM. From a business perspective, this is usually a person responsible for managing access to certain permissions (e.g. in Active Directory) and ensuring that unauthorized users or accounts do not receive access they should not have.

In combination with the Technical Accounts module, the main responsibility of a role guarantor is to prevent technical accounts from receiving roles they should not have – for example, when a request is made by mistake. In such cases, the guarantor usually rejects the request.

The role guarantor's permissions are typically included in the default user role (userRole). This role usually allows the following actions:

• 🔍view roles where the user is set as guarantor,
• 🔑assign these roles to users or accounts,
• 🔑approve role requests where the user acts as guarantor – both for users and technical accounts,
• 🔍view all users (this is the default setting; it can be limited to a specific group),
• 🔍view all users who have roles where the user is guarantor,
• 🔍view all accounts that have roles where the user is guarantor,
• 🔍view assigned roles for users and accounts – but only roles where the user is guarantor (other roles are not visible).

In the context of the Technical Accounts module, the guarantor’s main role is to review and approve (or reject) role requests for technical accounts, and to monitor which accounts have these roles assigned.

A security user is typically responsible for reviewing and validating role assignments for both users and technical accounts. In practice, this means that no user or account should have a role (permission) that does not match their job position or intended purpose. The security user can verify this using the recertification process (this is a paid module and not included in the default IdM installation).

Typical permissions for this user type include:

• 🔍reading all users (including assigned roles, contracts, and other attributes),
• 🔍reading all accounts (including assigned roles),
• 🔍accessing the audit log of assigned roles and approval history,
• 📋generating reports of currently assigned roles for users and accounts,
• ✏️starting recertification processes (if the module is enabled),
• 🔑approving role requests – usually as the final step in the global approval workflow.

The following section describes how to configure permissions for the Technical Accounts module. All listed evaluators are available only after the module (idm-tech) is deployed. We recommend configuring them either in the main userRole or in specific roles related to the Technical Accounts module.

• @since 2.1.0
• An evaluator that defines the relationship between a role guarantor and a technical account.
• Its use allows the role guarantor to view technical accounts that have been assigned the role they are responsible for.

• @since 2.1.0
• An evaluator that defines the relationship between a technical account guarantor and role requests for the technical account they guarantee.
• Its use allows the technical account guarantor to view role requests for the technical account they are responsible for.

• @since 2.1.0
• An evaluator that defines the relationship between a user I have access to (such as my subordinate), who is also a guarantor of technical accounts, and the role requests for those technical accounts.
• Its use allows, for example, a manager to view role requests for technical accounts that are guaranteed by their subordinate.

• @since 2.1.0
• A transitive evaluator that defines the relationship between a technical account and its guarantor.
• Its use allows, for example, a manager to view technical accounts that are guaranteed by their subordinate.

• Check Role Assignment on Contract
• Check Role Assignment on Target System Account
• Find Systems Linked to a Technical Account
• Find the Owner of a Technical Account
• Add System Account Attributes to Technical Account Report
• Check Technical Accounts Assigned to a Role You Guarantee
• How a Role Guarantor Adds Their Guaranteed Role to Technical Accounts
• How a Role Guarantor Can Remove the Role They Guarantee from a Technical Account
• Viewing Role Requests for a Guaranteed Technical Account as Its Guarantor
• How a Role Guarantor Obtains Access to View Technical Accounts with Their Guaranteed Role
• How to Gain Rights to View Role Requests for a Technical Account You Guarantee
• How a Manager Gains Access to View a Subordinate’s Account
• How a Manager Can Get Permission to View Technical Accounts Guaranteed by Their Subordinate
• How to View Role Requests for Technical Accounts Guaranteed by Your Subordinate
• Create a new technical account
• Technical account synchronization

zde doplnit běžný troubleshooting, aktuálně nedokážu vyhodnotit

The Troubleshooting section provides solutions to common issues that may arise when working with the Technical Accounts module. It helps identify errors, understand their causes, and suggests steps to resolve them.

TODO doplnit

The Glossary section provides explanations of key terms used within the Technical Accounts module. It serves as a reference to help users understand the terminology, as well as the functions and roles associated with the module.