Active Directory

Configuring the Active Directory integration for Veza Lifecycle Management

Overview

The Veza integration for Active Directory enables automated user lifecycle management, including user provisioning and deprovisioning, group membership management, and attribute synchronization.

Action Type	Description	AD Users	AD Managed Service Accounts
SYNC_IDENTITIES	Synchronizes identity attributes between systems, with options to create new identities and update existing ones	✅	✅
MANAGE_RELATIONSHIPS	Controls entitlements such as group memberships and role assignments for identities	✅	❌
DEPROVISION_IDENTITY	Safely disables access for identities while preserving attributes for audit	✅	❌
CREATE_ENTITLEMENT	Creates entitlements such as Active Directory groups	✅	❌
RESET_PASSWORD	Allows password reset operations for Active Directory users	✅	❌
DELETE_IDENTITY	Permanently deletes the identity from Active Directory	✅	✅
SOURCE_OF_IDENTITY	Active Directory can act as a source system for identity lifecycle policies	✅	❌

Non-Human Identity (NHI) Support: Active Directory Managed Service Accounts support a simplified action set designed for service account lifecycle needs. See Managed Service Accounts below for details.

This document includes steps to enable the Active Directory integration for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.

Enabling Lifecycle Management for Active Directory

Prerequisites

1. You will need administrative access in Veza to configure the integration.

2. Ensure you have an existing Active Directory integration in Veza or add a new one for use with Lifecycle Management.

3. Verify your Active Directory integration has completed at least one successful extraction.

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create an Active Directory integration

3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your Active Directory data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for Active Directory in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

2. Search for the integration and click the name to view details

3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

1. Create a Service Account

Create a dedicated AD user with the minimum required permissions:

Using Active Directory Users and Computers:

1. Open Active Directory Users and Computers

2. Navigate to the target Organizational Unit

3. Right-click > New > User

4. Complete the new user details form

   • Recommended name: "Veza AD Lifecycle Manager"

   • Set a strong password

   • Uncheck "User must change password at next logon"

Using PowerShell:

New-ADUser -Name "Veza AD Lifecycle Manager" `
    -Path "OU=<your_OU>,DC=<domain>,DC=<tld>" `
    -GivenName "Veza" `
    -Surname "AD Lifecycle Manager" `
    -SamAccountName "veza-ad-lcm" `
    -AccountPassword (ConvertTo-SecureString -AsPlainText "<password>" -Force) `
    -ChangePasswordAtLogon $False `
    -DisplayName "Veza AD Lifecycle Manager" `
    -Enabled $True

2. Configure Required Permissions

Grant the service account permissions to manage users in the target OUs:

Using Active Directory Users and Computers:

1. Navigate to the target Organizational Unit

2. Right-click > Delegate Control

3. Click Add and enter the service account name

4. Select these delegated tasks:

   • Create, delete, and manage user accounts

   • Reset user passwords and force password change

   • Read all user information

   • Modify group membership

Using PowerShell:

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-lcm"
$UserSID = [System.Security.Principal.SecurityIdentifier] $User.SID
$Identity = [System.Security.Principal.IdentityReference] $UserSID

# Create permission for managing users
$RuleCreateDeleteUsers = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $Identity, "CreateChild, DeleteChild", "Allow", $Users, "All"

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

# Apply permissions
$ACL = Get-Acl -Path $OrganizationalUnit
$ACL.AddAccessRule($RuleCreateDeleteUsers)
$ACL.AddAccessRule($RuleResetPassword)
Set-Acl -Path $OrganizationalUnit -AclObject $ACL

3. Configure the Integration in Veza

1. Navigate to Configurations > Integrations

2. Either:

   • Create a new Active Directory integration

   • Edit an existing Active Directory integration

3. Enable Lifecycle Management:

   • Check Enable Lifecycle Management

   • Enter the Lifecycle Management Username (service account created above)

   • Enter the Lifecycle Management Password

