# 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" %} **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](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md#native-vs-custom-identity-mappings) for details. {% 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](/files/ox4P3e7LCXYXPsQdSPiX) 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. ## 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 * The FQDN of the AD DS Domain * LDAPS enabled on the Domain Controller and the root or leaf certificate 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 {% 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 includes 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.`). Both options can be used together. Veza tries the primary host first, then any manually specified failover hosts, then any DCs discovered via DNS. {% hint style="info" %} 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](#get-or-generate-an-ldap-certificate) for a multi-SAN certificate request example. {% endhint %} {% hint style="info" %} **Lifecycle Management**: Failover hosts are used for extraction only. LCM actions are performed exclusively through the primary host. {% 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 public certificate in **base64 format** (.CER Base-64) to validate the LDAPS connection. {% hint style="info" %} **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](#domain-controller-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. {% 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**: 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: ```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`: ```shell 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](#domain-controller-failover), and can also be used 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. If you are configuring [Domain Controller Failover](#domain-controller-failover), add a `_continue_` entry for each DC hostname so that a single certificate is valid for all domain controllers: {% 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 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: ```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:** 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. ```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 settings and turn on **Enable Provisioning**. 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) | | **AD domain fully qualified domain name for cert** | Subject Name on the LDAPS leaf certificate; used for TLS verification. Only applies to LDAPS (port 636) and Kerberos TLS connections. | | **LDAP Certificate** | SSL/TLS certificate used to establish the LDAPS connection. 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** | Uncheck 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 | | **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](/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 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. This feature is disabled by default. To enable it, select **Extract Access Control Lists for Groups and Organizational Units** in the integration configuration. 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** {% hint style="info" %} **Scope:** 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 ## 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](#active-directory-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](#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 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: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/integrations/active-directory.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.