OpenBao Active Directory password rotation

How OpenBao Active Directory password rotation works

OpenBao's LDAP secrets engine manages directory account passwords so that OpenBao rotates them and hands them out for checkout, instead of leaving them fixed in configuration files, scripts and runbooks. The engine now ships as an external plugin, so you must install it into your OpenBao deployment and keep its version matched to the OpenBao release you run. The two cases this design targets are service accounts that applications and scripts depend on, and shared accounts that people currently check out by hand. The directories covered are Active Directory, OpenLDAP and RACF. Before you plan the work, confirm the exact plugin installation steps and the supported directory versions in OpenBao's current documentation for the release you run, because both can change between releases.

Think of the engine as holding a privileged bind account of its own. It uses that account to connect to the directory, changes the password of each managed account on a schedule or on request, and stores the new value inside OpenBao. Consumers then read the current credential through OpenBao policies, and every read is recorded in the audit log. Decide early which accounts can be rotated without human involvement and which are shared accounts where checkout is the right control. Some applications cache credentials or embed them in scheduled jobs, so each rotation interval must be coordinated with the owner of every consumer and tested before cutover.

The directory side needs as much attention as OpenBao. Active Directory Domain Services stores users and computers and replicates directory data to every domain controller in a domain, so a password change written to one controller must reach the others before a dependent system authenticates against a different one. Confirm with your directory team how replication timing and any lockout or password policy rules apply to the bind account and to each rotated account. Microsoft's comparison of Active Directory and Entra ID notes that most on-premises applications authenticate to Active Directory over LDAP, Windows-integrated authentication or header-based methods, so inventory which of those paths each dependent system uses before you change any password.

Plan the operating model before the build starts. Decide who owns the bind account and its permissions, who may check out shared accounts, how checkouts are approved and recorded, and what happens when a rotation fails partway through. A failed rotation can leave an application holding a password the directory no longer accepts, so the runbook must describe how an operator recovers that account. Ask the implementation team to demonstrate these paths in a test directory before production. Also confirm how the plugin is upgraded alongside OpenBao, because a version mismatch between the core server and the plugin tends to surface only after an upgrade. Record the OpenBao release and plugin build in each environment, and retest rotation whenever either changes. DeployOpen can plan and implement this design inside your own infrastructure, with the written scope fixing which directories, accounts and consumers are included.

What you need before connecting OpenBao to Active Directory

Six items need to be settled before the first rotation policy is written. Most of them sit with different owners, so assign each one a name and a date before the build starts. Work through the cards in order, since the directory and licensing items affect the sizing of the rest.

OpenBao cluster and matching plugin

Confirm the OpenBao cluster runs a release that is still supported, and that the LDAP secrets engine plugin is installed and compatible with that same release line. The plugin ships separately from the core server, so a version mismatch can block registration. Check the current release list on the OpenBao releases page, then test plugin registration in a non-production cluster before any directory credentials go in.

Narrow directory service account

Create a dedicated directory account for OpenBao whose only rights are the ones needed to read and reset the passwords of the accounts you manage. Avoid reusing a domain administrator or a shared operator login, because a compromised OpenBao credential would then carry directory-wide authority. Ask the directory team to scope the delegation to the target organizational units, then test a read and a reset against one test account before go-live. Record who approves the delegation and when it is reviewed.

Network paths and LDAPS trust

Open the network path from every OpenBao node to each domain controller the plugin will contact, using the LDAPS port your directory team confirms. Install the certificate authority chain that signed the domain controller certificates into OpenBao's trust configuration, so each TLS session validates against the controller name. Check firewall rules, DNS resolution for each domain controller, and any site or load balancer in front of them. Test from each OpenBao node, since one working node can hide a failing one.

Inventory of managed accounts

List every account the rotation will manage, with its directory, distinguished name, the business owner who approves changes, and each system that reads its password today. Shared and service accounts need their consuming systems named, because a rotation that breaks a scheduled job or an application pool often surfaces only after the change. Mark accounts that cannot be rotated without downtime so they receive a separate change window. Keep the inventory under change control, since it defines the scope of the rotation policy.

Domain controller version and support dates

Confirm which Windows Server version every domain controller runs, not only the newest ones, because a domain can run mixed versions. Windows Server 2022 mainstream support ended on October 14, 2026, and its extended support ends on October 15, 2031, according to Microsoft's Lifecycle page. Windows Server 2025, which became available on November 1, 2024, has mainstream support until November 14, 2029 and extended support until November 15, 2034. Record the dates that apply to your estate before you plan the upgrade window and the rotation rollout.