4. Save the configuration

The AD user created for lifecycle management can be the same as the primary AD user created for extraction, provided that the user has all the required permissions listed above.

Supported Actions

Active Directory can serve as a source for identity information in Lifecycle Management Policies. User identity details are synchronized from Active Directory, with changes propagated to connected systems.

Active Directory can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.

The integration supports the following lifecycle management Actions:

Sync Identities

Synchronizes identity attributes between systems, with options to:

• Create new identities if they don't exist

• Update attributes of existing identities

• Enable continuous sync to keep attributes aligned with the source of truth

Unique Identifiers

Active Directory uses composite unique identifiers to locate users. Only one unique identifier can be specified per action:

• account_name (sAMAccountName) - Default unique identifier

• distinguished_name - Full LDAP path (e.g., CN=John Doe,OU=Users,DC=company,DC=com)

• user_principal_name - Login format (e.g., [email protected])

The following attributes can be synchronized:

Active Directory User Attributes

Property	Required	Type	Description	Notes
account_name	Yes	String	User's account name (sAMAccountName)	Can be used as unique identifier
distinguished_name	Yes	String	Full LDAP distinguished name path	Can be used as unique identifier
user_principal_name	Yes	String	User's principal name (login format)	Can be used as unique identifier
account_expires	No	Date/Time	Account expiration date and time
city	No	String	City
company	No	String	Company name
country_code	No	String	ISO 3166 Alpha-2 country code
country_or_region	No	String	Country or region name
department	No	String	Organizational department
description	No	String	User description
display_name	No	String	Display name
email	No	String	Email address	Can be used as unique identifier
given_name	No	String	First name
manager_id	No	String	Manager's sAMAccountName
office	No	String	Office location
physical_delivery_office_name	No	String	Physical office name
postal_code	No	String	Postal/ZIP code
primary_group_dn	No	String	Distinguished name of primary group
state_or_province_name	No	String	State or province
street_address	No	String	Street address
sur_name	No	String	Last name/surname
title	No	String	Job title
user_account_control	No	String List	Account control flags	Comma-separated flag names (e.g., NORMAL_ACCOUNT,ACCOUNTDISABLE). See Controlling Account State for details.

Controlling account state with user_account_control

The user_account_control attribute controls the account state during identity synchronization, enabling scenarios like creating pre-staged disabled accounts or setting custom account flags.

Supported flags:

Flag Name	Description
NORMAL_ACCOUNT	Standard user account (required for most scenarios)
ACCOUNTDISABLE	Disables the account
DONT_EXPIRE_PASSWORD	Password never expires
PASSWD_NOTREQD	No password required
PASSWD_CANT_CHANGE	User cannot change password
SMARTCARD_REQUIRED	Smart card required for login

Combine multiple flags with commas. For example, NORMAL_ACCOUNT,ACCOUNTDISABLE creates a disabled account (equivalent to integer value 514).

Input format requirements:

• Use flag names only: Enter the exact flag names shown above (e.g., NORMAL_ACCOUNT). Integer values like 512 or 514 are not supported and will be ignored.

• Include NORMAL_ACCOUNT explicitly: When setting custom flags, you must include NORMAL_ACCOUNT in the list to maintain standard account behavior. For example, use NORMAL_ACCOUNT,ACCOUNTDISABLE rather than just ACCOUNTDISABLE.

• Invalid flags are silently ignored: Unrecognized flag names are skipped without warning. Always verify flag names match exactly (case-insensitive).

Common combinations:

Flags	Equivalent Integer	Use Case
NORMAL_ACCOUNT	512	Standard user provisioning (default)
NORMAL_ACCOUNT,ACCOUNTDISABLE	514	Pre-staging accounts before start date
NORMAL_ACCOUNT,DONT_EXPIRE_PASSWORD	66048	Service accounts
NORMAL_ACCOUNT,ACCOUNTDISABLE,DONT_EXPIRE_PASSWORD	66050	Pre-staged service accounts

