Create user

In the illustration above, the Identity Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Directory “Target” and are able to view the Identity Mappings which are configured for selected directory tasks. In this orchestration view admins are not allowed to change any mappings, those are presented as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. 

The creating new user orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory. It is important to be sure, that Identity Mapping, being used in Create User orchestration node, contains at least two additional Active Directory mappings: for “cn” and “sAMAccountName” attributes. If those two mappings are missing on a given configuration, it will not be presented on a dropdown.  

The creating new user orchestration node read attributes from Data Cards in question and execute API call to Azure. It is important to be sure, that Identity Mapping, being used in Create User orchestration node, contains at least three additional Azure AD mappings: for “displayName”, "mailNickname" and “userPrincipalName” attributes. Note: if those three mappings are missing on a given configuration, it will not be presented on a dropdown.

Creating new user activity notes:

• There are two ways to create the password for a new user for their first login.
  • Define “Default” password in the Provisioning Task -configuration view
    • That password will only be used by users, when they login into the system for the first time 
  • Generating random password in the workflow and select into which attribute on Identity Mapping data-card it was written to
  • In both cases the first time password “pwdLastSet” value is set to zero (0) to force a user to change their password after the first login
  • Possibility to choose if the password must change at the first login or not. Administrators can make the selection for this directly from the workflow User Creation orchestration node.
• There are different ways to provide password for the first login for the end-user. Depending on customers needs it is possible to use workflow functionalities to send the password directly to the end user via email or sms. Another option is to send the password for first login to the manager, who will provide it for the end-user. EPE’s Orchestration node itself DO NOT provide that functionality, it needs to be defined elsewhere. 
• The configuration of “Target” is done in the provisioning task configuration view. For creating new users, admins needs to make sure that there exists only one LDAP userbase / LDAP userfilter in order to avoid conflicts on the workflow
• Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions. 

Update User

In the illustration above, the Identity Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Active Directory “Target” and are able to view the Identity Mappings which are configured for selected AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented only as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. 

The update user orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory or execute API call to Azure AD.

User password update is not supported on this orchestration activity.

The configuration of “Target” is done in the provisioning task configuration view. For updating users, admins needs to make sure that there exists only one LDAP userbase / LDAP userfilter in order to avoid conflicts on the workflow.

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions. 

Activate / Deactive User 

In the illustration above admins choose the correct Active Directory “Target” and are able to view the Identity Mappings which are configured for selected AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented only as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. Inside this same node, administrators are able to choose the action what they are prefer to use “Activate” or “Deactivate”. 

Verify User

In the illustration above, the Identity Attribute Mappings are populated from the Provisioning tasks. Administrators choose the correct Active Directory from “Target” and are able to view what Identity Mappings are configured for the selected AD task. In this orchestration view you are not allowed to change any mappings, those are presented only as a visual aid. If there are needs to change the attribute mappings, those attributes must be defined in the provisioning task configuration view, in order them to be changed in the orchestration node. 

Within the Identity Mappings admins panel, admins are able to provide “IF” expression, which will form a LDAP query to verify if the user exists. It’s possible to select as many attributes from the Person Data Card as needed to confirm the uniqueness of a user. When an action takes place, those attributes will be read from the Data Card in question and will be compared to the appropriate AD attributes according to the “Target*“ Active Directory configuration. Admins can also choose to use “equal” or “not equal” to corresponding AD attribute by changing the “IF” expression. The “Save result*” field is used to define where the successful LDAP query results are saved, “true” if user was found or “false” otherwise. 

Key point to understand this node's mechanics is - while forming IF expression, admin needs to use Template's attributes, but in fact, values read from them, will be translated (mapped) to proper Active Directory attributes, according to Identity Mapping configuration and will be passed to Active Directory as a search query. 

Administrators has possibility to “check” Include OU subtree -property on this orchestration node to verify if user exists in the defined Organization Unit -subtree. If this administrator doesn’t select this option, orchestration node will only check the specific OU defined in the configuration. 

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions. 