Windows licensing and client access

Windows Server 2025 is licensed per core, with a minimum of 16 cores per server and 8 cores per processor. Standard and Datacenter editions both need a Windows Server Client Access License for each user or device that accesses the server. These licenses are separate from OpenBao, so confirm the core counts, edition and access license counts with the license holder before you size the domain controllers. Pricing varies by region, so request a written quote for your location.

How the LDAP secrets engine rotates and checks out directory passwords

The LDAP secrets engine supports two patterns for directory passwords, and the choice between them shapes most of the design. The first is rotation of a managed service account: OpenBao generates a new password on a schedule and writes it to the directory, so only OpenBao holds the current value, and applications read it when they need it. The second is check-out of a shared account, where one person or job receives the password for a bounded time and OpenBao rotates it when the lease ends or the credential is checked back in. Start by sorting every account in scope into one of these two groups, because each group needs different consumers, different alerts and a different owner.

For rotation, the main decision concerns dependencies. Every service that authenticates with the account must be able to fetch the new value without an outage, so map which applications, scheduled tasks and middleware use each account before the first rotation runs. Ask the team that runs each service whether it caches the password, whether it re-reads the secret after an authentication failure and whether a restart is needed after a change. Then confirm, in the documentation for the installed plugin version, which rotation timing options exist, how the schedule is defined and what the plugin does when a rotation fails partway through, such as when the directory write succeeds but the new value cannot be stored.

Check-out suits shared accounts that people or batch jobs must still use, such as a legacy administrative login that cannot be retired yet. A lease gives the holder the current password for a bounded period. Because OpenBao applies its lease and revocation model here, access expires on its own and an operator can revoke it early. Check-outs and check-ins can be written to the audit device, so the question of who used a shared account at a given time has a direct answer. Before relying on this pattern, confirm in the plugin documentation exactly how check-in triggers rotation, whether a holder can extend a lease and what happens to a job that loses its lease while it is still running.

The directory account that OpenBao uses to make these changes is itself a high-value credential. Anyone who can read its password or use its bind rights can reset other accounts, so it should hold only the delegated permissions needed to change the passwords in scope, and it should sit in a tightly limited administrative group. Plan its rotation separately, with a documented procedure for the moment the bind password changes and OpenBao's configuration is updated in the same operation. Decide who can read or reconfigure the engine, how the initial password is handed over without landing in configuration files or tickets, and what break-glass access exists if OpenBao cannot reach the directory during an incident.

Configure the LDAP secrets engine step by step

This sequence takes an OpenBao cluster from a plugin install to managed password rotation and check-out for directory accounts. Each step builds on the one before it, and each ends with a check that confirms the layer beneath it before the next layer is added. The result is a tested configuration that the identity and platform teams can review and reproduce in each environment.

Install and register the plugin on every node
The LDAP secrets engine ships as an external plugin, so the same plugin binary must be placed on every OpenBao node and registered in the plugin catalog with a matching checksum. The platform team should use one release across all nodes so that no node behaves differently after a failover. Confirm the plugin loads by listing registered plugins on each node and checking that the LDAP entry appears. Restart one node and repeat the check to confirm the registration persists. Standby nodes need the plugin too, because a standby that cannot load it will fail when it becomes active.
Enable the secrets engine at a planned path
Enable the LDAP secrets engine at a path that names the directory and environment, such as a dedicated mount for each domain. A clear path lets policies, audit records and rotation settings identify the target without guesswork. Confirm the mount appears in the list of enabled secrets engines and that the audit device records the mount operation with the requesting identity. Keep a written record of the path, because consumer policies and managed account definitions will refer to it.
Create a least-privilege directory bind account
Create a dedicated bind account in the directory that holds only the rights needed to reset and read passwords for the accounts you plan to manage. Scope it first to a test organizational unit that contains disposable test accounts, so any delegation error stays contained. Store the bind password only in OpenBao configuration, then confirm the account can authenticate to the directory from each OpenBao node. Ask the directory team to confirm the delegated permissions in writing, because the exact rights depend on your domain design and your password policy.
Connect to domain controllers over LDAPS
Configure the connection to domain controllers over LDAPS, using the host names that your domain controller certificates cover. Load the full certificate authority chain into OpenBao so that every node validates the same chain. Plaintext LDAP would send the bind password across the network without protection, so the configuration must use the encrypted endpoint only. Verify the setup by running a successful bind test from each node. Then present a deliberately mismatched certificate in a controlled test and confirm that the connection fails with a certificate error.
Define managed accounts and rotation policy
Define the managed accounts or account sets that the engine will rotate, along with the rotation interval and password policy that apply to them. Begin with one non-production test account so you can observe rotation behavior without affecting a live service. Trigger a manual rotation, then confirm that the new password authenticates against the directory and that the stored value has changed. Add production accounts only after this test passes, and identify every service that caches the old password before you enable rotation for it.
Grant consumer policies and confirm access boundaries
Write consumer policies that allow check-out or read operations only on the accounts each consumer owns, and attach them to the identities or roles that need them. Keep rotation and configuration permissions with the platform team. Confirm the allowed path by checking out a test account with a consumer identity, then confirm the audit log records the request with the identity, the path and the result. Finally, request an account outside that policy and confirm that OpenBao denies the request and logs the denial.

