> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/integrations/active-directory.md). # Microsoft Active Directory Configuring the Veza integration for Microsoft Active Directory. {% hint style="info" %} This topic is for legacy Active Directory Domain Services. Azure AD is automatically parsed for [configured Azure tenants](/4yItIzMvkpAvMVFAamTf/integrations/integrations/azure.md). {% endhint %} {% hint style="info" %} **Automatic identity matching**: Veza correlates local accounts in other systems to Active Directory users by comparing their identity values against the **IdP Unique ID** (the userPrincipalName), **Account Name** (the sAMAccountName), **Distinguished Name**, and **Email** attributes. Employee ID, Employee Number, objectGUID, and SID are not compared. If you also have Entra ID integrated, Veza correlates Active Directory users and groups to Entra ID users and groups, but only for Entra ID entities whose `onPremisesSyncEnabled` flag is set. See [Automatic Identity Matching](/4yItIzMvkpAvMVFAamTf/integrations/configuration/automatic-identity-matching.md#active-directory) for the full behavior, and [Custom Identity Mappings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md) to correlate on any other attribute. If you run more than one identity provider, see [Cross-IdP risk coverage](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md#cross-idp-risk-coverage) for assessing risk across all of your providers. {% endhint %} Veza discovers Active Directory entities and authorization by connecting as a read-only user over LDAP or LDAPS. To enable a secure connection to the AD Domain Controller, the integration is typically configured to use an [Insight Point](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md) deployed within your cloud environment. ![Veza for Active Directory](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-68109c198ebbd193088c769ec3d3d38da984e1ab%2Factive-directory.png?alt=media) See [Notes and Supported Entities](#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. ## Performance and resource impact Veza performs a complete LDAP extraction each cycle (there is no incremental or delta sync). Active Directory enforces server-side pagination limits, so every extraction issues paged LDAP search requests to retrieve all objects. This is the same paging behavior that requires [session persistence on load balancers](#load-balancer-configuration). Active Directory uses a 1-hour extraction interval by default (the **Auto** setting). To adjust the interval, see [Extraction Settings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/extraction.md). Resource impact on domain controllers depends on the size of your environment. Most customers see no measurable change in DC CPU, memory, or network utilization during extraction. To assess the impact in your environment: 1. Configure the integration and trigger a first extraction. 2. Monitor CPU, memory, and network utilization on the domain controller during the extraction window. 3. If the load is a concern, increase the extraction interval or reduce the scope in [Extraction Settings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/extraction.md). ## Prerequisites To configure a new Active Directory integration, you will need the following: {% tabs %} {% tab title="LDAPS (recommended)" %} * Either of the following: * IP address of an AD Domain Controller (preferably the domain controller with the [PDC emulator FSMO role](https://docs.microsoft.com/troubleshoot/windows-server/identity/find-servers-holding-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. Collecting [fine-grained password policies](#permissions-for-fine-grained-password-policies) additionally requires delegated Read on the Password Settings Container; without it, those policies are silently omitted rather than reported as an error. * The FQDN of the AD DS Domain * LDAPS enabled on the Domain Controller, and the certificate of the Certificate Authority (CA) that issued the DC's LDAPS certificate (see [Get or generate an LDAP certificate](#get-or-generate-an-ldap-certificate)) * 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 {% hint style="info" %} 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. {% endhint %} {% endtab %} {% tab title="Plain LDAP" %} {% hint style="info" %} Plain LDAP (port 389) is only supported with [Kerberos Token Authentication](#kerberos-token-authentication). Username/password and Kerberos TLS authentication both require LDAPS (port 636). {% endhint %} * Either of the following: * IP address of an AD Domain Controller (preferably the domain controller with the [PDC emulator FSMO role](https://docs.microsoft.com/troubleshoot/windows-server/identity/find-servers-holding-fsmo-role)) * FQDN of a domain controller or load balancer for environments using DNS resolution * The FQDN of the AD DS Domain * A Kerberos credential cache pre-configured on the Insight Point pod (see [Kerberos Token Authentication](#kerberos-token-authentication)) * An Insight Point with: * Network connectivity to the AD Domain Controller (TCP 389), including any failover hosts if configured * DNS resolution capability when using domain controller FQDNs, DC discovery, or load balancers No certificate is required for plain LDAP connections. {% endtab %} {% endtabs %} ## Load balancer configuration If using a load balancer for your domain controllers, configure session persistence (sticky sessions) on the load balancer. Veza uses paged LDAP searches, and paging cookies are DC-specific — if the load balancer routes pages of the same search to different backend DCs, the request will fail. This applies to both plain LDAP and LDAPS connections. For LDAPS connections, also ensure: * All domain controllers behind the load balancer trust the same root Certificate Authority (CA) that issued the LDAPS certificates * The LDAPS certificate on every domain controller behind the load balancer includes the load balancer's FQDN in the Subject Alternative Name (SAN) field. Veza verifies each backend DC's certificate against the load balancer FQDN entered in **Host**. * The load balancer passes TLS through to the domain controllers rather than terminating it ## Domain controller failover Veza supports automatic failover across multiple domain controllers for improved reliability, for both data extraction and Lifecycle Management actions. When it connects, Veza uses the first domain controller in the order below that it can reach. If that DC becomes unreachable during data extraction, Veza 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**: Select **Enable Domain Controller Discovery** to have Veza dynamically discover all available domain controllers via DNS SRV records (`_ldap._tcp.dc._msdcs.`). Both options can be used together. Veza tries domain controllers in this order: 1. The **Host** value. 2. The **Failover Hosts** entries, in the order you enter them. For example, with `dc-b, dc-a, dc-e`, Veza tries `dc-b`, then `dc-a`, then `dc-e`. A host listed more than once is tried only once. 3. When **Enable Domain Controller Discovery** is selected, the discovered DCs, in DNS SRV priority order. After failing over, Veza keeps using the new DC for the rest of the extraction, and moves to the next host in the list if that DC also fails. The next extraction starts again with the **Host** value. {% hint style="info" %} When using multiple domain controllers with LDAPS, Veza verifies each DC's certificate against the hostname it connects to: the **Host** value, the **Failover Hosts** entry, or the name returned by DC Discovery. Each DC can present its own certificate if the certificate's Subject Alternative Name (SAN) includes that hostname and it chains to the CA certificate uploaded to Veza. This also applies to **Host**: if you enter a DNS alias, CNAME, or load balancer name, that name must be in the SAN of the certificate each DC presents. A host entered as an IP address is verified against **Domain Controller Hostname** instead, so that name must be on the certificate of every DC you enter by IP. A multi-SAN or wildcard certificate that covers all DCs also works. See [Get or generate an LDAP certificate](#get-or-generate-an-ldap-certificate) for a multi-SAN certificate request example. {% endhint %} {% hint style="info" %} **Lifecycle Management**: **Available in Veza v2026.9.7 and later.** LCM actions use the same domain controllers, in the same order. Each job connects to the **Host** value first and fails over to the next host if it can't connect. Unlike extraction, a job doesn't move to another DC if its DC becomes unreachable partway through. The next job starts again with the **Host** value. If no host can be reached because of a network error, the job tries the whole list again: up to 10 attempts, with waits that increase from 2 seconds to 60 seconds. A rejected credential doesn't cause a retry by itself, which limits repeated attempts against the account lockout policy. However, if another host in the list then fails with a network error, the job retries the whole list, including the host that rejected the credential. A failed TLS handshake counts as a network error, so a job that connects to a DC with an untrusted certificate retries for the full schedule before it fails. {% endhint %} ## Get or generate an LDAP certificate {% hint style="info" %} This section applies to LDAPS connections (port 636) only. If connecting over plain LDAP (port 389), no certificate is required and you can skip this section. {% endhint %} If LDAPS **is enabled** for Active Directory, Veza requires the certificate of the CA that issued your domain controller certificates, in **base64 format** (.CER Base-64), to validate the LDAPS connection. Upload the CA root certificate, or the full chain (root and intermediate CA certificates) combined in one PEM file. Do not upload the DC's own server (leaf) certificate. Veza uses the uploaded CA to validate the certificate presented by any DC, whether you connect to one DC or use [multi-DC failover](#domain-controller-failover). Every DC's certificate must chain to a CA certificate in the uploaded file. {% hint style="info" %} **Available in Veza v2026.9.21 and later.** Veza verifies each DC's certificate against the hostname it connects to, and uses **Domain Controller Hostname** only when the host is an IP address. Earlier releases verified every DC against **Domain Controller Hostname**. If saving the integration reports that the LDAP Certificate does not trust the domain controller, replace the uploaded server certificate with the issuing CA certificate or chain. If it reports a hostname mismatch and **Host** is a DNS alias that is not on the DC certificates, add the alias to each certificate's SAN. The check runs on the Insight Point that connects to Active Directory, so it applies once that Insight Point runs v2026.9.21 or later. {% endhint %} {% hint style="info" %} 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. {% endhint %} ### 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**: Do not upload this server certificate to Veza. Use it to locate the CA that issued it, then export that CA's certificate. 5. Double-click the certificate and open the **Certification Path** tab 6. Select the root CA at the top of the path and click **View Certificate** 7. In the CA certificate window, open the **Details** tab and click **Copy to File** 8. Select **Base-64 encoded X.509 (.CER)** format 9. Specify a file name and location, then complete the export wizard If the certification path includes intermediate CAs, export each one the same way and combine the Base-64 files into a single file, one certificate after another. To export the CA root certificate with PowerShell instead, see **Export the CA root certificate for Veza** in the **Deploy certificate to failover domain controllers** block. ### 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 To see the certificates a DC presents over LDAPS, use `openssl`: ```shell openssl s_client -showcerts -connect addc.domain.local:636 ``` The first certificate in the output is the DC's server certificate. Do not upload it. Any certificates after it are intermediate CA certificates, which you can copy into the file you upload. If the DC sends only its own certificate, export the CA certificate with MMC or PowerShell instead. To generate a Multi-SAN certificate that covers multiple domain controllers, use the following process with Active Directory Certificate Services (AD CS). A shared certificate is optional for [Domain Controller Failover](#domain-controller-failover), because each DC can present its own certificate. Use one if you want a single certificate for all DCs, or if you enter failover DCs by IP address. You can also use this process to set up LDAPS for the first time. {% hint style="info" %} **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. {% endhint %} ### 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: ```shell 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 "\" 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. To use one certificate for all domain controllers in a [failover](#domain-controller-failover) pool, add a `_continue_` entry for each DC hostname: {% code title="request.inf" %} ```ini [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" ``` {% endcode %} {% hint style="info" %} 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. {% endhint %} For more information see the Microsoft documentation to [add a subject alternative name to a secure LDAP certificate](https://docs.microsoft.com/troubleshoot/windows-server/windows-security/add-san-to-secure-ldap-certificate).
Deploy certificate to failover domain controllers If you use a shared Multi-SAN certificate, deploy it to each failover DC after generating and installing it on the primary DC. **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: ```powershell certutil -importpfx C:\multi-san-cert.pfx ``` 3. Remove old DC-specific certificates so the new Multi-SAN certificate is used: ```powershell # List installed certificates to identify the old serial number certutil -store my # Remove the old certificate certutil -delstore my "" ``` 4. Restart AD DS services to pick up the new certificate: ```powershell Restart-Service NTDS -Force ``` 5. Verify the certificate is active: ```powershell Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like "**"} | Select-Object Subject, Thumbprint, NotAfter ``` **Export the CA root certificate for Veza:** Provide the CA root certificate to Veza, not an individual DC server certificate. Veza uses it to validate the certificate presented by any DC in the pool. ```powershell # Find the CA certificate thumbprint certutil -store Root | findstr -i "" # Export the CA root certificate $cert = Get-ChildItem Cert:\LocalMachine\Root | Where-Object {$_.Thumbprint -eq ""} | 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 two Kerberos authentication methods for Active Directory: * **Kerberos with TLS**: Uses a username and password to obtain a Kerberos TGT and authenticates over LDAPS (port 636). Credentials are entered in the Veza UI. * **Kerberos Token Authentication**: Uses a pre-generated Kerberos credential cache mounted on the Insight Point pod. No credentials are entered in Veza — authentication uses tokens provided by your environment. ### Kerberos with TLS If Kerberos authentication is selected, Veza will generate a simple Kerberos configuration file (`krb5.conf`) with the following format: {% code title="krb5.conf" %} ```ini [libdefaults] default_realm = dns_lookup_kdc = true dns_lookup_realm = true [realms] = { kdc = admin_server = } ``` {% endcode %} The integration requests 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. ### Kerberos Token Authentication You can use Kerberos Token Authentication in environments where credential injection from the Veza UI is not permitted. This enables mounting integration secrets as files on an Insight Point pod at deployment time, keeping all secrets within your network. Instead of entering a username and password in Veza, you will preconfigure the Insight Point pod with a Kerberos credential cache. Veza reads the cache at extraction time to authenticate without storing any credentials. #### Insight Point prerequisites The following environment variables and files must be present on the Insight Point pod before configuring the integration: | Environment variable | Default path | Purpose | | -------------------- | -------------------- | --------------------------------------------------------------------------------------------- | | `KRB5_CONFIG` | `/tmp/krb5.conf` | Kerberos configuration file (realm, KDC settings) | | `KRB5CCNAME` | `/tmp/krb5cc_go` | Path to the credential cache file containing TGT and service tickets | | `LDAP_CERTIFICATE` | `/tmp/ldap_cert.pem` | LDAP certificate. Required for LDAPS connections (port 636, the default and recommended port) | To populate the credential cache, use any standard Kerberos tools available in your environment. Using `kinit` (installed on the Insight Point image): 1. Run `kinit @` to generate a TGT and write it to the path specified by `KRB5CCNAME`. 2. Run `klist` to confirm the ticket is valid and check its expiration time. {% hint style="info" %} Plan to renew the credential cache before ticket expiration to prevent extraction failures. Tickets are requested with a 5-day lifetime, subject to the maximum configured on your domain controller. {% endhint %} #### Configure the integration 1. In the Veza integration form for Active Directory, check **Enable Kerberos Authentication**. This reveals the **Use Kerberos Token Cache** option. 2. Check **Use Kerberos Token Cache**. The **Username**, **Password**, and **LDAP Certificate** fields will be hidden — they are not used in token-based authentication. 3. Complete the remaining required fields (**Host**, **Domain**, **Port**, etc.) and save. When Kerberos Token Cache is enabled, Veza reads credentials exclusively from the Insight Point pod environment. Any username or password previously entered in the UI is not stored or used. #### Port behavior Use port 636 (LDAPS) unless your environment does not support TLS. Port 389 (plain LDAP) is available but not recommended. | Port | Connection type | Certificate source | | ----------------- | --------------- | ------------------------------------------------- | | 636 (recommended) | TLS (LDAPS) | Read from `LDAP_CERTIFICATE` on Insight Point pod | | 389 | Plain LDAP | Not required | #### Lifecycle Management Lifecycle Management (provisioning and deprovisioning) is supported with Kerberos Token Authentication. To enable it, open the **Integration details** page for the Active Directory integration, click **Edit**, check **Enable usage for Provisioning**, and click **Save Configuration**. Veza uses the same Kerberos token cache mounted on the Insight Point pod for both extraction and provisioning. No additional credentials need to be configured in the Veza UI. ## Configuring Active Directory on the Veza platform 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](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md) 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 for the LDAP connection. Default 636 (LDAPS); use 389 for plain LDAP. | | **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) | | **Domain Controller Hostname** | A DNS name on the domain controller's LDAPS certificate. Veza verifies the certificate against this name only when **Host** or a failover host is an IP address; a host entered by name is verified against that name. Also sets the default **Kerberos SPN**. | | **LDAP Certificate** | The CA certificate, or full chain PEM, that issued the domain controller certificates. Not the DC server (leaf) certificate. Required for port 636 (LDAPS); not required for port 389 (plain LDAP). | | **Enable Kerberos Authentication** | Check to use Kerberos authentication when connecting to the Domain Controller. Enables the **Use Kerberos Token Cache** option. | | **Use Kerberos Token Cache** | When checked, Veza authenticates using a credential cache pre-mounted on the Insight Point pod. Username, Password, and LDAP Certificate are not required. See [Kerberos Token Authentication](#kerberos-token-authentication). | | **Extract Disabled Users** | Clear to exclude disabled users from metadata extraction | | **Kerberos SPN** | Provide a value to override the ServicePrincipalName for the Kerberos connection (Default `ldap/`) | | **Failover Hosts** | Optional list of backup domain controller hostnames or IP addresses for automatic failover if the primary host becomes unavailable. Each host must present a certificate whose SAN matches that hostname. A host entered as an IP address is verified against **Domain Controller Hostname**. | | **Enable Domain Controller 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](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/secrets-vaults.md) for configuration details. * To connect to multiple AD domains, you will need add a new integration for each domain to discover * `Password` (and `LDAP Certificate` if using LDAPS) are secret fields that must be re-entered if the Insight Point changes * You can see all extracted AD entities under **Data Catalog** > *Entities*. Veza-built queries for Active Directory can be found in [Dashboards](/4yItIzMvkpAvMVFAamTf/features/insights/dashboards.md) and on the *Saved Queries* page ## Effective permissions (Early Access) {% hint style="info" %} **Early Access:** ACL extraction for Active Directory Groups and Organizational Units is an Early Access feature, enabled by the Veza support team on request. If it is not enabled for your tenant, the **Extract ACLs** option is unavailable — contact your Veza support representative to request it. Tenants that already have ACL extraction enabled are unaffected; it continues to work with no action needed. {% endhint %} The Active Directory integration supports extraction of **Access Control Lists (ACLs)** for Group and Organizational Unit objects, enabling Veza to model effective permissions for AD users on these objects. Once ACL extraction is enabled for your tenant, it remains off per integration by default — select **Extract ACLs** in the integration configuration to turn it on. When enabled, Veza discovers the following effective permission relationships: * **Active Directory User** → Effective Permission → **Active Directory Group** * **Active Directory User** → Effective Permission → **Active Directory Organizational Unit** * **Active Directory User** → Effective Permission → **Active Directory Group Policy Object** * **Active Directory Group** → Effective Permission → **Active Directory Group Policy Object** Group Policy Object effective permissions represent whether a policy *applies to* an identity, and follow Active Directory's own policy-application rules. See [Group Policy Objects](#group-policy-objects). {% hint style="info" %} **Scope:** For Groups and Organizational Units, these effective permissions reflect access a user has to the Group or Organizational Unit object itself, not to resources or objects contained within the group or OU. Veza evaluates the ACL of each Group and OU against all users, accounting for transitive group membership. A user nested in a group chain (e.g., User → IT\_Admins → IT → Employees) inherits the effective permissions of each group in the chain. Deny ACEs always override Allow ACEs, consistent with Windows ACL precedence. {% endhint %} ### How it works Active Directory uses an Access Control List (ACL) based model for permissions. When Veza extracts ACLs: * Each Group and OU has an ACL that defines which Users (directly or through group membership) have specific permissions * Permissions can be either **Allow** or **Deny**, with Deny always taking precedence over Allow * Veza calculates effective access by considering transitive group membership. If a User is a member of Group A, which is a member of Group B, the User inherits permissions granted to both groups * Common permission types include: * `READ_CONTROL`. Read security information about the object * `LIST_OBJECT`. List the object in directory searches * `READ_PROPERTY`. Read object properties * `LIST_CHILD_OBJECTS`. List child objects within a container This effective permissions data enables you to: * Query which Users can manage specific Groups or OUs using [permission filters](/4yItIzMvkpAvMVFAamTf/features/search/query-builder.md#filtering-and-sorting-results) (e.g., `READ_CONTROL`, `WRITE_PROPERTY`) * Identify Users with elevated administrative permissions by combining attribute filters on user properties with permission filters * Investigate access granted through nested group memberships. Veza automatically calculates effective permissions considering transitive group membership * Create [Access Reviews](/4yItIzMvkpAvMVFAamTf/features/access-reviews.md) and [Rules](/4yItIzMvkpAvMVFAamTf/features/insights/rules-and-alerts.md) to certify and alert on changes to administrative access ## Password policies Veza extracts Active Directory password and account lockout policy so you can review and query it alongside the users and groups it governs. Two kinds of policy are collected: * The **domain default policy** (the password and lockout settings of the Default Domain Policy), stored on the **Active Directory Domain** entity. * Each **fine-grained password policy**, stored as an **Active Directory Password Settings Object** entity. Fine-grained password policies apply different password and lockout settings to specific users and groups instead of the single domain-wide default. Active Directory holds them in Password Settings Objects (PSOs). The domain default and the Password Settings Objects are read independently, and each read is best-effort. If Veza cannot read one, it logs a warning and continues with the rest of the extraction. ### Policy properties The **Active Directory Domain** entity and every **Active Directory Password Settings Object** expose the same set of password and lockout properties. Durations are reported in seconds; a `-1` value carries a property-specific meaning, noted in the table below. | Property | AD attribute | Description | | ------------------------------------ | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | `min_password_length` | `msDS-MinimumPasswordLength` | Minimum number of characters in a password. | | `max_password_age_seconds` | `msDS-MaximumPasswordAge` | Maximum password age in seconds (`-1` means passwords never expire). | | `min_password_age_seconds` | `msDS-MinimumPasswordAge` | Minimum password age in seconds before a password can be changed again. | | `password_history_length` | `msDS-PasswordHistoryLength` | Number of earlier passwords Active Directory keeps in its password history. | | `password_properties` | `msDS-PasswordComplexityEnabled`, `msDS-PasswordReversibleEncryptionEnabled` | Enabled policy flags. See the flag list below. | | `lockout_threshold` | `msDS-LockoutThreshold` | Failed sign-in attempts allowed before the account is locked out. `0` disables account lockout. | | `lockout_duration_seconds` | `msDS-LockoutDuration` | How long a locked-out account stays locked, in seconds (`-1` means the account stays locked until an administrator unlocks it). | | `lockout_observation_window_seconds` | `msDS-LockoutObservationWindow` | Window in seconds during which failed sign-in attempts are counted toward the lockout threshold. | The **Active Directory Domain** entity exposes the same eight properties, read from the classic domain-policy attributes (`minPwdLength`, `maxPwdAge`, `minPwdAge`, `pwdHistoryLength`, `pwdProperties`, `lockoutThreshold`, `lockoutDuration`, and `lockOutObservationWindow`). Each **Active Directory Password Settings Object** also has: | Property | AD attribute | Description | | -------------- | --------------------------------- | ----------------------------------------------------------------------------------------- | | `display_name` | `displayName` | The policy's display name. | | `precedence` | `msDS-PasswordSettingsPrecedence` | Precedence value. A lower number wins when more than one policy applies to the same user. | The `password_properties` list reports the enabled flags below. The domain default policy can report any of them; a Password Settings Object reports only `COMPLEXITY_ENABLED` and `REVERSIBLE_ENCRYPTION_ENABLED`. * `COMPLEXITY_ENABLED`. Passwords must meet complexity requirements. * `REVERSIBLE_ENCRYPTION_ENABLED`. Passwords are stored using reversible encryption. * `NO_ANONYMOUS_CHANGE`. A password cannot be changed without first signing in. * `NO_CLEAR_CHANGE`. Passwords cannot be changed by sending them in plain text. * `LOCKOUT_ADMINS`. The built-in administrator account can be locked out. * `REFUSE_PASSWORD_CHANGE`. The domain refuses automatic machine account password changes (it does not restrict user password changes). For the underlying flag definitions, see Microsoft's [`DOMAIN_PASSWORD_INFORMATION`](https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/ns-ntsecapi-domain_password_information) reference. ### How policies apply to users and groups Veza models both the configured assignment and the resulting policy: * **Domain to policy**: the **Active Directory Domain** links to every **Active Directory Password Settings Object** defined in it. Traverse this relationship to list all of a domain's fine-grained password policies. * **Configured assignment**: an **Active Directory Password Settings Object** applies to the **Active Directory User** and **Active Directory Group** entities it is directly assigned to (the `msDS-PSOAppliesTo` attribute). * **Effective policy**: an **Active Directory User** links to the single **Active Directory Password Settings Object** that actually governs that user. Veza computes the effective policy the same way Active Directory does. A policy assigned to the user directly wins over one assigned through a group (including nested group membership), then the lowest `precedence` wins, and a tie in precedence is broken by the smallest object GUID. If no Password Settings Object applies to a user, the domain default policy governs and no effective-policy link is created. Veza also records the effective policy for each group (the lowest-precedence policy assigned directly to it). Fine-grained password policies apply only to users and global security groups. They do not apply to computers or organizational units. ### Permissions for fine-grained password policies The domain default policy is read with the standard read-only account described in [Prerequisites](#prerequisites). Password Settings Objects require additional permissions. Active Directory treats a policy's settings as confidential, and by default only members of the **Domain Admins** group can read them. To collect fine-grained password policies without granting the Veza service account broad privileges, delegate **Read** permission on the Password Settings Container (`CN=Password Settings Container,CN=System,`) and its Password Settings Objects to the account Veza binds with. If the account cannot read the container at all, Veza logs a warning and skips fine-grained password policy data for that extraction; the domain default policy and all other Active Directory data are still collected. More often, insufficient permissions surface as a partial result: Active Directory silently omits the individual Password Settings Objects the account cannot read, so Veza collects fewer policies than exist without raising an error. If Veza shows fewer fine-grained password policies than you expect, confirm the account's Read permission on the Password Settings Container and on every Password Settings Object. Fine-grained password policies also require a domain functional level of Windows Server 2008 or higher. On earlier domains the container does not exist and no Password Settings Objects are collected. ### Find policies that weaken the domain default The domain default policy sets your organization's baseline, and a fine-grained password policy can override it for the users and groups it governs. Because the **Active Directory Domain** links to every **Active Directory Password Settings Object** it contains, you can list and filter them together in [Query Builder](/4yItIzMvkpAvMVFAamTf/features/search/query-builder.md) to find any that fall below the baseline: 1. Start from **Active Directory Domain** and add the related **Active Directory Password Settings Object**. 2. On the **Active Directory Password Settings Object**, add an attribute filter for the setting you want to enforce, for example `min_password_length` less than your baseline value. Each result is a fine-grained password policy that relaxes that setting for the users and groups it governs. Filter on other properties, such as a longer `max_password_age_seconds` or a higher `lockout_threshold`, to check the settings that matter most to your policy. ## Group Policy Objects Veza discovers each Active Directory Group Policy Object (GPO) as an **Active Directory Group Policy Object** entity, so you can review a domain's policies in the Access Graph alongside the containers they are linked to and the identities they reach. Group Policy Objects are collected whenever Active Directory is integrated; no additional configuration is required. ### Group Policy Object properties Each **Active Directory Group Policy Object** exposes the following properties: | Property | AD attribute | Description | | -------------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `display_name` | `displayName` | The Group Policy Object's display name. | | `gpo_status` | `flags` | Which parts of the policy are enabled, decoded from the GPO's flags: `Enabled` (both configurations), `UserConfigDisabled`, `ComputerConfigDisabled`, or `AllDisabled`. A flags value Veza does not recognize reads as `Unknown`. | | `version_number` | `versionNumber` | The revision counter Active Directory increments each time the policy changes. | | `gpc_file_sys_path` | `gPCFileSysPath` | UNC path to the policy's file-system component in SYSVOL. | | `setting_categories` | `gPCMachineExtensionNames`, `gPCUserExtensionNames` | The categories of settings the policy carries, derived from its registered client-side extensions. | Each Group Policy Object also carries its distinguished name, the domain it belongs to, and its creation time. Veza derives `setting_categories` from the policy's client-side extension (CSE) registrations, so it reports which kinds of settings a Group Policy Object defines without reading SYSVOL. The categories are: * `Security Settings` * `EFS Recovery` * `Registry-based Policy Settings` * `Software Installation` * `Folder Redirection` * `Scripts` * `Other settings`, for any extension Veza does not map to one of the categories above ### Where a Group Policy Object is linked Veza models where each policy is linked with the **`GPO_LINKED_TO`** relationship, read from the `gPLink` attribute on each organizational unit and on the domain root: * **Active Directory Group Policy Object** → `GPO_LINKED_TO` → **Active Directory Organizational Unit** * **Active Directory Group Policy Object** → `GPO_LINKED_TO` → **Active Directory Domain** A Group Policy Object has one `GPO_LINKED_TO` edge for every place it is linked, whether that link is enabled or disabled. This is the policy's configured scope: the organizational units and the domain where an administrator attached it. Whether the policy takes effect for the identities under those containers is resolved separately. See [Effective permissions on Group Policy Objects](#effective-permissions-on-group-policy-objects). ### Effective permissions on Group Policy Objects {% hint style="info" %} **Early Access:** Effective and system permissions for Group Policy Objects are built from Active Directory ACLs, the same Early Access capability behind [Effective permissions](#effective-permissions-early-access) for Groups and Organizational Units. They are produced only when **Extract ACLs** is enabled for the integration. The Group Policy Object entity and its `GPO_LINKED_TO` links are discovered whenever Active Directory is integrated and do not require this option. If ACL extraction is not enabled for your tenant, contact your Veza support representative. {% endhint %} When ACL extraction is enabled, Veza resolves which Group Policy Objects **effectively apply** to your identities and records the result as effective permissions on the policy: * **Active Directory User** → Effective Permission → **Active Directory Group Policy Object** (the policy effectively applies to this user). * **Active Directory Group** → Effective Permission → **Active Directory Group Policy Object** (the policy's security filter targets this group). A Group Policy Object effectively applies to a **user** only when all of the following conditions hold, matching how Active Directory itself evaluates policy: 1. The policy is linked to the user's own organizational unit or to a container above it (an ancestor organizational unit or the domain). 2. That link is enabled. 3. Inheritance is not blocked by an organizational unit between the user and the link, unless the link is enforced, which overrides the block. 4. The policy's user configuration is enabled; its status is not `UserConfigDisabled` or `AllDisabled`. 5. The user passes the policy's security filtering: the user, or a security group the user belongs to directly or through nesting, is granted the **Apply Group Policy** right on the Group Policy Object and is not denied it. A Deny always wins over an Allow. The **group** effective permission answers a different question: which security groups the policy is filtered to, that is, the groups an administrator selected as the policy's targets. Veza adds a **Group** → Effective Permission → **Group Policy Object** edge when all of the following hold: 1. The group is a security group. 2. The policy's user configuration is enabled. 3. The Group Policy Object has at least one enabled link. 4. The group is granted, and not denied, the **Apply Group Policy** right, resolved across security-group nesting with a Deny winning. This edge reflects the policy's targeting. It does not on its own mean every member is affected, because each member's effective application still depends on the five conditions above. {% hint style="info" %} These effective-permission edges are recorded on the principals a policy directly targets. Because group membership is transitive in the Access Graph, a query that walks nested groups can still reach a Group Policy Object through a parent group even where a Deny removed a nested group's own direct edge. Evaluate a Deny at the group it directly targets. {% endhint %} Veza also records the raw picture as **system permissions**: every account or group Veza extracted that is named in a Group Policy Object's ACL appears as a system permission on the policy, regardless of which right it holds. A trustee Veza did not extract, such as a security principal from a trusted domain, produces no system permission. The effective and system views answer different questions and are not the same set of principals. An administrator granted Full Control over a policy, for example, holds rights such as `GENERIC_ALL` and appears in its system permissions, but not in its effective permissions. Holding management rights over a Group Policy Object is not the same as having the policy apply. Only the **Apply Group Policy** right produces an effective-application edge. Because Veza resolves effective application the way Active Directory does, the effective view leaves out policies that do not truly apply, even when the policy still shows a `GPO_LINKED_TO` edge for its configured scope. A policy is left out when the Group Policy Object is disabled, when its link is disabled, or when an intervening organizational unit blocks the link's inheritance without enforcing it. With both views you can: * Find which Group Policy Objects effectively apply to a specific user or group, and which identities a given policy reaches. * Separate the administrators who can **edit** a policy (a system permission) from the identities the policy **applies to** (an effective permission). * Surface Group Policy Objects whose configured links produce no effective application (for example, because the policy or its link is disabled). ## 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 * Active Directory Password Settings Object * Active Directory Group Policy Object * Active Directory Special Identity Group Special identity groups are the built-in principals Active Directory defines by well-known SID rather than as domain objects, such as **Everyone**, **Authenticated Users** and **SELF**. Veza models them as groups so that access granted to one is visible in the graph alongside access granted to a normal Active Directory Group. {% hint style="info" %} **Special identity groups appear in System query mode only.** They are raw entities, so **Effective** query mode filters them out. To search for them, include them in an Access Review, or see what a permission granted to **Everyone** actually reaches, switch to [System query mode](/4yItIzMvkpAvMVFAamTf/features/search/query-mode.md). {% endhint %} 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, contact the Veza 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 | | Admin Count | adminCount | Set by AdminSDHolder; can remain after an account leaves a protected group | | 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](#active-directory-user-active-status) | | Is Critical System Object | isCriticalSystemObject | | | Is Locked | userAccountControl | Locked flag | | Is Protected | objectSid, group membership | Calculated by Veza; see [Protected accounts](#protected-accounts) | | Job Title | title | | | Last Name | sn | | | Last Logon | lastLogon, lastLogonTimestamp | Uses more recent value; see [Last Logon Attribute Behavior](#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 (e.g. NORMAL\_ACCOUNT, DONT\_EXPIRE\_PASSWORD, ACCOUNTDISABLE) | Active Directory Managed Service Accounts also have the **Admin Count**, **Is Critical System Object**, and **Is Protected** attributes. ### Protected accounts The `Is Protected` attribute is **true** for built-in accounts (Administrator, Guest, and `krbtgt`) and for direct or nested members of the Domain Admins, Schema Admins, Enterprise Admins, or built-in Administrators groups. Unlike `Admin Count`, it reflects current group membership. To detect users who get these rights through their primary group, turn on **Extract ACLs** for the integration. [Disable NHI accounts](/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-disable-accounts.md) uses this attribute to exclude privileged accounts. ### 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`, `PASSWORD_EXPIRED`, or `DONT_EXPIRE_PASSWORD`, 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](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/useraccountcontrol-manipulate-account-properties) for possible values. ### Last Logon attribute behavior 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`: 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`: 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, Veza: 1. Retrieves both `lastLogon` and `lastLogonTimestamp` attributes 2. Compares the two timestamps 3. Uses whichever value is more recent {% hint style="info" %} The `Last Logon` value in Veza 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 and will not be reflected in the `lastLogon` value from the queried DC. `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. {% endhint %} For more information, see Microsoft's documentation on [lastLogon](https://learn.microsoft.com/en-us/windows/win32/adschema/a-lastlogon) and [lastLogonTimestamp](https://learn.microsoft.com/en-us/windows/win32/adschema/a-lastlogontimestamp) attributes. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/integrations/active-directory.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.