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)

  • DNS resolution capability when using domain controller FQDNs instead of IP addresses

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

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.

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

If LDAPS was not already enabled, follow the steps below to generate a new certificate that includes a Subject Alternative Name (SAN). To get a new certificate with certreq.exe:

Please only follow these instructions if you do not already have LDAPS enabled on your AD DC.

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

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

3. Submit the request to a CA (output is RequestID).

   certreq -submit request.req certnew.cer You might need to specify a Certificate Template as part of the submit command, for example: certreq -submit -attrib "certificatetemplate:webserver" request.req

4. Use the Request ID number to retrieve the certificate: certreq -retrieve RequestID certnew.cer

5. Accept the issued certificate: certreq -accept certnew.cer

The certificate must use the SAN, as shown in the [Extensions] block in the example configuration:

request.inf

[Version]

Signature="$Windows NT$"

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

KeySpec = 1
KeyLength = 1024
; 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

[Extensions]

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

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

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>)

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 Reports 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).

Since Veza connects to a single Domain Controller for each Active Directory integration, 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.