Testing rotation before any production account changes

Do not point OpenBao at a production directory account until a written test plan has shown that the rotation, the dependent services and the directory policy all behave as expected. Start with a pilot on dedicated test accounts in a non-production domain or organizational unit. Build those accounts to match the production accounts they stand in for: the same password policy scope, lockout settings, group memberships and delegated permissions. Because the LDAP secrets engine now ships as an external plugin, confirm that the plugin version your team installs is the one your OpenBao release supports, and record that version in the test evidence.

Before the first production rotation, inventory every system that uses each managed account. A rotation can succeed in Active Directory, OpenLDAP or RACF and still fail a service that cached the old password. Typical consumers include Windows services, scheduled tasks, application pools, database connection pools, middleware, CI jobs, monitoring agents and mainframe connections. Build the list from directory logon activity, service configuration searches and owner interviews, not from memory. For each consumer, record the owner, the host, and the path the service uses to obtain its password, such as a read from OpenBao at startup, a file or an environment variable.

For each inventoried consumer, confirm that it re-reads the new password through its intended path after a pilot rotation, and that it does not keep serving the old value from a cache. Then test the failure case: an old password still in use should produce a visible authentication failure and alert, not a silent retry loop. Check the directory's password policy and account lockout settings against OpenBao's changes. Confirm that the generated password meets length, complexity and history rules, that fine-grained policies applied to service accounts do not differ from what the pilot tested, and that the lockout threshold cannot be reached by stale consumers during the rotation window.

Define a rollback plan for any account that a rotation breaks, and rehearse it on a test account. Confirm with the directory team and the OpenBao operators whether the previous password can be restored, for how long, and who may authorize it. If it cannot, document the break-glass procedure for resetting the account through directory administration, the order in which consumers are updated, and the named owner who confirms recovery. Record every test result as change control evidence: the pilot accounts, the inventory version, each consumer's re-read outcome, policy and lockout checks, rollback rehearsal results, and the approvals given before production work begins.

How directory accounts map to OpenBao roles and policies

This table traces each Active Directory or LDAP object to the OpenBao object that manages it, the team that owns it, the path a consumer uses to reach the credential, and the evidence the audit log should show. Read it row by row before configuring the plugin, because a missing owner or an unclear access path is usually where rotation projects stall. Exact configuration keys, field names and policy path syntax must be confirmed in the LDAP secrets engine documentation for the OpenBao version you install.

Directory object	OpenBao object	Owner	Access path and audit evidence
Bind account	LDAP secrets engine configuration with the bind credentials	Directory administration team	Only the OpenBao administrator policy reads the configuration. Audit logs show configuration writes and rotation of the bind password.
Managed service account	Static role tied to one service account and its rotation policy	Application owner named in the change record	Consuming service reads the current password through a policy-scoped path. Audit logs record each read with the calling identity.
Shared administrative account	Static role with check-out and check-in controls	Privileged access team	Named operators request a check-out under an approved ticket. Audit logs link each check-out to a person and a time window.
Rotation policy per account	Rotation schedule and password policy set on each static role	Directory security owner	Rotation runs are recorded by the engine. Evidence is the rotation history and any failed rotation alert for that role.
Consuming application	OpenBao policy attached to the application's auth identity	Application owner	Application authenticates with its approved auth method and reads only its own role path. Audit logs show denied reads for any other path.
Human operator	Policy bound to a directory group mapped through an auth method	Service desk and access governance	Operator logs in with their own identity and checks out only permitted accounts. Audit logs show identity, account and reason.
OpenBao policy granting access	Policy document listing read, update and check-out capabilities per path	Platform security team	Policy changes are reviewed in version control. Evidence is the approved change and the policy diff linked to the ticket.
Directory group or OU scope	Directory search scope in the plugin configuration (confirm exact keys in plugin docs)	Active Directory administrators	Limits which objects the bind account can manage. Evidence is the configured scope and the directory permissions granted to the bind account.

