Microsoft Active Directory

Configuring the Veza integration for Microsoft Active Directory.

This topic is for legacy Active Directory Domain Services. Azure AD is automatically parsed for configured Azure tenants.

Native Identity Mapping: If you also have Azure AD integrated, Veza automatically creates identity relationships between Active Directory users/groups and Azure AD users/groups. Custom identity mapping is only needed for connecting to other systems. See Custom Identity Mappings for details.

Veza discovers Active Directory entities and authorization by connecting as a read-only user with an LDAP certificate. To enable a secure connection to the AD Domain Controller, the integration is typically configured to use an Insight Point deployed within your cloud environment.

Veza for Active Directory

See Notes and Supported Entities for more detail on how Veza converts AD User properties for use in search filters or to refine Access Review queries.

Prerequisites

To configure a new Active Directory integration, you will need the following:

• Either of the following:

  • IP address of an AD Domain Controller (preferably the domain controller with the PDC emulator FSMO role)

  • FQDN of a domain controller or load balancer for environments using DNS resolution

• Username and password for Active Directory user with Read Only access to the Domain

• The FQDN of the AD DS Domain

• LDAPS Enabled on the Domain Controller and the Root or Leaf Certification securing LDAPS on the AD DC

• An Insight Point with:

  • Network connectivity to the AD Domain Controller (TCP 636), including any failover hosts if configured

  • DNS resolution capability when using domain controller FQDNs, DC discovery, or load balancers

When using domain names for connection, ensure your LDAPS certificates include the appropriate FQDNs in the Subject Alternative Name (SAN) field. This includes both individual domain controller FQDNs and load balancer FQDNs if used.

Load Balancer Configuration

If using a load balancer for your domain controllers:

• Configure session persistence (sticky sessions) on the load balancer

• Ensure all domain controllers behind the load balancer trust the same root Certificate Authority (CA) that issued the LDAPS certificates

• The LDAPS certificate must include the load balancer's FQDN in the Subject Alternative Name (SAN) field

Domain Controller Failover

Veza supports automatic failover across multiple domain controllers for improved reliability. If the primary domain controller becomes unreachable during data extraction, Veza automatically retries the connection on the same DC, then fails over to the next available DC and restarts the current batch of requests.

You can configure failover in two ways:

• Manual: Specify backup domain controllers by hostname or IP address in the Failover Hosts field.

• Automatic: Enable DC Discovery to have Veza dynamically discover all available domain controllers via DNS SRV records (_ldap._tcp.dc._msdcs.<domain>).

Both options can be used together. Veza tries the primary host first, then any manually specified failover hosts, then any DCs discovered via DNS.

When using multiple domain controllers with LDAPS, ensure that your certificates include all DC FQDNs in the Subject Alternative Name (SAN) field, or use a wildcard certificate that covers all DCs. See Get or Generate an LDAP certificate for a multi-SAN certificate request example.

Lifecycle Management: Failover hosts are used for extraction only. LCM actions are performed exclusively through the primary host.

Get or Generate an LDAP certificate

If LDAPS is enabled for Active Directory, Veza requires the public certificate in base64 format (.CER Base-64) to validate the LDAPS connection.

Single DC vs. multi-DC failover: For a single domain controller, export the DC's server certificate and provide it to Veza. For multi-DC failover, provide the CA root certificate instead.

Veza uses this to validate the certificate presented by any DC in the pool. All DCs must use certificates issued by the same Certificate Authority.

Certificate Storage and Security: The LDAP certificate (public portion only) is stored encrypted within Veza's system and can only be accessed via authenticated API calls. For on-premises deployments using Insight Points:

• The certificate is encrypted using both application-layer and storage-layer encryption

• The certificate can only be decrypted by the Insight Point within your network

• In on-premises VPV environments, API calls are typically not exposed over the public internet based on customer network configuration

• The connection from the Insight Point to Active Directory remains entirely within your on-premises network

This ensures that the certificate and all communication occurs within your secure network environment.

Using Microsoft Management Console (MMC) - Recommended Method

1. From the Domain Controller, open a new MMC console (Run -> mmc.exe)

2. Add the Snap-in Certificates and select Computer account when prompted, then select Local computer and click Finish to complete the snap-in addition process

