# Active Directory or OpenLDAP User

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FD4pFTWlEuiTNgUy4pXoD%2FLocal%20Network%20rotations.jpg?alt=media&#x26;token=a54e5b3b-1dc1-4160-a142-d616e9c8f038" alt=""><figcaption></figcaption></figure>

## Overview

In this guide, you'll learn how to remotely rotate Active Directory or OpenLDAP user accounts using KeeperPAM.

## Prerequisites

This guide assumes the following tasks have already taken place:

* [Rotation enforcements](https://docs.keeper.io/en/keeperpam/privileged-access-manager/getting-started/enforcement-policies) are configured for your role
* A Keeper Secrets Manager [application](https://docs.keeper.io/en/keeperpam/privileged-access-manager/getting-started/applications) has been created
* Your [Keeper Gateway](https://docs.keeper.io/en/keeperpam/privileged-access-manager/getting-started/gateways) is online
* The Keeper Gateway is able to communicate via LDAPS (port 636) or LDAP (port 389) to your directory.

### 1. Set up a PAM Directory credential

Keeper Rotation will use the linked admin credential to rotate other accounts in your directory. This account does not need to be a domain admin account, but needs to be able to successfully change passwords for other accounts.

{% hint style="info" %}
The linked admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
{% endhint %}

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FLKl6RsmyYOEJBiI5gC1D%2FScreenshot%202025-01-08%20at%207.57.52%E2%80%AFPM.png?alt=media&#x26;token=36b0593c-3013-4fd8-a0c3-1353883e4484" alt=""><figcaption><p>PAM Directory record</p></figcaption></figure>

#### PAM Directory Record Fields

<table><thead><tr><th width="194.5">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Record Type</strong></td><td>PAM Directory</td></tr><tr><td><strong>Title</strong></td><td>Keeper record title</td></tr><tr><td><strong>Hostname or IP Address</strong></td><td>IP address, hostname or FQDN of the directory server. Examples: <code>10.10.10.10</code>, <code>dc01.mydomain.local</code></td></tr><tr><td><strong>Port</strong></td><td><code>636</code> - LDAPS is required for rotation on Active Directory.<br>LDAP over port <code>389</code> is insecure and should be avoided.</td></tr><tr><td><strong>Use SSL</strong></td><td>Must be enabled for use with Active Directory</td></tr><tr><td><strong>Administrative Credentials</strong></td><td>Linked PAM User credential used for performing the LDAP rotation. Example: <code>rotationadmin</code></td></tr><tr><td><strong>Domain Name</strong></td><td>Domain name of the Active Directory. Example: <code>mydomain.local</code></td></tr><tr><td><strong>Directory Type</strong></td><td>Set to <code>Active Directory</code> or <code>OpenLDAP</code></td></tr></tbody></table>

### 2. Set up a PAM Configuration

Note: You can skip this step if you already have a PAM Configuration set up for this environment.

A [PAM Configuration](https://docs.keeper.io/en/keeperpam/privileged-access-manager/getting-started/pam-configuration) associates an environment with a Keeper Gateway and credentials. If you don't have a PAM Configuration set up yet for this use case, create one.

<table><thead><tr><th width="200">Field</th><th>Description</th><th data-hidden></th></tr></thead><tbody><tr><td><strong>Title</strong></td><td>Configuration name, example: <code>My Active Directory</code></td><td></td></tr><tr><td><strong>Environment</strong></td><td>Select: <code>Local Network</code></td><td></td></tr><tr><td><strong>Gateway</strong></td><td>Select the Gateway that has access to your directory server</td><td></td></tr><tr><td><strong>Application Folder</strong></td><td>Select the Shared folder that contains the PAM Directory record</td><td></td></tr><tr><td><strong>Other fields</strong></td><td>Depends on your use case. See the <a href="../../../getting-started/pam-configuration">PAM Configuration</a> section.</td><td></td></tr></tbody></table>

### 3. Set up PAM User records

KeeperPAM will use the credentials linked from the "PAM Directory" record to rotate other "PAM User" records in your environment. The PAM User credential needs to be saved in a shared folder that is assigned to the secrets manager application. In the example below, the AD user `demouser` can be rotated.

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FlksgxWGHiHXbBOAOGr4R%2FScreenshot%202025-01-09%20at%2011.31.03%E2%80%AFAM.png?alt=media&#x26;token=ef96dd4c-6680-4306-b41f-03ada975a768" alt=""><figcaption><p>Example of Active Directory account password rotation</p></figcaption></figure>

#### PAM User Record Fields

<table><thead><tr><th width="194.5">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Record Type</strong></td><td>PAM User</td></tr><tr><td><strong>Title</strong></td><td>Keeper record title, e.g. <code>AD User - demouser</code></td></tr><tr><td><strong>Login</strong></td><td>Username of the account being rotated. The format of the username depends on the target system and type of service.<br><br>Examples:<br><code>demouser</code><br><code>demouser@domain.local</code></td></tr><tr><td><strong>Password</strong></td><td>Account password is optional. In most cases, a password rotation will not require the existing password to be present. However there are some scenarios and protocols which may require it.</td></tr><tr><td><strong>Distinguished Name</strong></td><td>Required for Active Directory and OpenLDAP directories.<br><br>The LDAP DN for the user, e.g.<br><code>CN=Demo User,CN=Users,DC=lureydemo,DC=local</code></td></tr></tbody></table>

If you don't know the user's DN, the following PowerShell command can be used to find it:

```
Get-ADUser -Identity <username> -Properties DistinguishedName
```

### 4. Configure Rotation on the Record

Select the PAM User record, edit the record and open the "Password Rotation Settings".

Any user with edit rights to a PAM User record and [enforcement policies](https://docs.keeper.io/en/keeperpam/privileged-access-manager/getting-started/enforcement-policies) allowing rotation has the ability to set up rotation for that record.

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2F0p1dou9o8QUgpZEuUhAg%2FScreenshot%202025-01-08%20at%208.11.11%E2%80%AFPM.png?alt=media&#x26;token=ebc39442-bb6a-40c6-b7e7-0780a162a890" alt=""><figcaption><p>PAM User scheduled rotations</p></figcaption></figure>

* The "Rotation" should be of type "General".
* The "PAM Resource" field should select the "PAM Directory" credential setup previously.
* Select the desired schedule and password complexity.
* Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.

### Troubleshooting

An easy way to test if LDAP is properly configured is to run 'LDP.exe' and test the connection. If this connection succeeds, then Keeper Rotation should also succeed.

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FKD087si6y6fF3dbuFWpy%2FScreenshot%202023-04-07%20at%2010.56.21%20AM.png?alt=media&#x26;token=6e360d49-856c-451a-816e-2b1490d44557" alt=""><figcaption><p>Testing and LDAP connection with LDP.exe</p></figcaption></figure>

### Testing with a Self-Signed Cert

For the purpose of testing an Active Directory user account rotation with Keeper, it is necessary to ensure that the LDAPS connection is active and using a valid certificate. If you are just testing and don't have a production certificate, the instructions below provide you with a self-signed cert.

{% hint style="warning" %}
Using a self-signed certificate with AD is only for testing purposes, do not use in production
{% endhint %}

{% stepper %}
{% step %}
**Create a cert**

From PowerShell running as an administrator, create a self-signed cert. Note that the subject name and alternate names of the certificate must match with the server hostname. In this example, the primary name is `XYZ123.company.local` with alternate names `company.local` and `company`.

{% code overflow="wrap" %}

```
New-SelfSignedCertificate -DnsName XYZ123.company.local,company.local,company, -CertStoreLocation cert:\LocalMachine\My
```

{% endcode %}
{% endstep %}

{% step %}
**Install the cert**

This script will locate the cert in the personal section of the certificate manager and copy it into the trusted domains. Replace the `company` parameter in the first line of this script with the domain in step 1.

{% code overflow="wrap" %}

```
# Get the cert we just created
$cert = Get-ChildItem -Path "Cert:\LocalMachine\My" | Where-Object {$_.Subject -like "*company*"}
$thumbprint = ($cert.Thumbprint | Out-String).Trim()

# Copy to NTDS through registry
$certStoreLoc = 'HKLM:/Software/Microsoft/Cryptography/Services/NTDS/SystemCertificates/My/Certificates'
if (!(Test-Path $certStoreLoc)) {
    New-Item $certStoreLoc -Force
}
Copy-Item -Path HKLM:/Software/Microsoft/SystemCertificates/My/Certificates/$thumbprint -Destination $certStoreLoc

# Copy to Trusted Root store
$rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store([System.Security.Cryptography.X509Certificates.StoreName]::Root, 'LocalMachine')
$rootStore.Open('ReadWrite')
$rootStore.Add($cert)
$rootStore.Close()
```

{% endcode %}
{% endstep %}

{% step %}
**Restart NTDS**

After restarting the NTDS service, the certificate should be installed.

```
Restart-Service NTDS -force
```

{% endstep %}

{% step %}
**Check the connectivity**

Run 'LDP.exe' and make sure that you're able to connect to the local domain over port 636 with SSL enabled.

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FEqolqHYLiMQnY7X8DaQT%2FScreenshot%202025-01-09%20at%2011.45.17%E2%80%AFAM.png?alt=media&#x26;token=e57fca91-d32d-46f9-9744-cc828d6cdc29" alt=""><figcaption><p>Connect using LDP.exe</p></figcaption></figure>
{% endstep %}
{% endstepper %}

### Production LDAPS Certification

For production deployments, KeeperPAM requires LDAPS with a certificate issued by a trusted Certificate Authority (CA).

Refer to the following table for the supported LDAPS certificates:

<table><thead><tr><th width="247.4140625">Certificate Issuer Type</th><th>Description</th></tr></thead><tbody><tr><td>Enterprise Internal Certificate Authority (CA)</td><td>Certificates are issued and managed by an internal PKI (such as Microsoft AD CS). This requires centralized certificate lifecycle management and is common in large enterprises, but may be less desirable in environments with many independently administered domains.</td></tr><tr><td>Public Certificate Authority (CA)</td><td>Certificates are issued by a trusted public Certificate Authority (e.g., DigiCert, GlobalSign, Entrust). This avoids the need for internal PKI infrastructure and is often preferred in environments with multiple domains or decentralized administration.</td></tr><tr><td>Server Authentication</td><td>The certificate must include the Server Authentication extended key usage to support LDAPS. This is a standard requirement for secure LDAP connections and applies regardless of the issuing CA.</td></tr><tr><td>Domain Controller FQDN</td><td>The certificate must be issued to the fully qualified domain name (FQDN) of the Domain Controller to prevent TLS validation errors. This may require individual certificates per Domain Controller in multi-DC environments.</td></tr></tbody></table>

Self-signed certificates are supported for testing only and are not recommended for production use.