Hardening the directory bind account and rotation path

These controls protect the path from the directory to OpenBao and on to consuming applications. The bind account and the directory connection protect the credentials OpenBao uses, while policies, audit logging and admin restrictions control who can read or change the passwords it manages.

Dedicated bind account with narrow rights

Create a separate directory account for OpenBao that can only reset and read the passwords of accounts it manages, and limit it to the organizational units that hold those accounts. Give it its own rotation schedule and alerting on logons and password changes, so a compromise of the bind account is visible and contained. Confirm the exact delegated permissions with your directory team, since the rights needed depend on how your accounts are organized.

LDAPS with certificate validation

Connect OpenBao to the directory over LDAPS and configure it to validate the domain controller certificate chain against your internal certificate authority. Plain LDAP would expose the bind credentials and the passwords OpenBao writes to anyone who can observe the network traffic. Confirm that validation stays enabled during testing, because turning it off to make a connection work is a common shortcut.

Policies that scope each consumer

Write one OpenBao policy per consuming application or team, granting read or checkout access only to the specific accounts that consumer owns. Name the accounts by path so that no policy matches the whole directory by accident. Review the policies with the owner of each consumer, then test them with a token from each consumer to confirm that requests for another consumer's accounts are denied.

Audit logging forwarded to your log system

Enable an OpenBao audit device and send its output to the log platform your security team already monitors. Before enabling a device, confirm how sensitive values appear in the audit entries and whether your retention rules allow them to be stored. Check that forwarding recovers after restarts, that failed audit writes raise an alert, and that rotation and checkout events can be searched by account name.

Restricted access to the admin path

Limit who can change the LDAP secrets engine configuration, roles and policies, because those paths control the bind account and the accounts it can change. Keep administrative tokens short-lived and separate from consumer tokens, and require a named operator for each configuration change. Review who holds administrative policies on a fixed schedule and after any change in staff or team ownership.

Choosing the consumer auth method

OpenBao documents several auth methods, and its guidance recommends AppRole for servers and Userpass for developer machines. Choose the method that fits each consumer, then confirm in the OpenBao auth documentation that it suits that workload and how it handles secret ID delivery and rotation. Shared service accounts that run on several hosts need a deliberate design for how each host authenticates.

How Active Directory, OpenLDAP and RACF differ for this engine

Active Directory Domain Services is a Windows Server role that stores users and computers and replicates directory data to every domain controller in a domain. Because the plugin changes passwords through a domain controller, the password change reaches one controller first and then replicates, so your team needs to understand both the connection path and the replication behavior.

Domain controller and LDAPS: Decide which domain controllers the plugin connects to, and confirm that the connection is encrypted with LDAPS and that the OpenBao host trusts the certificate chain.
Password policy and lockout: Confirm how domain password policy, password age rules and account lockout thresholds interact with frequent automated rotation, because repeated failed binds can lock the service account.
Replication timing: Confirm how long a changed password takes to apply on every domain controller, and whether the plugin reads from a specific controller immediately after a change.
Windows Server platform: Windows Server 2025 is licensed per core with a minimum of 16 cores per server and 8 per processor, and Standard and Datacenter editions each need a Client Access License for every user or device that accesses the server. Windows Server 2022 mainstream support ends October 14, 2026, so confirm which release your domain controllers run.
Entra ID sync: If identities sync to Microsoft Entra ID through Entra Connect, confirm which system owns the account and which password is authoritative.

Confirm each item against the plugin documentation and your domain policy, and test a rotation in a non-production domain before any production account is added.

Common failures when rotating Active Directory passwords from OpenBao

This table lists the failure points teams most often hit when OpenBao rotates Active Directory or LDAP passwords, with the symptom, likely cause, check to run and fix for each. Work through the rows in order when a rotation fails, because the first three explain most failures before bind or lockout problems appear. Most failures trace back to plugin consistency, certificate trust and delegated permissions.

