Active Directory
Rotating Active Directory user accounts remotely using KeeperPAM
Overview
In this guide, you'll learn how to remotely rotate Active Directory user accounts using KeeperPAM.
Prerequisites
This guide assumes the following tasks have already taken place:
Rotation enforcements are configured for your role
A Keeper Secrets Manager application has been created
Your Keeper Gateway is online
The Keeper Gateway is able to connect to your Active Directory via LDAPS (port 636)
1. Set up a PAM User Record
Keeper Rotation will use the credentials in this PAM User record 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.
PAM User Record Fields
Record Type
PAM User
Title
Keeper record title
Login
The username of the Active Directory admin. The format of the username depends on the target system and type of service.
Examples:
Administrator [email protected]
Password
Password of the admin user on the Active Directory.
Distinguished Name
Full Distinguished Name (DN) of the admin user on the Active Directory.
2. Set up a PAM Configuration
A 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.
Title
Configuration name, example: My Active Directory
Environment
Select: Domain Controller
Gateway
Select the Gateway that has access to your directory server
Application Folder
Select the Shared folder that contains the PAM User record created in step 1.
Administrative Credential
Select the PAM User record created in step 1.
Hostname or IP Address
Enter the domain or IP address of your Active Directory domain.
Port
Enter 636 (LDAPS). 389 LDAP is not supported for rotations.
Use SSL
Ensure this checkbox is checked.
3. Set up PAM User records
KeeperPAM will use the credentials linked from the PAM User 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.
PAM User Record Fields
Record Type
PAM User
Title
Keeper record title, e.g. AD User - demouser
Login
Username of the account being rotated. The format of the username depends on the target system and type of service.
Examples:
demouser
[email protected]
Password
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.
Distinguished Name
The LDAP DN for the user, e.g.
CN=Demo User,CN=Users,DC=lureydemo,DC=local
If you don't know the user's DN, the following PowerShell command can be used to find it:
Get-ADUser -Identity <username> -Properties DistinguishedName4. 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 allowing rotation has the ability to set up rotation for that record.
The "Rotation" should be of type
IAM User.The "PAM Configuration" field should point to the Active Directory PAM Configuration created in step 2.
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.
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.
Using a self-signed certificate with AD is only for testing purposes, do not use in production
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.
New-SelfSignedCertificate -DnsName XYZ123.company.local,company.local,company, -CertStoreLocation cert:\LocalMachine\MyInstall 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.
# 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()
Last updated
Was this helpful?