How to read user's data from directory with workflow?

Since 2022.2 Efecte Provisioning Engine (EPE) introduces new workflow activity "Read User's data". Supported directories are Active directory, Azure AD, OpenLDAP and IBM. Info can be updated behind reference for example IGA account data can be updated from Identity storage. 

1. Create new Event-based provisioning for the workflow activity. Attribute mappings are populated from Provisioning task. Attribute mappings must be unique. 
   
   
   
2. Create new workflow orchestration node with activity Read User's data. Select just created event-based epetask to be target. Add unique person attribute, its used for updating right account information from directory to ESM. 
   
   

Unlock User

In the illustration above administrators can choose the correct Active Directory “Target”. The unlock user orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

It’s important to take into account in the configurations, that 'Person Attribute' should contain User's distinguishedName name.

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions. 

Delete User

In the illustration above administrators can choose the correct Active Directory “Target”. The delete user orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory.

For Active Directory-based configurations, 'Person Attribute' should contain User's distinguishedName name.

For Azure Active Directory-based configurations, 'Person Attribute' should contain User's ObjectGUID value.

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Remove User Attribute

In the illustration above administrators can choose the correct Active Directory “Target”. The remove user attribute orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory. In the property “Attribute(s) to remove” administrator can define the attribute, which will be removed from the Active Directory. NAME what you want to remove. On string can contain multi value attributes. like "City, CostCenter, mobile".

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions. 

Update User Distinguished Name value

In the illustration above administrators can choose the correct Active Directory “Target”. The Update user Distinguished Name Value orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory. 

In the field “Current Distinguished Name Value*” admin must select, from which attribute on given template/data-card, ‘old’ name of AD location will be read. Field “New Distinguished Name Value* selects attribute from given template/data-card, which will be used as a name of new AD location.  

With This activity admins are able for example to limit update action to ‘commonname’ attribute, but It’s required to give whole Distinguished value, example: 

Current Distinguished Name Value: CN=DemoAccount,OU=DemoUsers,DC=testad,DC=local 

New Distinguished Name Value: CN= DemoAccount,OU=OldDemoUsers,DC=testad,DC=local

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions. 

Reset User Password

In the illustration above administrators can choose the correct Active Directory “Target”. The Reset user password orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory. The Person and Password attributes should point to the template where the orchestration node finds the user’s data.  

User password value “pwdLastSet” is set to zero (1), which means that a user doesn’t need to change their password in the first login. From the EPE version 2022.3 forward we have implemented possibility to choose if the password must change at the first login or not. Administrators can make the selection for this directly from the workflow Reset User password orchestration node.

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

How to create custom objects with EPE?

Since 2022.2 Efecte Provisioning Engine (EPE) introduces new workflow activity "Create custom object". For example devices, contacts and applications can be now created with EPE towards directory (AD,Azure and OpenLDAP). 

[LDAP: error code 16 - 00000057: LdapErr: DSID-0C0910DA, comment: Error in attribute conversion operation, data 0, v4563]

How to update custom objects with EPE?

Since 2023.1 Efecte Provisioning Engine (EPE) introduces new workflow activity "Update custom object". For example devices, contacts and applications can be now updated with EPE towards directory (AD and Azure). 

How to delete custom objects with EPE?

Since 2023.1 Efecte Provisioning Engine (EPE) introduces new workflow activity "Delete custom object". For example devices, contacts and applications can be now deleted with EPE towards directory (AD and Azure).

Step-by-Step Instructions

Add User to Group

In the illustration above, the Person attribute configuration should point to the template where the orchestration node finds the user’s data (usually IGA account). The Role attribute needs to be configured to define where the orchestration node finds the available roles (directory groups where the user should be removed). There might be single or multiple attribute groups configured in a “Role attribute”. The list of available registered directory Tasks is fetched from the EPE-master. 

It is required to select the directory Task, because the Efecte Provisioning Engine orchestration node will use identity and access rights fields mapping to know, under which attribute code, the user’s and directory group distinguished names are stored. 