3. Open the Personal/Certificates folder

4. Locate the correct certificate to export:

   • Look for a certificate where the Issued To column shows the FQDN of the domain controller

   • If multiple certificates exist with the DC's FQDN, choose the one with:

     • Intended Purposes (Enhanced Key Usage) that includes "Server Authentication"

     • Certificate Template column shows "Domain Controller" (if this column is visible)

     • Valid expiration date (not expired)

     • Most recent issue date if multiple valid certificates exist

   • Important: Export only the domain controller's server certificate, NOT the root CA certificate or intermediate certificates

5. Right-click the certificate and select All Tasks/Export

6. Select No, do not export the private key

7. Select Base-64 encoded X.509 (.CER) format

   • Note: When you select Base-64 format, the "Include all certificates in the certification path" option will not be available - this is expected

   • Veza only needs the server certificate itself, not the full certificate chain

8. Specify a file name and location to save the certificate

9. Complete the export wizard

Test LDAPS Connectivity

To test the LDAPS connectivity locally before submitting the certificate to Veza:

1. Open LDP.exe on the Domain Controller

2. Click the Connection menu and choose Connect...

3. Type the Domain Controller FQDN and Port Number as 636 and click OK

4. You should see "Established connection to [Domain Controller]" and the Base DN details

Alternative Methods

You can also retrieve the certificate using Python:

import ssl

host = "addc1.domain.local"

cert = ssl.get_server_certificate((host, 636))
path = f"{host.replace('.', '_')}.cert"

with open(path, "w", encoding="utf8") as file:
  file.write(cert)

To retrieve an LDAPS certificate using openssl:

openssl s_client -showcerts -connect addc.domain.local:636

To generate a Multi-SAN certificate that covers multiple domain controllers, use the following process with Active Directory Certificate Services (AD CS).

This is required when configuring Domain Controller Failover, and can also be used to set up LDAPS for the first time.

Prerequisites: AD CS must be installed in your domain with an Enterprise Root CA configured. You need administrative access to all domain controllers in the failover pool.

Create a certificate template

Before generating a certificate request, create a custom template in AD CS that supports multiple Subject Alternative Names:

1. On the CA server, open the Certificate Templates console: run certtmpl.msc

2. Find the Domain Controller template, right-click, and select Duplicate Template

3. Set the template name to DomainControllerMulti-SAN

4. Configure the template:

   • General tab: Set a validity period (1–2 years recommended)

   • Subject Name tab: Select Supply in the request

   • Security tab: Grant Domain Controllers Read and Enroll permissions

5. Publish the template on the CA:

certutil -SetCAtemplates +DomainControllerMulti-SAN

Generate and install the certificate

1. Prepare the request.inf configuration file (see example below)

2. Generate a certificate request from the .inf file: certreq -new request.inf request.req

3. Submit the request to the CA: certreq -submit -config "<ca-server-fqdn>\<ca-name>" request.req certnew.cer If the CA requires manual approval, you will receive a RequestID instead of a certificate. Retrieve the issued certificate with: certreq -retrieve RequestID certnew.cer

4. Accept and install the issued certificate: certreq -accept certnew.cer

The certificate must use the SAN, as shown in the [Extensions] block in the example configuration. If you are configuring Domain Controller Failover, add a _continue_ entry for each DC hostname so that a single certificate is valid for all domain controllers:

request.inf

[Version]

Signature="$Windows NT$"

[NewRequest]
Subject = "CN=corp-ad-01.corp.veza.com"

KeySpec = 1
KeyLength = 2048
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

; If using the DomainControllerMulti-SAN AD CS template from Step 1,
; replace the [EnhancedKeyUsageExtension] block above with:
; [RequestAttributes]
; CertificateTemplate="DomainControllerMulti-SAN"

[Extensions]

2.5.29.17 = "{text}"
_continue_ = "dns=corp-ad-01.corp.veza.com&"
_continue_ = "dns=corp-ad-02.corp.veza.com&"
_continue_ = "dns=corp-ad-03.corp.veza.com"

Each _continue_ entry except the last must end with &. The Subject field only needs to match one DC; the SAN entries are what validate TLS connections for each host.

For more information see the Microsoft documentation to add a subject alternative name to a secure LDAP certificate.