If user_account_control is not specified in your transformer, the default value (512) is used and accounts are created in an enabled state.

Example use cases:

• Pre-staged accounts: Create accounts in a disabled state before an employee's start date, then enable them via a separate workflow when the start date arrives

• Approval workflows: Create disabled accounts that require manager approval before activation

• Service accounts: Set specific flags like "password never expires" for service accounts

Updating existing accounts: The user_account_control attribute can also update existing users, not just new accounts. To enable a previously disabled account, sync user_account_control with NORMAL_ACCOUNT only (omitting ACCOUNTDISABLE). This is useful for workflows that activate pre-staged accounts on an employee's start date.

Graph visibility: Disabled users (accounts with ACCOUNTDISABLE flag set, such as value 514) are filtered out during Active Directory extraction and will not appear in the Veza graph. This is expected behavior—once the account is enabled, it will appear in the graph after the next extraction.

For a complete list of userAccountControl flag values and their meanings, see Microsoft documentation: UserAccountControl flags.

Manage Relationships

Controls relationships between users and Active Directory groups:

• Entity Types: Active Directory Groups

• Assignee Types: Active Directory Users

• Supports Removing Relationships: Yes

Both adding and removing group memberships are supported. Group memberships can be managed individually or removed in bulk during deprovisioning.

Deprovision Identity

When a user is deprovisioned in Active Directory:

• Entity Type: Active Directory User

• Method: Account Disabled (sets userAccountControl flags to NORMAL_ACCOUNT,ACCOUNTDISABLE)

• Remove All Relationships: Yes (optional - group memberships can be removed)

What is preserved:

• User account structure (not deleted)

• All user attributes (name, email, title, etc.)

• Audit history and account information

• Account can be reactivated by re-enabling

What changes:

• Account is disabled (login prevented)

• Group memberships are removed (optional, based on workflow configuration)

• User cannot authenticate or access AD resources

The following unique identifiers can be used to locate the user:

Unique Identifiers for Deprovision

Property	Type	Description	Notes
account_name	String	User's account name (sAMAccountName)	Can be used as unique identifier
distinguished_name	String	Full LDAP distinguished name path	Can be used as unique identifier
user_principal_name	String	User's principal name (login format)	Can be used as unique identifier
email	String	Email address	Can be used as unique identifier

Create Entitlement

Creates new Active Directory groups:

• Entity Type: Active Directory Group

• Required Attributes: name

• Optional Attributes: description, group_type, is_security_group, member_of, account_name, organizational_unit_dn

Group Creation Attributes

Property	Required	Type	Description	Notes
name	Yes	String	Group name	Maximum 64 characters
account_name	No	String	Group account name (sAMAccountName)	Maximum 256 characters, must be unique
description	No	String	Group description
group_type	No	String	Type of group	Values: Domain, System, Global, Universal, App Basic, App Query
is_security_group	No	Boolean	Whether this is a security group
member_of	No	String	Distinguished name of parent group(s)
organizational_unit_dn	No	String	Distinguished name of target OU

Reset Password

Resets a user's password in Active Directory:

• Entity Type: Active Directory User

• Idempotent: No (generates a new password with each execution)

• Password Options:

  • Configurable password complexity (length, character types, excluded characters)

  • Option to require password change on next login

  • Passwords must comply with Active Directory domain password policy

The Reset Password action is non-idempotent. Each execution generates a new password, even if the action is run multiple times.

Password Complexity Options:

• Length: Configurable minimum password length

• Character Types: Uppercase, lowercase, numbers, special characters

• Disallowed Characters: Specify characters to exclude from generated passwords

• Require Change: Force user to change password on next login

The following unique identifiers can be used to locate the user:

Unique Identifiers for Password Reset