Exception handling:

• The result of a node will be in the “Completed” state only in the case when all user’s group memberships will be updated successfully. In the case when, for example, the user will be successfully removed from 5 out of 6 groups then the result of a node will be in the “Exception” state.
• Hence the mapping for distinguishedName JSON field, for both Identity and Access Right is required. If mapping won’t be found then the orchestration node will result in an “Exception” state.
• The attempt to remove a user from a group which they do not belong will end as a failure.
• The attempt to add a user to a group to which he already belongs will end as a failure.
• Details about successfully/unsuccessful updated user’s group membership can be found in logs.
• Provisioning and group membership exceptions are optional properties on this workflow node. Admins can configure this properties in use where exceptions can be written if any exceptions exists during the provisioning actions.

How to configure EPE to use OU from data card?

EPE Event-based provisioning task  provides possibility to choose if information of the organization unit (OU-path) for example new user creation is defined in the provisioning task or is it read from the ESM datacard. This feature decrease the amount of the needed event-based provisioning tasks. There are cases, where customers are creating new users to several OU-paths and with this approach we would use one provisioning task and part of the needed information is read from datacard. 

1. Go ESM Admin side and select IGA tab.
   
   
2. Select Event-based provisionings and the needed task. 
   
   
3. Set LDAP userBase / LDAP userfilter or/and LDAP groupBase / LDAP groupfilter to "Read OU path from the data-card". 
   
   
   
4. When the provisioning task configuration has been set “Read OU path from the datacard” the orchestration activities show you addition property (LDAP group- /userbase), where its possible to define the attribute from which attribute this information can be read. 
   
   

Create Group

In the illustration above, the Access Rights Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Active Directory “Target” and are able to view the Access Rights Mappings which are configured for selected AD tasks. In this orchestration view admins are not allowed to change any mappings, those are presented as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. 

The creating new user orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory. 

It is important to be sure, that Access Rights Mapping, being used in Create Group orchestration node, contains:

• at least four additional Azure AD mappings: for “displayName”, “mailEnabled”, “mailNickname” and “securityEnabled” attributes. 
• at least two additional Active Directory mappings: for “cn” and “sAMAccountName” attributes. 
  
  

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Update group

In the illustration above, the Access Rights Attribute Mappings are populated from Provisioning tasks. Admins choose the correct Active Directory “Target” and are able to view the Access Rights Mappings which are configured for selected AD tasks. 

In this orchestration view admins are not allowed to change any mappings, those are presented only as a visual aid. If any changes to the mappings are needed, those needs must be execute in the Provisioning task configuration view. 

The update group orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory or execute API call to Azure. 

The configuration of “Target” is done in the provisioning task configuration view. For updating groups, admins needs to make sure that there exists only one LDAP groupbase / LDAP groupfilter in order to avoid conflicts on the workflow.

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Delete Group

In the illustration above administrators can choose the correct Active Directory “Target”. The delete group orchestration node read attributes from Data Cards in question and execute LDAP command to Active Directory. 

For Active Directory-based configurations, 'Role group attribute' should contain group’s distinguishedName name.

For Azure Active Directory-based configurations, 'Role group attribute' should contain group’s ObjectGUID.

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Verify Group

In the illustration above, the Access Rights Attribute Mappings are populated from the Provisioning tasks. Administrators choose the correct Active Directory from “Target” and are able to view what Access Rights Mappings are configured for the selected AD task. In this orchestration view you are not allowed to change any mappings, those are presented only as a visual aid. If there are needs to change the attribute mappings, those attributes must be defined in the provisioning task configuration view, in order them to be changed in the orchestration node. 

Within the Access Rights Mappings admins panel, admins are able to provide “IF” expression, which will form a LDAP query to verify if the group exists. It’s possible to select as many attributes from the Data Card as needed to confirm the uniqueness of a group. When an action takes place, those attributes will be read from the Data Card in question and will be compared to the appropriate AD attributes according to the “Target*“ Active Directory configuration. Admins can also choose to use “equal” or “not equal” to corresponding AD attribute by changing the “IF” expression. The “Save result*” field is used to define where the successful LDAP query results are saved, “true” if group was found or “false” otherwise. 

