How OpenStack Keystone LDAP and Active Directory integration works
Keystone can let employees sign in with directory credentials through its LDAP identity back end, configured per domain. The directory supplies the user identities, while Keystone keeps control of projects, roles and assignments. From Keystone's side the directory is read-only: Keystone looks up users and groups but does not create, change or delete directory entries. The design is planned and built inside your own infrastructure, including your cloud accounts, data centers or air-gapped network. Private cloud teams usually need this split because employees should come from Active Directory or LDAP, while automation accounts used by pipelines and orchestration should stay under cloud control.
Keystone organizes identity by domain, and each domain can use a different identity back end. One common pattern is a directory-backed domain for people and a SQL-backed domain for service accounts, so automation keeps working when a person's directory account is disabled or when the directory is unavailable. Before the build, decide which domains will exist, which population belongs in each, and whether any user needs access to more than one domain. Also decide how name collisions between domains are handled. Confirm with the Keystone configuration reference for your release how per-domain driver configuration is enabled and where those domain settings are stored, because this detail changes between releases.
Directory group membership does not grant OpenStack access on its own. Keystone grants access through role assignments on projects and domains, so the link from a directory group to a role is a mapping decision your team owns. Because the directory is read-only, group membership is taken as the directory reports it, and changes made in the directory reach Keystone according to the lookup and caching behavior you configure. Decide which groups map to which roles, who approves changes to those mappings, and how a departing employee's access is removed. Test the mappings against a copy of the directory before production so that a broad group does not give unintended administrative rights.
Plan for the limits of read-only LDAP. Keystone cannot create users, reset passwords, unlock accounts or enforce directory password policy, so those tasks stay with the directory team. Option names, attribute mappings, TLS settings and cache timeouts depend on the OpenStack release in use. Confirm each one against the Keystone configuration reference for that release before the build begins, and record the release and reference version in your design document. Ask your directory team to confirm the bind account, the search bases, the group object structure and the TLS trust chain, since these inputs shape most of the configuration work.
What you need in place before Keystone reads your directory
Keystone can only read a directory that is reachable, trusted and accurately described, so these checks come before any configuration file is edited. Each card sets a decision or dependency that the LDAP or Active Directory driver relies on later. Confirm them with your directory and security owners before changing any Keystone node.
Maintained OpenStack release and deployment tool
Choose a maintained release first, and check the driver options against the release you deploy. Use a maintained release such as 2026.1 Gazpacho, a SLURP release published on 2026-04-01, and confirm the current maintained list on the OpenStack releases site before you commit. Then choose Kolla-Ansible, which runs OpenStack in Docker containers, or OpenStack-Ansible, which uses LXC containers or bare metal, and follow the matching 2026.1 deployment guide.
Read-only bind account and search structure
Create a dedicated bind account with read-only access to the user and group subtrees Keystone needs, and do not reuse an administrator account. Document the search base for users, the search base for groups, the attributes used for login names and group membership, and whether nested groups are in use. Keystone depends on these values, so an undocumented OU move or attribute rename can break sign-in later.
Network paths from every Keystone node
Every Keystone node, including any host that runs the service in a container, needs a route and firewall rule to the directory on LDAP port 389 or LDAPS port 636, depending on the transport you choose. Test each node directly, since one successful test from an administrator workstation does not prove the others work. Also confirm DNS resolution of directory hostnames from inside the containers, and check the addresses of any load balancer or replica that clients will use.
CA chain for directory certificates
If you use LDAPS or StartTLS, Keystone hosts must trust the full certificate chain that issued the directory certificate, including any intermediate authority. Obtain the root and intermediate certificates from your PKI team, install them in the trust store the deployment uses, and confirm that the directory hostname matches the name Keystone connects to. Record the expiry date and the renewal owner, because an expired directory certificate can stop authentication for every user at once.
FreeIPA or an AD domain controller
Decide which directory answers Keystone's queries before you write any configuration. Where an Active Directory forest already serves staff, it is normally the default choice for employee identity. FreeIPA, a community project licensed GPL-3.0-or-later, suits Linux-heavy estates that want an integrated directory with Kerberos and certificate services. If you choose FreeIPA, plan at least two to three replicas in each datacenter on dedicated servers, following the FreeIPA deployment recommendations.
Per-domain drivers: keeping service accounts in SQL while employees come from the directory
The core decision in this design is to split identity sources by Keystone domain instead of pointing the whole cloud at one directory. One domain is backed by LDAP or Active Directory and holds employees. The default domain stays backed by Keystone's SQL identity driver and holds service accounts, automation users and break-glass administrators. If the directory is slow, misconfigured or unreachable, the SQL-backed accounts still authenticate, so pipelines and operators with emergency access are not locked out of the cloud at the moment they need it most. Keystone treats each domain as a separate namespace with its own identity back end. A user is identified by a name within a domain, so the same name can exist in two domains as two different users. Operators must decide several things before configuration begins. They need to choose domain names that are stable and meaningful to auditors, such as one name for employees and one for service accounts. They need to decide whether user IDs are generated by Keystone or derived from directory attributes, because changing this later affects role assignments and audit trails. They also need a rule for name collisions, for example a service account named the same as an employee's directory login, and a process that blocks such names from being created. The design also depends on the directory product. If the corporate directory is FreeIPA, which runs 389 Directory Server as an LDAPv3 directory, the LDAP path described here applies, and you should confirm the exact attribute names and bind model against your FreeIPA version. An Active Directory trust from FreeIPA is a different design. It is established through Samba components, requires that the IPA domain use a DNS namespace that does not overlap with any domain in the AD forest, and changes how user principals and domain names appear. Do not treat a FreeIPA trust as a shortcut to the LDAP configuration in this section. Before finalizing the layout, check three things with your directory team. Confirm which domain holds each population, confirm that the SQL-backed accounts are the only ones allowed to hold break-glass roles, and record how a service account is created, rotated and removed. Test a login against each domain while the directory is deliberately stopped in a non-production environment. Those results define what the emergency path actually protects, and they should be written into the operations runbook before go-live.
OpenStack Keystone LDAP and Active Directory integration steps in order
This sequence connects Keystone to a corporate directory in a controlled order, so each layer is proven before the next one depends on it. The result is a read-only directory domain for employees, with service accounts still held in the SQL domain and verified at the end.
Confirm directory reachability and certificate trust
The network team or directory administrator confirms that every Keystone controller can open the directory's LDAP over TLS connection and reach each listed directory server by name. Run a test search with a standard LDAP client from each controller, and check that the certificate chain validates against the CA bundle the Keystone containers or hosts will actually use. This step is closed when the query returns entries with no trust warnings from every controller. A single controller with a missing CA usually fails only intermittently, so test all of them.
Create and test the read-only bind account
The directory administrator creates a dedicated service account with read access to the user and group subtrees Keystone needs and no write permissions. Test a bind with that account and run a sample search under the intended base, then attempt a modification to confirm it is refused. Store the password in the deployment's secrets handling, not in shared configuration files. Confirm the password expiry policy with the directory team before go-live, because an expired password breaks authentication later without a clear error in Keystone. This step is closed when the bind and search succeed and the write attempt fails.
Define the domain and its LDAP settings
The platform engineer adds a domain-specific configuration for the directory domain in the deployment tool's configuration. It includes the server URL, the bind account, the base distinguished names for users and groups, object classes and attribute mappings, filters that limit which accounts are visible, and TLS settings. Confirm with the release's documentation which option names and per-domain configuration method apply to the release in use. Keep the SQL-backed domain used for service accounts unchanged. A second engineer reviews the diff, and the step is closed when the rendered configuration validates and changes only the new domain and its enabling settings.
Apply the configuration through the deployment tool
The operator runs the deployment tool's Keystone reconfigure task, using Kolla-Ansible or OpenStack-Ansible depending on how the cloud was deployed. Read the play output for failed tasks, then confirm that the Keystone services restarted on every controller. Check the Keystone logs for the new domain loading and for any LDAP bind or certificate errors. Where the tool allows, reconfigure one controller at a time so the identity API stays available. This step is closed when all controllers report the same configuration and the logs show no LDAP errors.
List users and groups from the new domain
Using the OpenStack client with administrative credentials, the operator lists users and groups scoped to the new domain. Directory accounts and groups should appear with the correct domain name. If the lists are empty or incomplete, the base distinguished names and object filters are the first things to check. Compare a known test user and a known test group against the directory to confirm the attributes match. Also list the SQL default domain and confirm its service accounts are still present. This step is closed when the expected directory entries appear and the SQL domain is unchanged.
Assign a test group to a project role
The operator creates a test project and assigns a single, narrow directory group a role on that project using a domain-qualified group reference. Confirm the assignment in the role assignment list for the project. Use a test group, not a broad organizational group, so the first test has limited blast radius. The step is closed when the role assignment list shows exactly the intended group, role and project. Record the group name, role and project in the change record so the access model can be audited later.
Confirm directory login and service account access
A member of the test group signs in through Horizon or the command line and requests a token scoped to the test project. Confirm that the user sees the project and holds only the assigned role. Then authenticate a SQL-domain service account, such as one used by automation, and confirm it still obtains a token and completes a read call. Attempt a write as the directory user to confirm the read-only setup refuses it. The step is closed when both accounts behave as expected and the results are recorded in the change record.
How directory users, groups and attributes map to Keystone domains, groups and roles
This table pairs each directory object with its Keystone counterpart, so the team can see where an employee, an access group and a project role meet. Read it as a checklist to complete before the first configuration change, because the unique identifier and group filters are hard to undo once users exist. The main takeaway is that the identifier choice and the group-to-role rules decide how access behaves after staff join, move or leave.
| Directory object or concept | Keystone counterpart | What the team must decide or confirm |
|---|---|---|
| User identifier | Unique user ID in the LDAP-backed domain | Choose an attribute that is unique and never reassigned, such as objectGUID or a directory-issued immutable ID, instead of sAMAccountName or email, which can change. Confirm the attribute name for your directory version. |
| Display name | User name shown in the dashboard and CLI output | Map the directory display name attribute. Confirm the exact attribute name in the release documentation, since display changes do not affect authorization. |
| Optional user email attribute | Map it only if notifications or audit reporting need it. Keep it out of the login identifier, because email addresses change and may be reused. | |
| Access group object | Group filter that selects groups Keystone may read | Set the group object class and filter so only security groups meant for OpenStack are returned. Confirm the filter syntax and group membership attribute for your release. |
| Keystone domain | Per-domain LDAP driver section, with employees from the directory and service accounts in SQL | Keep service accounts and automation identities in the SQL backend so they survive directory outages and are not tied to a person's employment status. |
| Keystone group | Group created or referenced in Keystone for each directory group that grants access | Create one Keystone group per access level, not per team member. Name it so an assessor can trace it back to the directory group it represents. |
| Role on a project | Role assignment linking a Keystone group to a project | Assign roles to groups on projects, not to individual users. Review role names against the policy file of your release before granting them. |
| Nested groups | Usually not expanded by Keystone unless the release and directory support it | Flatten access by granting roles to the direct group, or confirm nested group behavior in the documentation for your release before relying on it. |
| Groups that grant no access | Excluded from the group filter or left unassigned to any project role | Exclude distribution lists, mail-only groups and notification groups so they cannot be mistaken for access. Document the exclusion for the access review. |
Group-to-role assignment and the limits of read-only LDAP
Under a read-only LDAP identity back end, Keystone reads users and groups from the directory and never writes to it. Passwords, group membership and account lifecycle changes therefore happen in Active Directory or LDAP, and OpenStack sees the results the next time a user authenticates or a token is issued. This split is the central operating fact of the integration. Your identity team, not the cloud team, owns the moment an account is created, disabled or removed. Before you commit to a design, confirm with the Keystone documentation for your target release whether any write or password-change operation is available through the LDAP driver and which configuration settings it requires. Do not assume write behavior from older guides or community posts.
Role assignments in Keystone are not stored in the directory. Each assignment ties an actor to a domain or project and a role. When the actor is a directory group, Keystone records the group's identifier in its own database, and membership is resolved from the directory at authentication. Adding someone to the group grants the project role without any change in OpenStack, and removing them revokes it at the next token issuance. Audit is therefore split across two systems. Directory change logs show who joined or left a group, while Keystone's own logs and any audit notifications you enable show who created or deleted an assignment. Plan a single change record that links both, and confirm which Keystone audit events your release emits and where they are sent.
Assigning roles to directory groups is the design most teams should choose, because it keeps Keystone configuration stable across joiners and leavers and makes the directory group the single approval point. The risk sits in assignments that do not follow this pattern. A role granted directly to a user, a group that was renamed or recreated, or a project whose only assigned group has been removed can outlive the person who needed it. Those leftovers keep working after that person leaves the company unless someone removes them. Disabling the directory account blocks new logins, but tokens already issued remain valid until they expire. Confirm the token lifetime your deployment uses and write it into the offboarding procedure.
Before go-live, run three checks. First, export every direct user role assignment in each domain and project and decide whether it should move to a group. Second, record an owner for each project and each role-bearing group, so that someone can confirm leftover access during periodic review. Third, test a departure end to end: disable a test account in the directory, confirm its logins fail, confirm that tokens it already holds expire within the window you documented, and confirm that its project role assignments are either removed or flagged for removal. Repeat the review on a fixed schedule and tie it to your directory's access certification process if one exists.
Securing the bind account, transport and access paths
Keystone reads user and group data from the directory through one service identity, over a connection that carries credentials, and only the hosts that need that path should reach it. The six controls below depend on each other: a narrow bind account, managed secrets, encrypted transport, restricted network paths, controlled admin access and reviewed failure logs. Check each one against your directory team's configuration before go-live.
Give the bind account read-only scope
The bind account is the identity Keystone uses to search the directory, so it is the first credential an attacker would target. Create a dedicated service account that can read only the user and group attributes Keystone needs for lookups and group mapping. Confirm with your directory team that it has no write rights, no membership in administrative groups and no access to unrelated organizational units. Test the scope by attempting a write with it and confirming the directory refuses.
Rotate the bind password through secret handling
Store the bind password in the secret handling your deployment tool supports, such as Ansible Vault or the encrypted password file used by Kolla-Ansible or OpenStack-Ansible, and keep it out of plain configuration files and shell history. Agree a rotation schedule with the directory team and confirm that a rotation updates the stored secret and restarts the Keystone services that read it. Check that the old password stops working after cutover. Write the procedure into the runbook so it does not depend on one person.
Encrypt directory traffic with a pinned CA
Simple binds send credentials and user lookups across the network, so the connection must be encrypted. Choose LDAPS or StartTLS based on what your directory accepts, and confirm the port and protocol with the directory team before configuring Keystone. Pin the directory's certificate authority in the trust store on every Keystone host and keep certificate validation enabled, so a spoofed server cannot complete the handshake. Verify the chain from each controller, because one host with validation turned off weakens the whole integration.
Restrict which segments reach the directory
Only Keystone controllers and the hosts that operate the identity service should open connections to the directory. Define firewall or security group rules that allow the LDAP or LDAPS port from those addresses only, and block that port from tenant networks and general data center segments. Ask the directory team which domain controllers or read-only replicas Keystone should use, then confirm the network path from each controller to them. Repeat the review whenever a controller is added or moved.
Limit the admin domain and SQL fallback
Per-domain drivers let directory users sign in to their own Keystone domain while service and administrative accounts remain in SQL, so the two groups must stay separate. Keep the admin domain for a small named group of operators, and record who belongs to it and why. Ensure no directory account holds cloud-wide administrative rights by default. Where your design allows, disable the SQL fallback credentials. If break-glass access must remain, rotate those credentials on a schedule and store them in secret handling.
Log authentication failures for review
Failed binds and rejected logins are the earliest signal of a misconfigured or abused integration. Confirm which Keystone and directory logs record failed authentication, how long they are kept, and where they are forwarded for review. Watch for bind failures from the service account, repeated failures against one user, and failures from unexpected source addresses. Agree who reviews these events and how an alert becomes an incident ticket. Confirm that log entries never include passwords.
Verifying directory logins before users depend on them
Before any employee signs in to OpenStack through the directory, run a written test plan that proves the Keystone LDAP or Active Directory back end behaves the way your access model says it should. The plan should cover authentication, removal, group-driven role assignment, outage behavior and token scope. Treat each check as a pass or fail item with a named owner, so the result can be reviewed later without relying on memory or on a single engineer's walkthrough. Start with login tests using at least two accounts from a test group that maps to a known project and role. Confirm that a valid employee can authenticate through the domain configured for directory users, and that a wrong password is refused. Repeat the same checks against the domain that holds your SQL service accounts, so you can see that the two domains do not leak into each other. Record the domain name, the user identifier used at login and the exact error returned for each failed attempt, because these details are what an engineer will need when a user reports a problem later.
Next, test removal and group change. Disable or remove a test user in the directory, then confirm that new authentication attempts fail and that any existing API or CLI sessions are handled according to your token lifetime settings. Then move a second test user out of a group that grants a project role and into a group that grants a different role. Confirm that the Keystone role assignment changes as the group mapping predicts. Because the back end is read-only, make these changes in the directory itself, not in OpenStack, and check whether role assignments update on the next login or only after a refresh. Confirm that timing with your own configuration rather than assuming it. Run an outage test by making the directory unreachable from the Keystone nodes, for example by blocking the connection at the network level in a non-production environment. Verify that SQL-backed service accounts still authenticate and that directory users are refused with a clear error rather than an ambiguous one. Also check that Keystone recovers once connectivity returns. If the directory runs in more than one site, include a failover test against a second replica, and confirm which replica each Keystone node uses and what happens when the primary is stopped. A test that only covers the primary server leaves the most likely production failure untested.
Finally, confirm that tokens issued to directory users carry the intended project scope. Request a token for a test user scoped to a single project, inspect the returned roles and project identifier, and confirm that the user cannot obtain a token for a project they are not mapped to. Repeat the check for a user whose group membership has just changed. Store the commands, the inputs, the outputs and the date for each check, along with the configuration version under test. Keep these results as evidence for internal security and compliance review, and rerun the full plan after any change to the domain configuration, the directory schema, the replica topology or the OpenStack release. Ask your implementation partner to deliver the plan and results in this form as part of the fixed-scope work.
Common Keystone LDAP and Active Directory failures and how to fix them
This table lists the failures teams most often hit when Keystone reads users and groups from LDAP or Active Directory, with the cause, the fix and the check that confirms the fix. Work down the rows in order, since bind and certificate problems block every later test. The main takeaway is that most failures trace back to the directory connection settings, group mapping or token lifetimes, and each can be confirmed with a direct test.
| Failure | Cause and fix | Check that confirms the fix |
|---|---|---|
| Users and the service account fail to bind | Wrong bind DN or password, or a disabled account. Correct the DN, rotate the password in the driver settings and re-enable the account. | Bind with the same DN from the Keystone host using an LDAP client. The bind must succeed. |
| Certificate validation errors on LDAPS or StartTLS | Incomplete CA chain, usually a missing intermediate. Install the full chain on the Keystone host and point the CA file setting at it. | Run openssl s_client against the directory's LDAPS port and confirm the chain verifies. |
| Group lists come back empty | Wrong group search base or filter, often an OU that holds no groups. Correct the base DN and the object class filter. | Query the group tree with the configured base and filter and confirm the expected groups return. |
| Users authenticate but see no projects | Group-to-role assignments are missing or point to the wrong project or domain. Create or correct the assignment for each directory group. | List role assignments for a test user and confirm each group maps to the intended role on the intended project. |
| Same user name appears in two domains | Two directories hold the same user name, and login resolves to the wrong account. Keep names unique within each domain and map each domain to one directory. | List users per domain and confirm each name resolves to one account with the expected domain ID. |
| Logins are slow or time out | Slow directory responses, a distant or unreachable server, or deep nested group expansion. Point to a nearby server, set timeouts and reduce group nesting. | Time a bind and a user search from the Keystone host, then time a login with the same test user. |
| Removed users keep access | Cached identity data and long-lived tokens persist after the directory change. Shorten cache expiry and token lifetime, and revoke existing tokens for removed users. | Disable a test account, revoke its tokens and confirm that new authentication and existing tokens both fail. |
What does an OpenStack Keystone LDAP integration cost and take to deliver?
How much does an OpenStack Keystone LDAP integration cost?
No public figure applies to every environment, and DeployOpen does not publish prices, so the cost comes from a written scope. The largest line item is labor: planning the domain layout, configuring Keystone domain-specific drivers, testing logins and role assignments against the directory, and handing over runbooks. Infrastructure costs are separate and usually sit with your organization, including directory service accounts, certificates, load balancer or firewall changes and test environments. Ask the quote to show who is paid for each item, whether it is fixed or time-based, and which assumptions it depends on. Compare it with an internal estimate built on the same assumptions so the two can be read side by side.
How long does a Keystone LDAP integration take to deliver?
The duration depends on the directory, the number of Keystone domains and how quickly approvals and change windows move, so the written timeline is the figure to rely on. Much of the calendar time is often waiting on people: directory administrators creating a bind account, network teams opening paths to the directory servers, and operations agreeing a change window for the Keystone configuration change. Testing takes longer when many groups map to many roles. Ask the partner to break the timeline into phases, list the dependencies your team must clear, and state the date each dependency is needed. A timeline without named dependencies usually slips at the first approval.
What makes the Keystone LDAP work larger or smaller?
The biggest driver is the number of Keystone domains, since each domain with its own directory back end adds configuration, testing and documentation. Directory complexity comes next: a single organizational unit with clean group membership is simpler than nested groups, multiple forests, referrals or inconsistent attributes. The number of Keystone regions multiplies deployment and verification, because each region needs its configuration applied and its logins tested. Certificate work applies when the directory is reached over LDAPS, because the certificate authority must be trusted by every Keystone controller. Network work covers firewall rules and routes from each controller to each directory server. Testing depth ranges from a basic login check to role mapping verified for every project. Running a release upgrade in the same change adds scope and risk.
Which parts of the integration are one-time and which recur?
Design, initial configuration, certificate setup, testing and handover are one-time work. Recurring effort comes from keeping the integration current: adjusting group-to-role assignments as teams change, handling directory schema or server changes, renewing certificates, and retesting the driver configuration after Keystone upgrades. Your organization also carries ongoing directory administration and access reviews, which continue after the project closes. If you want DeployOpen to handle recurring work, DeployOpen offers retainers, and the scope should be written down, listing the change types covered, how requests are submitted and which upgrades and testing are included. Ask the quote to separate one-time and recurring amounts so both can be budgeted.
What does our team need to provide for the integration?
Plan on providing four things. Directory administrators confirm the schema, create a read-only bind account for Keystone, supply the search bases and group structure, and approve the attribute mapping. A test group of ordinary, non-privileged users should exist so logins and role assignments can be verified before production. Network teams open the path from every Keystone controller to the directory servers and handle certificates if LDAPS is used. Operations must agree a change window that covers the Keystone configuration change and a rollback plan. Name an owner for each item in the written scope so delays show up early, and confirm who signs off each test result before go-live.
Can our own team build this with the Keystone documentation?
A capable team can configure Keystone domain-specific drivers from the upstream Keystone documentation, provided it has OpenStack operators who can change the Keystone configuration safely, directory administrators who understand the schema, and a test environment. The harder parts are usually not the configuration settings. They include choosing a read-only design that fits your directory, mapping groups to roles without granting more access than intended, validating behavior in every region, and writing a runbook for later changes. Those tasks draw time from people who are already busy. Decide by comparing the skills available in-house with the work in the written scope. A narrower request, such as a design review or a test plan, is a practical middle option.
What should a written quote for Keystone LDAP integration include?
A usable quote states the scope in the same terms as the design. Ask for the number of Keystone domains and regions covered, the directory type and number of directory servers, the group-to-role mapping approach and the expected number of mappings, and how LDAPS and certificates are handled. Include the test depth, who signs off each test, and whether any release upgrade is included. The deliverables should be listed, such as configuration, runbooks and handover sessions, along with the client responsibilities and dependencies. Request a timeline by phase with milestones, a split between one-time and recurring costs, and the changes that would trigger a new quote. DeployOpen's fixed-scope engagements are agreed in writing before work starts.
Should the LDAP integration happen during an OpenStack upgrade?
Usually keep them separate unless an upgrade window already exists and your team can test both changes. Combining them shares one change window but stacks two sources of risk. If logins fail, it becomes harder to tell whether the cause is the directory settings or the new release. OpenStack supports upgrades between SLURP releases and between adjacent releases, so plan the release path first, then decide where the Keystone change fits. For example, the 2026.1 Gazpacho release is a SLURP release that was published on 2026-04-01. A sequence of upgrade, verification, then integration is often easier to roll back. Ask the partner to show the order, the rollback step for each stage and the test that confirms each stage is complete.
How DeployOpen scopes, delivers and supports Keystone directory integration
DeployOpen plans and builds Keystone directory integration inside your own infrastructure, so OpenStack authenticates employees against your existing LDAP or Active Directory server. The work covers read-only identity back ends, per-domain configuration that keeps service accounts in SQL, and group-to-role assignment agreed with your access owners. Engagements are fixed-scope and documented in writing before work starts.
How we scope
- The written scope names your directory type, LDAP or Active Directory, and the Keystone release you run.
- It lists which domains authenticate against the directory and which keep service accounts in SQL.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Read-only bind accounts and directory search filters are configured and tested in a non-production environment first.
- Group-to-role assignment maps directory groups to Keystone roles and projects, reviewed with your access owners.
- Test cases cover login, denied users, disabled accounts and role results for each mapped group.
How we hand over
- Configuration is documented per domain, including which identities are read-only and where service accounts live.
- A limits register records what read-only LDAP cannot do, such as creating users or changing passwords in the directory.
- Your team receives runbooks for directory lookups, failed binds and rotating service account credentials.
How we support
- Ongoing support, upgrades and testing can run as a retainer after handover.
- Keystone upgrades are re-tested against directory login and group mappings before rollout.
- Directory changes such as renamed groups or new OUs are reviewed against role mappings before they take effect.