Property	Type	Description	Notes
account_name	String	User's account name (sAMAccountName)	Can be used as unique identifier
distinguished_name	String	Full LDAP distinguished name path	Can be used as unique identifier
email	String	Email address	Can be used as unique identifier
user_principal_name	String	User's principal name (login format)	Can be used as unique identifier

Delete Identity

Permanently removes a user from Active Directory:

• Entity Type: Active Directory User

• Method: Permanent deletion (DROP USER equivalent)

• Warning: This action cannot be undone

Delete Identity permanently removes the user account from Active Directory. Use Deprovision Identity instead if you need to preserve the account for audit or potential reactivation.

The following unique identifiers can be used to locate the user:

Unique Identifiers for Delete Identity

Property	Type	Description	Notes
account_name	String	User's account name (sAMAccountName)	Can be used as unique identifier
distinguished_name	String	Full LDAP distinguished name path	Can be used as unique identifier
user_principal_name	String	User's principal name (login format)	Can be used as unique identifier
email	String	Email address	Can be used as unique identifier

Example Workflows

Employee Onboarding

Automate user creation and group assignment when a new employee joins:

1. Create a Lifecycle Management policy with your HR system as the source of identity

2. Configure a workflow triggered when a new identity is detected

3. Add a Sync Identities action to create the AD user:

   • Map HR attributes to AD attributes (name, email, department, title, manager)

   • Set initial password with "require change on next login"

4. Add a Manage Relationships action to assign initial group memberships based on role/department

Role Change

Update access when an employee changes roles:

1. Create a policy with your HR system as the source of identity

2. Configure a workflow triggered when attributes change (department, title, or manager)

3. Add a Sync Identities action to update user attributes

4. Add a Manage Relationships action to:

   • Remove old role-based group memberships

   • Add new role-based group memberships

Employee Offboarding

Disable access when an employee leaves:

1. Create a policy with your HR system as the source of identity

2. Configure a workflow triggered when termination date is set or employee status changes

3. Add a Deprovision Identity action:

   • Account will be disabled (not deleted)

   • Group memberships will be removed

   • Attributes preserved for audit

4. Optionally schedule a Delete Identity action after retention period (e.g., 90 days)

Managed Service Accounts

Active Directory Lifecycle Management supports Managed Service Accounts (MSAs) for Non-Human Identity (NHI) provisioning. MSAs have a simplified action set compared to user accounts, reflecting the different lifecycle needs of service accounts.

Current NHI Support: Veza's Managed Service Account provisioning currently supports identity creation, attribute synchronization, and deletion. Group membership management and staged deprovisioning are not yet available for MSA entity types.

Supported Actions for MSAs

Action	Supported	Notes
Sync Identities	✅	Create and update MSA attributes
Delete Identity	✅	Permanently remove MSAs
Manage Relationships	❌	MSAs cannot be assigned to groups via LCM
Deprovision Identity	❌	Only deletion is supported, not disabling
Reset Password	❌	Not applicable for service accounts

MSA Attributes

Managed Service Accounts support a limited attribute set compared to user accounts:

Property	Required	Type	Description
account_name	Yes	String	Service account name (sAMAccountName)
distinguished_name	Yes	String	Full LDAP distinguished name path
description	No	String	Service account description

Example: Service Account Lifecycle

Automate service account creation and removal:

1. Create a Lifecycle Management policy with your CMDB or service catalog as the source of identity

2. Configure a workflow triggered when a new service is registered

3. Add a Sync Identities action to create the MSA:

   • Entity Type: ActiveDirectoryManagedServiceAccount

   • Map service attributes to MSA attributes (account_name, distinguished_name, description)

4. For service decommissioning, add a Delete Identity action to remove the MSA

Unlike user accounts, Managed Service Accounts do not support the Deprovision Identity action. When an MSA is no longer needed, use Delete Identity to permanently remove it. Plan your MSA lifecycle accordingly.

For more information about NHI governance beyond provisioning, see NHI Security.