Configuring Integrations for Lifecycle Management

Enabling Veza to make changes within Active Directory, Echange Server, and Workday based on Lifecycle Management policies and rules.

See the following sections for steps to grant Veza permission to commit changes within compatible integrations, and enable provisioning for Workday (source), Custom Identity Providers (source), Active Directory (target) and Exchange Server (target).

Enable Provisioning for Active Directory

Enable provisioning by creating an additional user that Veza can connect as, with mimum-required capabilities to write into Active Directory. Specify the additional username and password when configuring the Active Directory integration.

Follow the guide to create an Active Directory integration, or use an existing integration.
Create an additional AD User with permission to create AD users, add users to groups, and disable users.
When configuring the AD integration in Veza, check the box to Enable Provisioning.
Enter the Provisioning User Name and Provisioning User Password.

Note: The AD User created for provisioning can be the same as the primary AD User created for extraction, provided that the user has the required permissions to:

Create AD Users.
Add users to groups.
Disable users.

No additional administrator privileges are required.

Create an additional Active Directory User

From a Domain Controller or other workstation with management tools installed, open Active Directory Users and Computers
Locate the Organizational Unit where the user account will be created
Right-click the Organizational Unit, select New, then click User
1. Complete the details in the dialog box to create the new user account

Permissions Configuration

To provide the newly created user with the ability to configure accounts in an Organizational Unit within the Active Directory, follow these steps:

In Active Directory Users and Computers, locate the Organizational Unit to be controlled
Right-click the Organizational Unit, select All Tasks, then click Delegate Control...
1. Complete the dialog box to allow the new user to control the Organizational Unit:
  1. On the Users and Groups page, click Add, type the name of the new user, click Check Names, then click OK
  2. On the Tasks to Delegate page, select the checkboxes for the following options:
    Create, delete, and manage user accounts
    Reset user passwords and force password change at next logon
    Read all user information
    Modify the membership of a group

Alternative PowerShell Instructions

To instead create the user with PowerShell, run the following command, substituting items in angled brackets (<>):

New-ADUser -Name "Veza AD Provisioner" -Path "OU=<your_OU>,DC=<domain>,DC=<tld>" -GivenName "Veza" -Surname "AD Provisioner" -SamAccountName "veza-ad-provisioner" -AccountPassword (ConvertTo-SecureString -AsPlainText “<password>” -Force ) -ChangePasswordAtLogon $True -DisplayName "Veza AD Provisioner" -Enabled $True

To delegate control of an Organizational Unit to the user account, run the following, substituting items in angled brackets (<>):

Import-Module ActiveDirectory
$OrganizationalUnit = "OU=<your_OU>,DC=<domain>,DC=<tld>"
$Users = [GUID]"bf967aba-0de6-11d0-a285-00aa003049e2"
Set-Location AD:

$User = Get-ADUser -Identity "veza-ad-provisioner"
$UserSID = [System.Security.Principal.SecurityIdentifier] $User.SID
$Identity = [System.Security.Principal.IdentityReference] $UserSID

$RuleCreateDeleteUsers = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $Identity, "CreateChild, DeleteChild", "Allow", $Users, "All"

$ResetPassword = [GUID]"00299570-246d-11d0-a768-00aa006e0529"
$RuleResetPassword = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($Identity,
"ExtendedRight", "Allow", $ResetPassword, "Descendents", $Users)

$ACL = Get-Acl -Path $OrganizationalUnit
$ACL.AddAccessRule($RuleCreateDeleteUsers)
$ACL.AddAccessRule($RuleResetPassword)

Set-Acl -Path $OrganizationalUnit -AclObject $ACL

Enable Provisioning for Exchange Server

To enable the Create Email Address action for provisioning policies, you will need to configure an Exchange Server integration in Veza, and run a VezaProvisioner.msi installer that will run on the Windows Server to create email addresses for users created in Active Directory. The installation program is provided by the Veza support team. Follow the steps below to:

Get the local path to PowerShell executable and scripts on the Exchange Server.
Create a domain user with permission to run Exchange Management Shell and commands.
Create an application pool in IIS for the Veza Provisioner application.