Failure point	Symptom	Likely cause and check	Fix
Plugin missing or mismatched on one node	Rotation succeeds through one OpenBao node and fails through another with plugin or engine errors	The LDAP plugin is absent or built for a different OpenBao release on one node. Compare plugin version and registered checksum on every node.	Install the plugin build matching the running OpenBao release on all nodes, register it with the same checksum, and restart nodes in a controlled order.
LDAPS certificate chain not trusted	TLS handshake or certificate verification errors on rotation, while plain LDAP tests may still work	The OpenBao host does not trust the CA or intermediate certificate that issued the domain controller certificate. From the OpenBao node, test the LDAPS handshake and confirm the full chain validates.	Add the root and intermediate CA certificates to the trust bundle the engine uses, then confirm the engine's CA setting points to that bundle.
Bind account lacks rights on target OUs	Permission errors when changing some accounts, or reads of certain entries return nothing	The bind account was not delegated password reset or read rights on every target organizational unit, or some accounts sit outside the delegated scope. Test a reset on a canary account in each OU using the bind account.	Delegate password reset and read permissions on the specific OUs in scope only, then repeat the canary test for each OU.
Password policy rejects generated passwords	Rotation fails with a length or complexity error only for certain accounts	The engine's password policy produces values that break the domain policy or a stricter fine-grained policy applied to those accounts. Compare the engine policy with the effective policies on the target accounts.	Align the OpenBao password policy with the strictest policy that applies to each target account, then test on a canary account.
Account lockout from repeated failed binds	Account locks shortly after a configuration change, with repeated failed logons in domain controller logs	A retry loop keeps binding with a wrong bind DN or password until the lockout threshold is reached. Review domain controller security logs for failed logons from the OpenBao host.	Stop the rotation job, correct the bind DN and password, unlock the account, and limit retries before any further change is made.
Consumers still using the old password	Applications or services fail to authenticate soon after a rotation reports success	Consumers cache the password or read it only at startup, and no reload is configured. List every consumer of each account and record how and when each one reads the current value.	Have consumers read the current value from OpenBao on use or on a defined refresh interval, and schedule rotations inside an agreed reload window.
Time skew or replication latency	Reads return the old password intermittently, or the new password fails from some sources right after rotation	Domain controllers have not yet replicated the change, or the read reaches a lagging controller. Clock drift also breaks Kerberos. Compare the password last set attribute across controllers and check time sync on all hosts.	Direct the write and the read to consistent domain controllers, allow replication to complete before dependent reads, and correct NTP drift before the next rotation.

What does it cost and take to rotate Active Directory passwords with OpenBao?

What drives the cost of rotating Active Directory passwords with OpenBao?

Cost follows the amount of work the rotation touches, not a fixed product fee. The main drivers are the number of managed accounts, the number of consuming systems and the change work each one needs when its password changes, the directory topology (a single domain or several domains and forests, where domain controllers sit, and whether Linux or RACF hosts are involved), the maturity of your existing OpenBao deployment, and the testing scope.

Design, plugin setup, bind account configuration and the first pilot are mostly one-time costs. Per-consumer integration, change control support and ongoing operations are recurring work. When you request a quote, ask for these lines separately: discovery, directory and bind account setup, OpenBao configuration, each consumer integration, testing in a non-production directory, handover, and any ongoing retainer. DeployOpen does not publish a price list. A quote follows the written scope.

Can our own team rotate Active Directory passwords with OpenBao alone?

Yes, for a narrow start. A single pilot account can be handled in-house by a team that includes a skilled directory administrator and an OpenBao operator who understands the LDAP secrets engine and its external plugin.

The difficulty grows with each consumer. Every service, scheduled task or application that reads the password must be found, updated at the right moment and tested. That work is mostly coordination and change control. Across many accounts, the bottleneck is usually getting each consumer owner to agree on timing.

Confirm that the plugin behaves as you expect in your OpenBao version before you commit, and test against a non-production directory first. DeployOpen can run the whole job or support the parts your team lacks.

What does DeployOpen need from our team before rotation work starts?

Start with four things. First, directory administrator access sufficient to create and scope the bind account that OpenBao uses to manage the target accounts, with permissions limited to what rotation needs. Second, an inventory of consumers: every system, service, scheduled job and person that uses each managed account, including where the password is stored today. Third, change windows agreed with the owners of those systems, because a rotation a consumer does not expect can cause an outage. Fourth, a named owner for each account who approves the rotation policy, the timing and the cutover.

Your team also needs a test directory or staging copy where rotations can be exercised before production. Put these in writing in the scope so gaps are visible early. Expect discovery to reveal consumers missing from the first inventory.