Deploy certificate to failover domain controllers

After generating and installing the Multi-SAN certificate on the primary DC, deploy the same certificate to each failover DC. All DCs in a failover pool must present the same certificate.

On the primary DC, export the certificate:

1. Open MMC (mmc), add the Certificates snap-in for Computer account > Local computer

2. Navigate to Certificates (Local Computer) > Personal > Certificates

3. Find the Multi-SAN certificate, right-click > All Tasks > Export

4. Select Yes, export the private key

5. Choose Personal Information Exchange (.PFX) format and set a strong password

6. Save the file (for example, multi-san-cert.pfx)

On each failover DC, import and activate the certificate:

1. Copy multi-san-cert.pfx to the failover DC

2. Import the certificate:

   certutil -importpfx C:\multi-san-cert.pfx

3. Remove old DC-specific certificates so the new Multi-SAN certificate is used:

   # List installed certificates to identify the old serial number
   certutil -store my
   # Remove the old certificate
   certutil -delstore my "<old-serial-number>"

4. Restart AD DS services to pick up the new certificate:

   Restart-Service NTDS -Force

5. Verify the certificate is active:

   Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*<your-domain>*"} | Select-Object Subject, Thumbprint, NotAfter

Export the CA root certificate for Veza:

When using domain controller failover, provide the CA root certificate to Veza rather than the individual DC server certificate. Veza uses it to validate the certificate presented by any DC in the pool.

# Find the CA certificate thumbprint
certutil -store Root | findstr -i "<ca-name>"

# Export the CA root certificate
$cert = Get-ChildItem Cert:\LocalMachine\Root | Where-Object {$_.Thumbprint -eq "<ca-thumbprint>"} | Select-Object -First 1
Export-Certificate -Cert $cert -FilePath C:\ca-root.cer -Type CERT

# Convert to Base64 for Veza
certutil -encode C:\ca-root.cer C:\ca-root-base64.cer

Upload the contents of ca-root-base64.cer as the LDAP Certificate in the Veza integration configuration.

Kerberos Authentication

Veza supports authenticating to the Active Directory LDAP server via simple LDAP bind or with Kerberos authentication.

If Kerberos authentication is selected, Veza will generate a simple Kerberos configuration file (krb5.conf) with the following format:

krb5.conf

[libdefaults]
   default_realm = <domain>
   dns_lookup_kdc = true
   dns_lookup_realm = true

[realms]
   <domain> = {
      kdc = <AD domain fully qualified domain name for cert>
      admin_server = <AD domain fully qualified domain name for cert>
   }

The integration will request a Ticket Granting Ticket (TGT) and Service Ticket from the hostname provided in the integration configuration before authenticating to the LDAP server with Kerberos password authentication.

Creating an Active Directory integration in Veza

In Veza, browse to the Integrations page. Click Add Integration and search for Active Directory. Click on the tile to add an integration.

Field	Description
Insight Point	Use the default selection unless using an Insight Point for the connection
Name	Name to use for the AD connection in Veza
Host	Either: (1) IP address/FQDN of a single domain controller, or (2) FQDN of a load balancer that distributes traffic across multiple domain controllers
Port	Port serving LDAPS (Default 636)
Username	Active Directory user to bind to the LDAP Connection (Recommended to use the UserPrincipalName)
Password	Password for the Active Directory user
Domains	The FQDN of the AD Domain (Only 1 can be listed)
AD domain fully qualified domain name for cert	Subject Name on the LDAPS Leaf Certificate, should be the AD DC or load balancer FQDN
LDAP Certificate	SSL/TLS certificate used to establish the LDAP connection
Enable Kerberos Authentication	Check this box to use Kerberos authentication when connecting to the Domain Controller
Extract Disabled Users	Uncheck this box to exclude disabled users from metadata extraction
Kerberos SPN	Enable Kerberos authentication and provide a value to set a ServicePrincipalName for the Kerberos connection (Default ldap/<dc_hostname>)
Failover Hosts	Optional list of backup domain controller hostnames or IP addresses for automatic failover if the primary host becomes unavailable
Enable DC Discovery	Enable automatic discovery of domain controllers via DNS SRV records
DC Discovery Domain	Override the domain used for DNS-based DC discovery (defaults to the first domain in the Domains field)

