Managing Target Systems

The preferred method is to control access rights via group memberships. Each group defines a set of access rights in the connected system regarding a set of resources. The meaning of a group is only visible from the group name. DirX Identity does not handle or store any discrete access control information.

Assigning a user a group either directly or via permissions and roles gives the user the right to handle the defined resource accordingly. Removing the user from the group revokes the access rights. DirX Identity supports group-side and account-side memberships. In group-side membership, the group holds the accounts as members. In account-side membership, the account holds the groups as members.

Fortunately, most connected systems today use the group-based access control.

You should try to work with account-side memberships as much as possible, because typically all users of a company can be members of a single (company) group. If a company has 500,000 users, this results in 500,000 group members. Handling such large groups is a problem for LDAP directories. On the other hand, the number of groups is typically much lower than the number of users in a large company, and there will be no user that is a member of all groups, which means that the user has full access to all resources in the company.

We recommend that you set up the target system in the Identity Store in account-side mode. If the connected system is not able to work in this mode, you can use cross-membership configuration for the Provisioning workflows to manage this problem. See the section "Cross-Membership Scenario" in the DirX Identity Application Development Guide for more information.

Some connected systems do not support the concept of group-based access control.In this case, access control is performed via attributes at the user’s account.To keep a unique method on the Identity Store side, we use group-based assignment of access rights as well.These groups possess obligations that set or reset the relevant account attributes.

The groups and the group memberships exist only in the Identity Store.Only the accounts with the access right-relevant attributes are synchronized between the target system and the connected system.Special validation rules can be established to create the relevant group memberships if the attributes are changed on the connected system side.

A prominent example of an attribute-based connected system is Microsoft Exchange.The attributes for the mailbox are held at the Active Directory Account.

For more information, read the sections about validation rules in the section "Managing Rules" in the chapter "Managing Policies".To understand obligations, read the section "Handling Attribute-based Access Rights" in the DirX Identity Customization Guide.

To create a target system with DirX Identity Manager (Provisioning):

If you have created a virtual target system, you may need to customize the target system’s properties. These properties are available on the target system’s Advanced and Options tabs. The DirX Identity Customization Guide provides further details on how to set up these properties to correspond to your virtual target system.

During the privilege resolution process, DirX Identity Provisioning automatically creates target system accounts without any administrator interaction. As a result, DirX Identity Provisioning requires that you provide it with the information it needs about how to create the target system account names and passwords and other required attributes so that it can perform this automatic function. You can:

To accommodate an individual connected system’s requirements for account and group descriptions, DirX Identity Provisioning supplies template descriptions of account and group objects and allows you to customize them to a particular target system’s account and group descriptions. These templates are located within each target system’s Configuration folder, as follows:

To edit these descriptions with DirX Identity Manager (Provisioning):

Now you can use the object description editor to specify:

The DirX Identity Customization Guide describes the structure of these files and how to modify them.

Alternatively, you can use DirX Identity Manager (Provisioning) Export text function to write the description to a file, and then use your favorite XML editor to edit it within the file system. You then use DirX Identity Manager (Provisioning) Import text function to import the file back into the Identity Store (Provisioning Configuration).

Note that during an upgrade installation of DirX Identity your versions of the account and group object and property page descriptions are preserved. See "Upgrading Customized Descriptions" for further details.

The initial load workflow is a batch workflow that you use to load a snapshot of the connected system’s accounts and groups into the Identity Store (Provisioning Configuration). DirX Identity Provisioning supplies an initial load workflow template (the validation workflow is used here) that is copied by the target system creation wizard. This design ensures that the workflow is also correctly configured.

If you have extended the account or group object descriptions, you may need to adapt the mapping of the workflow. Use the DirX Identity Manager (Connectivity) Configure Workflow wizard to adapt the mapping (and maybe other parameters) as follows:

The DirX Identity Connectivity Administration Guide and the DirX Identity Application Development Guide provide more information about workflow configuration parameters and how to use DirX Identity Manager (Connectivity) to configure them.

To run the initial load workflow, click the target system in the Target System view and then select Connectivity → Validation → Run Workflow from the context menu. Alternatively, you can use the DirX Identity Manager’s Connectivity view to run the initial load workflow by hand.

The workflow exports all accounts and groups and the relationships between them from the connected system and imports them into the target system subtree in the Identity Store (Provisioning Configuration).

The first execution of this workflow runs in mode "initial load". All subsequent executions run in mode "validation". The mode sequence is controlled by the Last validation field on the General tab. If it is empty, the workflow runs in "initial load" mode, otherwise it runs in "validation" mode.

To re-run the initial load workflow if it fails to complete due to a network or database failure, just clear the Last validation field before the run.

The DirX Identity Connectivity Administration Guide provides more information about how to use DirX Identity Manager (Connectivity) to run and monitor a workflow.

Note that the difference between "initial load" and "validation" mode is only that the validation mode sets the ToDo fields at accounts and groups.

To automate tasks in target system management, you may need to configure some consistency rules and validation rules. For information on how to check and automatically handle account-group assignments with validation rules, see the section "Checking Account-Group Assignments".

DirX Identity Provisioning provides the following consistency rule templates that you can copy and customize:

Note that you can use event-based processing workflows for accounts. These workflows have a configurable feature to associate accounts to users. This is especially useful when new accounts are added during a validation workflow. Then the accounts are immediately bound to users.

Read the DirX Identity Application Development Guide for information about synchronization and validation workflows and how to set them up and configure them.

The connected system administrator generally does not need to create, delete or modify personal connected system accounts because DirX Identity Provisioning automatically handles these tasks. DirX Identity Provisioning creates an account when a user is granted his first access right in the target system and disables the account when the last right has been revoked.

However, the synchronization and validation of the remote connected system can reveal differences in the target system object states in the Identity Store (Provisioning Configuration). The validation workflow detects accounts, groups, and account-group memberships that have been created or deleted in the connected system independently of a DirX Identity Provisioning request. The workflow notifies you about these objects by writing messages into their To do fields. As a result, you should periodically use the To do query folder to search for accounts (and other objects) in an inconsistent state, and follow up with the appropriate actions, as described in the topic "Handling The Results of the Validation Workflow".

The topic "Handling Imported Accounts" describes the account management functions that you need to perform when you add a target system to the Identity Store (Provisioning Configuration).

Managing target system accounts comprises these concepts:

In general, you will only need to perform these tasks as the result of some unusual condition; these tasks are not typical day-to-day maintenance tasks.

Privileged accounts typically come with the initial installation of a target system. Accounts like "root" for a UNIX system or "Administrator" for a Windows system already exist and are not bound to a specific user entry.

Any user can use a privileged account as long as he can authenticate with this account: he must know the password of this account or his certificate must be assigned to this account (this method is only supported by some target systems).

DirX Identity’s role-based management allows for managing password access to these privileged accounts. The following figure illustrates this concept:

The figure shows that assignment of a role (Role Y) assigns via permissions (Permission Y) one or more groups in different target systems to a user (Group user rights). The necessary accounts (Personal Account …​) are created automatically and assigned to these groups. The accounts are linked via the dxrUserLink attribute to the user entries.

If Role X is assigned to the user, then via Permission X a set of privileged groups may be assigned. It does not imply the creation of personal accounts; only a link is set from the corresponding privileged accounts to the user entries (attribute dxrUsedby).

As a result, the user can now read the passwords of the assigned privileged accounts in clear text. The system can also copy the certificates of the user to this account. Provisioning of the password and the certificates to the connected system allows accessing the target system with these credentials.

If the role assignment is removed, the dxrUsedBy attribute is deleted. Because the user could still remember the old password, the system automatically changes the password. This action guarantees that only users who are still assigned to the privileged account can read the password. The system also removes all certificates of the user from the account, which disables access to the connected system.

To handle other critical situations, DirX Identity comes with a set of account password management services. See the DirX Identity Application Development Guide for more information.

The next sections describe the management of privileged accounts in more detail.

Functional accounts can also come with the initial target system.Examples of functional accounts include a trainee account, a meeting room account, or a group mailbox account.

You can choose to handle a functional account as a privileged account or as a personal account of a functional user.If you have a scenario similar to the one described in "Managing Privileged Accounts", where multiple administrators use the same account to log on to a system, it is convenient to model this situation with a privileged account.If you have several different functional accounts, it makes sense to create a functional user for each functional account.You then use the sponsor link to associate the functional user with its responsible user.The account is completely managed by the DirX Identity privilege resolution process and is assigned to the functional user as his personal account.For details on creating a functional user, see the chapter "Managing Functional Users".

You can import groups and group from target structures via the validation (optionally in initial load mode) workflows or create groups by hand within the DirX Identity Manager.

To add a new target system group:

Manager returns an error if the name you supply for the account is not unique.

For hierarchical target systems, you can structure your groups with containers:

In some cases, you may need to make changes to a target system group. For example, you may need to:

All of these properties are available as attributes of the target system group object. To change a group’s attributes:

DirX Identity allows using group folders and hierarchies. With this feature:

Creating group folders in DirX Identity requires that you customize the target system workflows.

This section explains the options for handling imported groups. Imported groups are immediately set to state ENABLED. The following figure illustrates the options for handling imported groups.

Processing tasks on the imported groups after the initial load workflow has executed include:

The target system workflows - especially the validation workflows - import the accounts and groups, and also import their memberships: the account-group assignments. They assign the IMPORTED state to newly imported assignments. The following figure illustrates the alternatives for managing imported group memberships.

To display the memberships of the group, select it in the subtree, then click the Member tab. Manager displays the accounts that are members of this group and the account-group assignment state. You can perform these tasks:

After performing these tasks, you should not find any more group memberships in state IMPORTED.Use the todoMemberhips query folder to check on it.

If the member is a group, Manager displays the state NESTED.Account members of the nested group are also shown with state NESTED.

You can delete a target system group by hand.To delete a group, right-click it in the subtree and then click Delete.DirX Identity Provisioning changes the group’s state to DELETED, that is, the group is not immediately and physically deleted.

The target synchronization workflow attempts to delete the group from the connected system the next time it runs.If the operation is successful, it sets the group’s dxrTSState to DELETED.Running the consistency rule cleanupDeletedObjects will remove the group if its audit trail is empty.