How long does Active Directory password rotation with OpenBao usually take?

No duration is given here. Time depends on the same drivers as cost. The longest phase is usually consumer change work, and OpenBao configuration tends to be shorter. A small pilot with one account and a few known consumers moves faster than a rotation across many accounts, several domains or forests, and consumers you have not yet inventoried.

Plan separate phases for discovery, directory and bind account setup, a pilot with testing, staged rollout by account group, and handover. Each phase depends on owners returning answers and on scheduled change windows, so calendar constraints often set the pace. DeployOpen scopes timelines in writing before starting work. Ask for dated milestones and the dependencies each one needs from your team.

What should a fixed-scope quote for AD password rotation include?

A fixed-scope quote should name what is in and out of scope in terms you can check. Ask for the managed accounts by name or group, the consumers for each account and the integration work each one needs, the directory topology the quote assumes, and the OpenBao version and plugin it targets.

Request the bind account design and its least-privilege permissions, the rotation policy for each account type, and the testing scope, including whether testing covers only a non-production directory or also a controlled production pilot. List change-window support, the documentation and runbooks delivered, handover sessions and acceptance criteria. State which items are one-time and which recur, such as operations or a retainer. Anything unlisted should be marked out of scope or handled as a change request. No price is given here. DeployOpen issues a quote once the scope is written.

What breaks most often when rotating directory passwords with a secrets manager?

The common failures are predictable. Consumers that cache a password keep failing until they reload it, and scheduled tasks or services running under a managed account can fail in ways that are hard to see. Microsoft describes Active Directory replicating directory data to every domain controller in a domain, so a password change needs time to reach all of them. Test that propagation window against the domain controllers your consumers actually authenticate to.

Confirm how your lockout policy reacts when a consumer retries with an old value. Other frequent problems include a bind account with broader permissions than needed or one that expires, shared accounts that are checked out and never checked back in, and LDAP or LDAPS connectivity that differs between test and production. Log every rotation and consumer read so you can trace a failure to one change. Build a rollback step for each account before rotating it.

Which directory and OpenBao details should we check before a pilot?

Check the directory version first, because it determines what your domain controllers support and how long they receive updates. Microsoft's lifecycle pages list Windows Server 2022 mainstream support as ending on October 14, 2026, with extended support ending October 15, 2031. Windows Server 2025 mainstream support ends November 14, 2029. Confirm the domain functional level, LDAPS certificate validity and which domain controllers your OpenBao network can reach.

Then confirm your OpenBao version and whether the LDAP secrets engine plugin is installed and supported for it, since the plugin ships externally. Check your storage and high availability setup, because rotation depends on the cluster staying available. Finally, list every consumer and its owner. These checks take time, and they decide the scope of any quote. DeployOpen can run this discovery as a fixed-scope first step.

How DeployOpen scopes and delivers this integration

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including OpenBao. For Active Directory and LDAP password rotation, we start from the directory and the accounts you need to control, then build the rotation and checkout workflow in your environment so credential handling stays under your governance.

How we scope

Inventory the directories in use, including Active Directory, OpenLDAP or RACF, and which service and shared accounts rotate
Agree which rotation policies, checkout rules and consumers apply, and where the LDAP secrets engine plugin will run
Confirm the written scope, deliverables and timelines before work starts, since most engagements are fixed-scope
Confirm with your directory team which bind account and permissions OpenBao will use, and whether a retainer covers later changes

How we build

Configure the LDAP secrets engine plugin against a non-production directory first, then verify rotation and check-in behavior
Test failure paths such as unreachable domain controllers, locked accounts and rotations that fail mid-cycle
Document how dependent applications and services receive rotated credentials, and where they must be updated
Confirm the plugin release and compatibility with your OpenBao version directly from the project release notes before installation

How we hand over

Provide configuration, role and policy documentation covering each rotated account and its owner
Walk your operations and directory teams through checkout, rotation alerts, and manual recovery steps
Deliver runbooks for emergency rotation, bind account replacement and rollback to manual password control
Record audit log locations and the evidence your assessors will need, without claiming any audit outcome

How we support

Offer ongoing support, upgrades and testing as a retainer after handover, if your team wants it
Plan plugin and OpenBao upgrades in a test cluster, with rotation tests repeated before production changes
Review directory permission changes and new shared accounts as they are added to the rotation scope
Agree response expectations and escalation paths in writing as part of the support terms

OpenBao Active Directory and LDAP password rotation