Security Note: For enhanced security, you can store Active Directory credentials in an external secrets vault instead of directly in Veza. This keeps sensitive credentials in your private network. See Secrets Vaults for configuration details.

• To connect to multiple AD domains, you will need add a new integration for each domain to discover

• LDAP Certificate and Password are secret, and will need to be re-entered if changing the Insight Point used for the AD integration

• You can see all extracted AD entities under Data Catalog > Entities. Veza-built queries for Active Directory can be found in Dashboards and on the Saved Queries page

Notes and Supported Entities

• Active Directory Domain

• Active Directory Computer

• Active Directory Group

• Active Directory User

• Active Directory Organizational Unit

• Active Directory Managed Service Account

Veza discovers built-in attributes for Active Directory Users, which can be used to specify the scope of Access Reviews and filter search results. In some cases, Veza derives values from other properties, or changes AD property names for consistency with other integrations.

• To discover custom properties created in Active Directory, specify them by name and type in the Custom Properties section when configuring the integration

• To discover additional built-in properties, please contact our support team with more detail about your case

Veza Attribute	AD Attribute	Notes
Account Name	sAMAccountName
Account Type	objectClass	User Object
Active Directory Domain	userPrincipalName	Domain part only
City	l
Common Name	cn
Company	company
Country Code	c
Country Or Region	countryCode
Created At	whenCreated
Department	department
Description	description
Display Name	displayName
Distinguished Name	distinguishedName
Domain Admin	memberOf	Checks for Domain Admins group membership
Email	mail
First Name	givenName
Given Name	givenName
Idp Unique Id	userPrincipalName
Is Active	userAccountControl	Boolean calculated by Veza; see User Active Status
Is Locked	userAccountControl	Locked flag
Job Title	title
Last Name	sn
Last Logon	lastLogon, lastLogonTimestamp	Uses more recent value; see Last Logon Attribute Behavior
Lower Email	mail	Lowercase transformation
Manager	manager
Manager Principal Name	manager	Derived from manager distinguished name
Office	physicalDeliveryOfficeName
Password Last Set	pwdLastSet
Physical Delivery Office Name	physicalDeliveryOfficeName
Postal Code	postalCode
Primary Group Id	primaryGroupID
Sid	objectSid
State Or Province Name	st
Street Address	streetAddress
Sur Name	sn
Title	title
User Principal Name	userPrincipalName
User Password Expiration	pwdLastSet	Calculated using pwdLastSet and domain password policy
Full Admin	memberOf	True when user is member of Administrators or Domain Admins group
User Account Control	userAccountControl	String list of account control flags (PASSWORD_EXPIRED, LOCKOUT, etc.)

Active Directory User Active Status

The Is Active property for an Active Directory user is determined by their userAccountControl attribute. A user is considered Is Active: true unless their account has the ACCOUNTDISABLE flag set.

Other userAccountControl flags, such as LOCKOUT or PASSWORD_EXPIRED, do not affect the Is Active status. The full list of flags is available in the User Account Control attribute for more granular filtering. See Microsoft Learn: Use the UserAccountControl flags to manipulate user account properties for possible values.

Last Logon Attribute Behavior

In Veza, the Last Logon value represents the most recent activity visible from the connected Domain Controller. For users who authenticate to multiple Domain Controllers, the actual logon may have occurred on a different DC. It will not be reflected in the lastLogon value from the queried DC

The lastLogonTimestamp provides a more consistent view across the full organization, but can be up to 14 days (or the configured sync interval) behind actual logon activity

The Last Logon attribute in Veza represents the most recent logon time for an Active Directory user. Due to Active Directory's distributed architecture, this value requires special handling:

• lastLogon: This attribute updates every time a user authenticates, but only on the specific Domain Controller where authentication occurred. This attribute is not replicated between Domain Controllers.

• lastLogonTimestamp: This attribute replicates across all Domain Controllers in the domain, but only updates when current_time - msDS-LogonTimeSyncInterval has passed (typically 14 days by default).

During extraction, the integration will:

1. Retrieve both lastLogon and lastLogonTimestamp attributes

2. Compare the two timestamps

3. Uses whichever value is more recent

For more information, see Microsoft's documentation on lastLogon and lastLogonTimestamp attributes.