Configure Exchange Server

Find the “Exchange Management Shell” shortcut.
1. You can do this by searching on the Start Menu, right clicking the icon, and choosing More > Open File Location.
2. An Explorer window will open showing the Start Menu shortcut. Right click the icon and choose Properties.
Inspect the properties in the Shortcut tab. Copy the value in the Target field.
Find 2 paths from target: a PowerShell.exe path and a PowerShell script path.
- For example, for the target: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell "
- The PowerShell path is C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe . This is “PowerShell Path” when adding exchange server provider in Veza.
- The PowerShell script path is C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1. This is “Remote Exchange Path” when adding exchange server provider in Veza.
Prepare a domain user to access Exchange Server. The user needs permission to run the “Exchange Management Shell” shortcut and Exchange Server commands.
Install VezaProvisioner.msi
Open IIS and add an application pool.
Give the application pool a name.
Set a user identity for the application pool:
1. Right click on the new application pool and choose Advanced Settings.
2. Under Process Model, enter the user identity.
Add application to “Default Web Site”
1. Specify the VezaProvisioner and the application pool you just created.
Set authentication for the Veza Provisioner:
1. Disable “Anonymous authentication” and enable “Basic authentication”

Register the Exchange Server integration in Veza

Go to Configurations > Integrations. Click Add New and pick Exchange Server. Check the box to Enable Provisioning and enter the required fields:

Field Description

Field	Description
Insight Point	If Veza will use an Insight Point to access the Exchange Server, choose it from the list.
Name	A friendly name to identity the integration on the Integrations list.
Instance URL	The URL to access the IIS site we added. It should be `https://<domain or ip of the exchange server host>/VezaProvisioner`.
Username	The domain user name of the user created above.
Password	The password of the user created above.
PowerShell Path	The PowerShell executable path in step 3.
Remote Exchange Path	The PowerShell script path in step 3.

Insight Point

If Veza will use an Insight Point to access the Exchange Server, choose it from the list.

Name

A friendly name to identity the integration on the Integrations list.

Instance URL

The URL to access the IIS site we added. It should be https://<domain or ip of the exchange server host>/VezaProvisioner.

Username

The domain user name of the user created above.

Password

The password of the user created above.

PowerShell Path

The PowerShell executable path in step 3.

Remote Exchange Path

The PowerShell script path in step 3.

Enable Provisioning for Workday

To enable Workday as a provisioning source, follow the instructions to add a Workday integration, and choose the Enable Provisioning option when adding the provider on the Veza Configurations page. If you've already configured a Workday integration, Edit the configuration and enable the option.

Custom Attributes: To enable Provisioning Policies that include custom attributes you have created for Workers, define the attributes to discover in the Custom Properties section of the Workday configuration.

Email Write Back: For provisioning flows that include creating Exchange Server email addresses for new users, Veza can optionally write back the change by updating the Email attribute for the original Workday Worker.

API Calls Used:

Veza discovers metadata in Workday using WQL queries to built-in tables allWorkdayAccounts, allWorkers., securityGroups., domainSecurityPolicies., businessProcessTypes.

To write provisioned user emails back to Workday (if enabled), Veza makes API calls:

%s/ccx/api/person/v3/%s/workContactInformationChanges/%s/emailAddresses
%s/ccx/api/person/v3/%s/workContactInformationChanges/%s/submit
%s/ccx/api/staffing/v5/%s/workers/%s/workContactInformationChanges

Follow the steps below to enable email write back. The instructions assume you have already created a Workday Security Group, Integration System User, and API Client for the Veza integration:

Create Workday Business Process Security Policy

Log into Workday and search for Edit Business process security policy. Under Business Process Type, choose Work Contact Change.
Find the section with Initiating Action: Change Work Contact Information (REST Service). Use the input field to create a Segment-Based Security Group.
Under Group Criteria, add the security group created for the Veza integration, and add “Worker” scope to Access Rights. Save the configuration.
The security group should now appear in the Initiating Action Security groups list.
Click OK at the bottom of the page and click Done to confirm. The security change is not effective until an admin runs Activate Pending Security Policy Changes.
Go back to the Workday main page and search for Activate Pending Security Policy Changes. Add a comment, review the changes and click‘OK’.
Go back to Business Process Security Policy to verify that ‘work contact change’ has the groups under REST service.