Administrators has possibility to “check” Include OU subtree -property on this orchestration node to verify if group exists in the defined Organization Unit -subtree. If this administrator doesn’t select this option, orchestration node will only check the specific OU defined in the configuration. 

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.

Verify Group Membership

In the illustration above, the Identity Attribute Mappings are populated from the Provisioning tasks. Administrators choose the correct Active Directory from “Target” and are able to view what Identity Mappings are configured for the selected AD task. In this orchestration view you are not allowed to change any mappings, those are presented only as a visual aid. If there are needs to change the attribute mappings, those attributes must be defined in the provisioning task configuration view, in order them to be changed in the orchestration node. 

The “Save result*” field is used to define where the successful LDAP query results are saved, “true” if user was found or “false” otherwise. 

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions. 

Create Local User (in ESM)

In the illustration above, the Mappings are from the target template, no separate EPE task needed for this. The creating new local user orchestration node read attributes from Data Card in question and executes command to ESM. 

ESM Security log logs the following events of this node:

• Successful AND failed changes on User "security settings"
  • User level changes
  • Password
  • Username
• User permission changes
  • user given a role
• Creating a user

Update Local User Password (from ESM)

In the illustration above, the Mappings are from the target template, no separate EPE task needed for this. The updating local user orchestration node read attributes from Data Card in question and executes command to ESM. ESM Security.log logs events of this node. Note! Root user's password update is not allowed. 

Update Local User name (from ESM)
 

In the illustration above, the Mappings are from the target template, no separate EPE task needed for this. The updating local user orchestration node read attributes from Data Card in question and executes command to ESM. ESM Security.log logs events of this node. Note! Root user's username update is not allowed. 
 

Delete Local User (from ESM)
 

In the illustration above, the Mappings are from the target template, no separate EPE task needed for this. The delete local user orchestration node read attributes from Data Card in question and executes command to ESM. ESM Security.log logs events of this node. Note! Root user cannot be deleted with this node. 
 

Manage ProxyAddresses

There are three different possibilities: Set, Update and Remove proxyaddresses. 

• Set: admin selects one attribute in ESM's Workflow UI (can be single or multivalue attribute) - Then Workflow Node, contacts AD, finds user account and set's the value into proxyAddresses (this action is used to set the value to proxyAddresses the first time - previous value in AD is null).
  
  
• Update: admin selects two attributes in ESM's Workflow UI - one for CURRENT value, and the other - the NEW value. Then Workflow Node, contacts AD, finds user account and updates the existing proxyAddresses, finds the CURRENT value in the list, and changes its prefix from: SMTP: to smtp: - and adds NEW value with prefix SMTP: (the other values remain in proxyAddresses).
  
  
• Remove: admin selects one attribute in ESM's Workflow UI (can be single or multivalue attribute) - Then Workflow Node, contacts AD, finds user account and removes the value from proxyAddresses list (the other values remain in proxyAddresses).

Run provisioning task

This activity is used when all information from the directory is immediately needed back. Supported directories are Active directory, Azure AD, OpenLDAP and IBM.  

In the illustration above administrators can choose the correct Directory “Target”. Run provisioning task orchestration node read attributes from Active Directory to IGA Accounts. 

Requirements for the "Target" EPEtask are:

• Task must be of type "Schedulable task" not event-based
• Workflow's Template must be the same as Identity mapping Template 
• Task must be scheduled at some time - it marks a task to be "enabled" then
• Mappings must be distinct, no duplicated mappings in the task
  
  

In this orchestration view you are not allowed to change any mappings, those are presented only as a visual aid. If there are needs to change the attribute mappings, those attributes must be defined in the provisioning task configuration view, in order them to be changed in the orchestration node. 

Provisioning exception is an optional property on this workflow node. Admins can configure this property in use where exceptions can be written if any exceptions exists during the provisioning actions.