AD Services Workload

This feature is currently available only to customers participating in a Private Preview. If you'd like to participate and be among the first to try this feature, ask our support or account team for details.

Overview

The Active Directory Services Workload is a service that enables secure communication between the Verify Privileged Identity Platform and your Active Directory (AD) environment. It delivers the Active Directory Services capability, which allows the platform to authenticate users, look up AD users and groups, and perform account operations such as password changes, resets, and unlocks.

This workload is a replacement for the legacy standalone Delinea AD Connector. For more information about that older solution, see AD Connector.

Benefits of Using AD Services Workload

  • Centralized Identity Management: Use Active Directory as the single source of truth for authenticating users on the Verify Privileged Identity Platform.

  • Secure Account Operations: Perform password changes, resets, and account unlocks directly through the platform.

  • Automated Maintenance: The workload is automatically updated and maintained by the platform after installation.

  • High Availability: Deploy multiple engines within a site for failover and load distribution.

Usage Scenarios

Active Directory Services are useful when you want to do any of the following:

  • Use Active Directory as the identity repository for authenticating users on the Verify Privileged Identity Platform.

  • Prompt users for RADIUS Authentication. See RADIUS Authentication.

  • Use Privilege Control for Servers (PCS). See Privilege Control for Servers.

Architecture

The workload functions in an architecture made up of domains and sites.

Domains

A domain represents an Active Directory domain. Each domain is registered in the platform with the DC hostname(s), connection mode (LDAPS or LDAP Sign & Seal), and the service account credential.

A single tenant can have multiple domains registered. Each domain is managed independently. Operations always target a specific domain.

Sites

A site is a logical grouping of engines, typically representing a network boundary such as a data center or office. A domain registration is bound to a site, meaning the workload deployed on those engines handles requests for that domain.

When a cloud service needs to perform an AD operation, it routes the request to the site associated with the target domain. If the site has multiple engines, the platform's transit layer selects one by latency (first available, then next on failure).

Limitation: A domain can only be assigned to one site. Multi-site support for redundancy and geographic distribution may be considered as a future enhancement.

Deployment

The Active Directory Services Workload can be installed and run on any Windows server, whether domain-joined or non-domain-joined.

This workload is installed along with the Platform Engine, requiring no separate installation procedure. Updates are managed automatically by the platform.

Prerequisites

  • A supported Windows server. See Server Hardware and System Requirements.

  • Port 443 outbound must be open on the server.

  • Service account in Active Directory with appropriate permissions for the operations you need (read, password reset, unlock). See Service Account Requirements.

  • Service account credentials must be stored as a secret in your IBM Security vault.

  • Administrator account on the Verify Privileged Identity Platform with access to engine management and the ability to create registered apps.

Configure the Active Directory Workload

This section describes how to configure the Active Directory workload on your platform tenant.

Step 1: Create Site and Install Engine

  1. In the Verify Privileged Identity Platform UI, open the Engines page.

  2. Click Add Engine.

  3. In Operating System, select Windows.

  4. In Capabilities, select Active Directory Services.

  5. In Select Site, click Select to choose an existing site or Create to make a new site.

  6. Click Generate Script.

  7. Copy the script and run it with administrator privileges on your target Windows server.

    Run the script within 24 hours. Otherwise, its device code will expire. See Installation Script Fails.

    Once installed, the engine appears in the engines list for your site.

  8. Click Go to site settings.

  9. Click Engines and select the engine you just added.

  10. In Workload settings, under Active Directory Identity Services, click Register AD Identity.

Step 2: Configure the Active Directory Domain

Domain configuration is managed in Registered Apps. Each Registered App represents a single AD domain.

  1. In the Verify Privileged Identity Platform UI, open the Registered Apps page.

  2. Select Add App, then select Customer Managed Active Directory.

  3. Complete the following fields:

    • Name

    • Description (Optional)

    • Site (select the site from Step 1: Create Site and Install Engine)

    • Domain (FQDN)

    • Protocol. Choose one of the following:

      Secure LDAP (TLS): Uses TLS over port 636. Recommended for all deployments. Requires an X.509 certificate on your domain controller.

      Secure LDAP (Kerberos): Uses Kerberos/SASL sealing over Port 389. No certificate required.

    • Secret name: Select a vaulted secret containing your service account credentials. If needed, create a Secret with the Active Directory Account template with an active user account for the domain.

  4. Click Save.

Step 3: Validate Domain Communication

  • From the domain configuration screen, trigger a validation.

The platform will test connectivity from your engine to your domain controller using the provided credentials. Each configured capability (read, password reset, unlock) is validated independently.

Once all capabilities show a Validated status, the Active Directory services are ready.

Step 4: Test the Integration

Test the following functionality:

  1. User Authentication: Log in to the Verify Privileged Identity Platform using an Active Directory user account. Confirm the login succeeds and the correct user profile is returned.

  2. User Lookup: While logged in to the Verify Privileged Identity Platform, search for an AD user by name, display name, or email. Confirm the correct user record is returned with expected attributes.

  3. Group Lookup: Search for an AD group by name. Confirm the group and its members are returned correctly.

  4. Self-Service Password Change: Log in to the platform as an AD user. Change your own password. Confirm it succeeds in AD.

  5. Admin Password Reset: Log in to the platform as an admin. Perform a password reset on a test account. Confirm it takes effect.

  6. Account Lock/Unlock: As an admin, lock and then unlock a test account. Confirm the account state changes in AD.

  7. Failover (multi-engine sites only): Take one engine offline. Confirm that AD operations continue to function through the remaining engine.

Service Account Requirements

This section describes the minimum level of service account permissions that are required to work with the AD Services workload. Additional permissions can be optionally granted for specific business situations.

The service account only needs delegated permissions. It does not need Domain Admin or any built-in AD group membership.

Capability Required AD Right Domain root
ad-domain-verification Authenticated Users (default read on rootDSE) Domain root
ad-users-read List Contents + Read All Properties User OU(s)
ad-groups-read List Contents + Read member attribute Group OU(s)
ad-user-pw-reset Reset Password (extended right) + Write pwdLastSet User OU(s)
ad-user-unlock Write lockoutTime User OU(s)
ad-user-lock Write userAccountControl User OU(s)