Update Security Group Permissions

Open the Maintain Permissions for Security Group dialog to add the following Domain Permissions to the security group you created:

Person Data: Work Email (View and Modify)
Person Data: Work Contact Information (View and Modify)
Worker Data: Staffing (View and Modify)
Worker Data: Public Worker Reports (View and Modify)
System: Security Administration (View and Modify)
Workday accounts (View and Modify)

Add scopes for the Workday API client

Use the Edit API Client to manage the API client configuration.

To access worker data you will need following scopes (functional areas):

Staffing
Contact Information
System
Tenant Non-Configurable

Omitting the scopes will result in insufficient permission errors when attempting to write back email changes. This configuration is for adding email to workers on Workday only. The required REST API scope when integrating with Workday for extraction is different.

Enable Provisioning for a Custom Identity Provider

If your organization does not use Workday, you can use Open Authorization API to submit user metadata for any system compatible with the Custom Identity Provider template.

Use a custom provider as a provisioning source

Set the provisioning boolean to true when creating an OAA provider to enable provisioning:

curl -X POST 'https://<veza_url>/api/v1/providers/custom' \
-H 'authorization: Bearer <access_token>' \
--data-binary '{"name":"Custom Provisioning Provider","custom_template":"identity_provider", "provisioning": True}'

The response will return the custom provider ID. Use the ID to create a data source:

curl -X POST 'https://<veza_url>/api/v1/providers/custom/<provider_id>/datasources' \
-H 'authorization: Bearer '<access_token> \
--data-binary '{"id":"<provider_id>", "name":"Provisioning Data Source"}'

Once created, you can populate the data source with user metadata:

curl -X POST 'https://<veza_url>/api/v1/providers/custom/<provider_id>/datasources/<datasource_id>:push' \
-H 'authorization: Bearer '<access_token> \
--compressed --data-binary @payload.json

When enabled, Veza can trigger actions and provision users based on the metadata in an OAA push API payload. The custom data source will be available when creating Provisioning Rules and Provisioning Policies.

Custom provider template

See Custom Identity Provider Template and the Open Authorization API overview for more information about registering a custom provider and uploading a payload containing user details in JSON format.

To enable Veza to read custom identity metadata and trigger provisioning rules based on user attributes, custom IdP payloads must contain a custom_property_definition such as in the example:

{
  "json_data": {
    "name": "CustomIdP1",
    "idp_type": "CustomIDP",
    "custom_property_definition": {
      "user_properties": {
        "cus_location": "STRING",
        "cus_employment_status": "STRING",
        "cus_hire_date": "STRING",
        "cus_name_of_manager": "STRING",
        "cus_termination_date": "STRING",
        "cus_jobtitle": "STRING"
      }
    },
    "domains": [
      {
        "name": "CustomIdPDomain"
      }
    ],
    "groups": [
      {
        "name": "Johnson Team",
        "identity": "Johnson Team"
      }
    ],
    "users": [
      {
        "name": "John Smith1",
        "identity": "jsmith1",
        "manager_id": "tjohnson",
        "groups": [
          {
            "identity": "Johnson Team"
          }
        ],
        "full_name": "John Smith1",
        "custom_properties": {
          "cus_location": "CA San Francisco",
          "cus_employment_status": "Active",
          "cus_hire_date": "2023-09-06",
          "cus_termination_date": "2023-09-11",
          "cus_name_of_manager": "Johnson Tim",
          "cus_jobtitle": "engineer"
        },
        "is_active": True
      }
    ]
  }
}

Note that when pushing the json_data payload, it must contain a single string, for example:

{
  "id": "532f6fe3-189f-4576-afdf-8913088961e4",
  "data_source_id": "b6a32af6-b854-47e1-8325-e5984f78bb4d",
  "json_data": "{\n\"name\":\"CustomIdentityProvider\",\n\"idp_type\": ... "
}