When to choose OpenLDAP or Active Directory
Choose OpenLDAP when the central directory serves mostly Linux hosts and LDAP-only applications, you do not need a Windows domain, and your team is prepared to operate slapd as a service it owns. OpenLDAP is an LDAPv3 directory server under the OpenLDAP Public License, and it authenticates clients through SASL and TLS certificates. It is a directory and nothing more: it does not provide Kerberos, Group Policy or Windows domain join, so those needs must be met by other systems. Fit improves when applications bind with simple or SASL authentication and do not expect Windows-integrated (NTLM or Kerberos) sign-on. Choose Active Directory when Windows desktops and servers must join a domain, Group Policy must configure them, and users expect Kerberos-based Windows single sign-on. Active Directory Domain Services also replicates directory data to every domain controller and provides a schema and global catalog, which is why most Windows-centric estates already run it. Microsoft notes that Linux machines need third-party tools or must be configured to authenticate against Active Directory as a Kerberos realm, so a Linux-heavy estate pays an integration cost that OpenLDAP does not impose.
Check the cost of each option against your own license position rather than against list prices alone. Windows Server 2025 is licensed per core with a minimum of 16 cores per server, and both Standard and Datacenter editions require a Windows Server Client Access License for every user or device that accesses the server. Microsoft's pricing page gives suggested prices and notes they vary by region, so ask your Microsoft reseller for the quote that matches your core count, client count and existing agreements. OpenLDAP has no license fee, but its costs are staff time, hosting, replication design, backups and an upgrade plan. Confirm the OpenLDAP release line you will run: the current feature release is 2.7.1 and the long term support line is 2.6.15, according to the OpenLDAP website.
The decision turns on three questions. First, which clients must bind directly to the directory, and do they speak plain LDAP or require Kerberos or NTLM? Second, will Windows devices be domain joined and managed with Group Policy, which settles the question for most organizations. Third, who will run the service after go-live, including patching, certificate renewal, replication monitoring and recovery? If the answer to the second question is yes, keep Active Directory as the authoritative source and connect Linux and application clients to it. If the answer is no and the team has directory operations skills, OpenLDAP is a credible central choice. Where Windows and Linux both need central identity, a mixed estate may keep both, with a documented source of truth for each identity.
Which directory fits which scenario
This table matches common estate shapes to the directory that fits each one, based on domain join, Group Policy, Kerberos and LDAP support. Read each row as a starting point: the better fit depends on which clients and applications must authenticate, and the cells name the condition under which each option wins.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Linux-only estate with LDAP-aware applications | OpenLDAP | slapd implements LDAPv3 with SASL and TLS certificate authentication, so applications that bind to LDAP can use it directly. Confirm each application's SASL and TLS support before committing. |
| Windows desktop fleet managed with Group Policy | Active Directory | Active Directory lets administrators domain-join Windows devices and manage desktops and servers with Group Policy. OpenLDAP provides no domain join or Group Policy for Windows clients. |
| Application backends that speak LDAP only | OpenLDAP | Any application that needs a simple bind and search against an LDAP tree can point at slapd. Active Directory also answers LDAP, so choose by what else the estate needs, such as Kerberos or Windows integration. |
| Linux servers that must sign in with Kerberos | Active Directory or FreeIPA | Microsoft notes that Linux machines can authenticate against Active Directory as a Kerberos realm, usually with third-party tools or manual configuration. OpenLDAP does not provide a Kerberos KDC, so Kerberos needs a separate service. |
| Mixed estate with Windows and Linux users | Active Directory as the source, with Linux integration | Keeping Active Directory as the identity source avoids a second user store for Windows clients. Confirm the Linux join method your team will support before deciding whether OpenLDAP is still needed. |
| SaaS sign-on for cloud applications | Neither alone | Microsoft notes that Active Directory needs a federation system such as AD FS for SaaS apps, and OpenLDAP is not an SSO server. Plan an identity provider or federation layer for SaaS, whichever directory sits behind it. |
| Replication across sites with no single point of failure | Active Directory | Active Directory replicates directory data to every domain controller in a domain. slapd supports multi-provider replication, but the design must be built and tested by your team. |
How OpenLDAP and Active Directory are built
OpenLDAP and Active Directory both store directory objects and answer LDAP queries, but they arrive there from different directions. One is a stand-alone directory server you assemble around; the other is a Windows Server role tied to a domain, its replication and its operating system lifecycle. The cards below cover the parts that shape day-to-day operations.
slapd as a stand-alone server
slapd is OpenLDAP's LDAPv3 directory server. It runs on Linux and other Unix-like systems without a Windows dependency, implements LDAPv3 over IPv4, IPv6 and Unix IPC, and uses the MDB backend, a transactional store built on LMDB. Operations teams patch slapd as an application package on their own schedule. Check which backend, overlays and schema your applications expect before you commit, because those choices are part of the server configuration you must maintain.
Replication design in slapd
slapd supports single-provider with multiple consumers and multi-provider replication, the latter for environments where a single point of failure is not acceptable. You design the topology yourself, including which servers accept writes and how consumers are kept in sync. Ask who will own replication monitoring and conflict handling, and test failover before relying on it. Active Directory replicates across its domain controllers as a built-in function, so the design work is different in kind.
lloadd as a load balancing proxy
lloadd is the stand-alone LDAP load balancing proxy shipped with OpenLDAP 2.7. It sits in front of directory servers so that client connections spread across backends or fail over when one is unavailable. It is a separate component to install, configure and monitor, not a feature of the directory itself. Confirm that your applications handle the proxy's behavior with their own bind and referral settings before placing it in the authentication path.
AD DS as a Windows Server role
Active Directory Domain Services is installed as a role on Windows Server. It stores users, computers and other objects, and it replicates directory data to every domain controller in a domain. Patching, promotion of domain controllers and schema changes follow Windows Server processes, so the directory's upkeep is tied to the server operating system. Plan for the Windows Server lifecycle as part of the directory's lifecycle, not as a separate concern.
Schema, global catalog and query indexing
AD DS provides a schema, a global catalog and a query and index mechanism as part of the role. Applications that need forest-wide lookups use the global catalog, while schema changes affect every domain controller. OpenLDAP has no equivalent built-in global catalog, so cross-domain lookups must be designed through directory structure, referrals or application logic. Ask which lookups your applications run and whether they depend on forest-wide searches.
Windows Server licensing and support windows
Windows Server 2025 became available on November 1, 2024, with mainstream support ending November 14, 2029 and extended support ending November 15, 2034, according to Microsoft's lifecycle page. Windows Server 2022 mainstream support ended on October 14, 2026 and extended support ends on October 15, 2031. Windows Server 2025 is licensed per core with a minimum of 16 cores per server, and every user or device accessing the server needs a Client Access License. Get the license count and support dates from your Microsoft agreement before budgeting.
Capability comparison: LDAP, Kerberos, Group Policy and domain join
This table sets OpenLDAP's directory-only scope against what Active Directory Domain Services bundles in, row by row. Read each row as a question to ask your own estate: if you need a capability in the Active Directory column, OpenLDAP alone will not supply it and you will need additional components.
| Capability | OpenLDAP | Active Directory |
|---|---|---|
| LDAPv3 directory server | slapd implements LDAPv3 over IPv4, IPv6 and Unix IPC, with SASL and TLS certificate authentication | Active Directory Domain Services is a Windows Server role that stores users, computers and other objects |
| Kerberos realm | Not part of OpenLDAP. Kerberos needs a separate KDC, so confirm the design with your own Kerberos setup | Domain controllers act as the Kerberos realm, and most on-premises apps use Kerberos through Windows-integrated authentication |
| Windows domain join | Not provided. Windows devices cannot join an OpenLDAP directory as a domain | Administrators can domain-join Windows devices and servers directly to the domain |
| Group Policy management | Not provided. Configuration management for Windows endpoints needs other tooling | Group Policy manages Windows desktops and servers from the directory |
| Linux authentication | Linux hosts authenticate through LDAP-aware PAM and NSS configuration, which you must build and test yourself | Linux machines need third-party tools or must be set up to use Active Directory as a Kerberos realm |
| Replication model | Single-provider with multiple consumers, plus multi-provider replication where a single point of failure is not acceptable | Replicates directory data to every domain controller in a domain |
| Schema and global catalog | Schema is configured on the server, and OpenLDAP does not provide a global catalog | Provides a schema and a global catalog across the forest |
| SaaS federation | Not provided by the directory itself. Pair it with a federation or identity provider such as Keycloak | Needs a federation system such as AD FS for SaaS apps, or Microsoft Entra Connect to sync to Entra ID |
What Windows Server licensing costs compared with OpenLDAP
OpenLDAP Software is available under the OpenLDAP Public License, which the project describes as a non-restrictive, free, open-source license. The software itself carries no license fee, and the project does not publish a paid edition in the facts supplied for this page. Your recurring costs are the servers, storage, backup, and the staff time to run the directory, plus any outside support you choose to buy from a vendor or consultant.
- No license line item: Installing and running slapd does not create a per-core, per-server, or per-user license charge.
- Hardware and hosting: Servers, virtual machines, storage, and network capacity are your costs, and they scale with your replication topology.
- Operating staff: Directory administration, schema changes, and certificate handling are internal labor unless you contract them out.
- Support is optional: Any paid support comes from a third party under a separate agreement, so ask whether a quote includes it.
- Upgrade effort: Moving between the 2.6 LTS line and the 2.7 feature line is planned work, with testing time that is not a license cost.
Before you build a budget, confirm with your legal or procurement team how the OpenLDAP Public License applies to your redistribution and bundling model.
Active Directory Domain Services runs as a role on Windows Server, so the directory cost sits inside the server license. Microsoft's Windows Server 2025 pricing page states that the product is licensed per core, with a minimum of 16 cores per server and 8 cores per processor. Both Standard and Datacenter editions also require a Windows Server Client Access License for every user or device that accesses the server, which adds a second cost layer that scales with your user count.
- Per-core base: Every physical server that runs domain controllers needs core licenses, and the 16-core minimum applies even to small servers.
- Per-user or per-device CAL: Each user or device that authenticates to the server needs a Client Access License, which grows with headcount.
- Edition choice: Standard and Datacenter carry different suggested prices, so the edition decision affects the base cost.
- Domain controller count: Redundancy requires more than one domain controller, and each one carries its own core licensing.
- Lifecycle dates: Windows Server 2025 mainstream support ends November 14, 2029 and extended support ends November 15, 2034, per Microsoft's lifecycle page.
Confirm with Microsoft or a licensed reseller how your core count, CAL mix, and any existing Software Assurance or subscription rights apply to your environment.
Microsoft's Windows Server 2025 pricing page lists a suggested price of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter, both for 16 core licenses. Microsoft attributes these as suggested figures and notes that prices vary by region. These are list prices before any volume discount, reseller margin, tax, or agreement terms, so they do not show what your organization will pay.
- Standard list price: Microsoft's suggested price for 16 Standard core licenses is 1,176 US dollars.
- Datacenter list price: Microsoft's suggested price for 16 Datacenter core licenses is 6,771 US dollars.
- Multiple servers: Each physical server needs at least 16 core licenses, so cost multiplies with the number of hosts, not the number of directory services.
- CALs are separate: The list prices above do not include the Client Access Licenses that each user or device needs.
- Regional variation: Local currency and tax rules change the figures, so confirm the figure for your country.
Ask Microsoft or your reseller for a written quote that shows the core count, edition, CAL quantity, discount level, and any tax or currency conversion.
Microsoft's pricing page also offers pay-as-you-go licensing through Azure Arc at 33.58 US dollars per core per month. This model replaces a perpetual purchase with a recurring charge tied to cores under Arc management, which changes how you budget and how you exit. The page presents this as a published rate, but the terms, billing unit, and eligibility depend on your agreement, so verify them before you rely on the figure.
- Recurring charge: At the published rate, cost accrues monthly for each core, so long-running servers accumulate cost over time.
- Break-even depends on term: Compare the monthly figure against the purchase price over the period you plan to run the servers.
- Azure dependency: Arc billing requires an Azure subscription and connection, which adds a governance and cost-tracking task.
- Core counting rules: Confirm how Microsoft counts cores for billing, including the 16-core minimum per server.
- Regional and currency terms: The rate is shown in US dollars, so confirm the currency and any regional variation for your billing entity.
Ask Microsoft whether pay-as-you-go applies to Active Directory domain controllers in your scenario, and request the billing unit, minimum terms, and cancellation rules in writing.
What drives the running cost of each directory
The license line is only part of what each directory costs to run. Server licensing and client access licenses on the Active Directory side, and hosting, patching and staff time on the OpenLDAP side, shape the total, and the same operational work recurs on both. The cards below separate the one-time items from the recurring ones and list what to request in a written quote.
Windows Server licensing and CALs
Active Directory domain controllers run on Windows Server, which Microsoft licenses per core with a minimum of 16 cores per server and 8 per processor. Both Standard and Datacenter editions also need a Windows Server Client Access License for every user or device that accesses the server. Ask the reseller or licensing advisor to price the domain controller count, core count per host, and CAL position for your user and device population, including any licensing for other servers that consume directory services.
Hosting and patching the directory
An OpenLDAP deployment carries no per-server license fee, so its recurring cost is infrastructure and operations: virtual machines or containers, storage, backup targets, and the patch cycle for slapd and the operating system beneath it. Active Directory has the same hosting and patching work for its domain controllers, plus Windows Server update management. Ask for the number of directory nodes in each design and who owns patch testing and rollback.
Staff skills and on-call coverage
Most Windows-centric teams already run Active Directory daily, so the skills cost is mainly cross-training for Linux-side identity work. An OpenLDAP estate needs people who can write and debug LDAP schemas, ACLs, overlays and replication settings. Estimate the staffing gap in your own organization, then ask any implementation partner to state which roles are included in the scope and which stay with your team after handover.
Support subscriptions and vendor terms
OpenLDAP is free under the OpenLDAP Public License, and its support comes from a commercial provider, community channels or your own staff. Microsoft support for Windows Server and Active Directory is tied to the product support terms in your agreement. Ask each supplier what support tiers exist, what response times they commit to in writing, and whether the price is per server, per core, or per engagement.
Upgrade windows and lifecycle dates
Each platform recurs a major upgrade cost on its own schedule. Windows Server 2025 has mainstream support until November 14, 2029 and extended support until November 15, 2034, while Windows Server 2022 moves through its lifecycle with mainstream support already ended. For OpenLDAP, compare the 2.6 LTS line with the 2.7 feature release when planning. Build the upgrade calendar into the quote so the cost of a forced platform move is not a surprise.
Replication, backup and monitoring build
Both designs need replica sites, tested backups and monitoring for replication lag and authentication failures. Active Directory replicates to every domain controller in a domain by design, so the replication topology is largely built in. With OpenLDAP, you choose and build single-provider, multiple-consumer or multi-provider replication, backup tooling and alerting yourself. Ask for the one-time build effort for each of these items, separately from the recurring run effort.
Moving from OpenLDAP to Active Directory or the reverse
This sequence moves directory-backed authentication from one server to the other without a single cutover event. It produces an inventory of every bind, a schema map, a tested credential plan and a parallel directory that clients move onto one group at a time before the old service is retired.
Inventory every LDAP client and bind pattern
The directory team, with application owners, lists every system that queries or authenticates against OpenLDAP. For each one, record the bind account, whether it uses simple bind over TLS, SASL or Kerberos, which base DNs and filters it uses, and whether it writes back to the directory. Microsoft's comparison notes that most on-premises apps authenticate against Active Directory with LDAP, Windows-integrated authentication or header-based authentication, so expect a mix. The step is done when every client has a row in the inventory and each row has an owner who has confirmed it.
Map schema and object classes
Compare the OpenLDAP schema, including any custom attributes and object classes, with the Active Directory schema and its global catalog. Decide which attributes map directly, which need a new name, and which have no equivalent and must be stored elsewhere. Note that Active Directory stores computers, groups and Windows-specific objects that OpenLDAP does not model by default, so group semantics and nested membership may need redesign. The step is done when a written mapping table is reviewed by the application owners and every client attribute in the inventory resolves to a target.
Plan password and credential handling
Identify how passwords are stored and checked today, including hash schemes in OpenLDAP and any applications that read password hashes directly. Active Directory does not expose password hashes in the same way, so confirm with Microsoft documentation and your own testing which clients can still authenticate after migration. Plan how users set or reset credentials during the transition and whether Kerberos keys must be generated for Windows-integrated or Linux Kerberos clients. The step is done when a credential approach is signed off by security, and a test account has authenticated successfully from each client type.
Rebuild Kerberos, Group Policy and domain join separately
These items do not transfer from OpenLDAP and must be designed as new work. Active Directory provides Kerberos, Group Policy and Windows domain join as part of AD DS, while Linux machines need third-party tools or must be configured to authenticate against Active Directory as a Kerberos realm. If Linux hosts must use Kerberos against the new directory, plan the realm, keytabs and host enrollment, and confirm the approach with Microsoft and your Linux distribution's documentation. The step is done when a test Windows device joins the domain, receives its policy and a test Linux host authenticates through the agreed method.
Run both directories in parallel
Populate the new directory from the authoritative source, keep it in sync for a defined window, and point a non-production group of clients at it first. Compare authentication results, group membership and attribute values between the two directories for the same test identities. Where you plan to use Microsoft Entra Connect for a hybrid model, confirm its sync scope and behavior in Microsoft's documentation before relying on it. The step is done when test results match for every client group and discrepancies are logged with owners and fixes.
Cut over clients in groups
Move clients to the new directory in small groups, starting with the lowest-risk applications. For each group, change the bind DN, server address, TLS settings and search base in the application configuration, then run the agreed login and read or write tests. Keep a documented rollback path to OpenLDAP for each group until the group has run normally through a full business cycle. The step is done when every client in the inventory is recorded as moved, tested and signed off by its owner.
Retire the old service with evidence
Once all clients are moved, stop writes to OpenLDAP, take a final verified backup, and record which configuration, LDIF exports and audit logs are retained under your records policy. Remove client references, revoke old bind accounts and confirm no traffic reaches the old server in monitoring. Ask your compliance lead which retention evidence the relevant framework expects before decommissioning. The step is done when monitoring shows zero client traffic for the agreed period and the retention record is approved.
When a mixed estate keeps both directories
Keeping OpenLDAP alongside Active Directory makes sense when the Windows domain and the Linux or application directory have different owners, trust boundaries or change rates. Common cases include Linux application backends that need a simple LDAP bind and search, a separate trust zone such as a perimeter network or a regulated enclave, and a Windows domain that should not hold application service accounts. Before deciding, check which applications can already query Active Directory over LDAP. Microsoft's comparison notes that most on-premises apps authenticate against Active Directory with LDAP, Windows-integrated authentication or header-based authentication, so some apps may not need a second store at all. Record each consumer and the store it binds to.
Two directories create a synchronization problem that someone must own. Decide which system is the source of truth for each attribute, how a disabled Windows account propagates to OpenLDAP, and what happens during a sync outage. Microsoft Entra Connect synchronizes Active Directory to Entra ID, not to OpenLDAP, so an OpenLDAP path needs its own tooling or an identity governance layer. midPoint can provision accounts into target systems, but Evolveum states it is not an authentication server or SSO server, so it complements a directory rather than replacing one. Keycloak can federate users from LDAP or Active Directory for applications, which gives a read path but does not settle who approves access. Budget for the recurring cost of maintaining these flows and for access reviews across both stores.
FreeIPA is one option to test before building a second directory. FreeIPA can establish a cross-forest trust with an Active Directory domain on Windows Server 2008 R2 or later, so Active Directory users can reach Linux resources without a separate copy of their accounts. This removes some synchronization work but adds a Kerberos trust and a Linux identity platform to operate. Confirm in your own environment that your domain functional levels, DNS design, and the application protocols in use all work with a cross-forest trust, and run a pilot against a non-production application before committing. The FreeIPA Active Directory trust setup guide is the place to start that check.
Questions buyers ask before choosing a central directory
Can OpenLDAP replace Active Directory for Windows clients?
Not as a direct swap. OpenLDAP is an LDAPv3 directory server, and slapd gives you LDAP, SASL and TLS certificate authentication, but Microsoft's comparison notes that Active Directory also provides domain join and Group Policy for Windows devices, and Windows-integrated authentication through NTLM and Kerberos. Replacing those features means relying on third-party tools or a different Windows management model, which you should test against your own desktop and server build process. Confirm with your Windows administrators which of these functions your estate actually depends on before deciding.
What licensing costs drive the directory decision?
The main recurring cost difference is on the Microsoft side. Windows Server 2025 is licensed per core, with a minimum of 16 cores per server and 8 per processor, and Standard and Datacenter editions both need a Windows Server Client Access License for every user or device that accesses the server. Microsoft's pricing page lists suggested prices of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter for 16 core licenses, and prices vary by region. OpenLDAP is licensed under the OpenLDAP Public License, so the software itself carries no license fee; your costs are the servers, the staff who run them and any support contract you choose. Ask for your own Windows licensing count from your Microsoft partner or reseller.
How long does a directory migration take, and what drives that?
No supplied fact gives a migration duration, so treat any number you hear as unverified. The main drivers are the number of applications that bind to the directory, how many of them use hard-coded schema or attribute names, how Windows devices are joined and managed, and whether you run a hybrid period with Microsoft Entra Connect syncing identities. Each application that authenticates against the directory needs its own test cycle. Ask any implementation partner for a written scope that lists the applications, devices and authentication paths included, and a timeline tied to those deliverables.
Can our team run OpenLDAP ourselves?
It depends on the skills you already have. Running slapd well means managing schema, access control, replication topology, TLS certificates and backups, and deciding how a multi-provider design behaves during a network partition. Teams that already operate Linux directories and LDAP-aware applications usually find the work manageable, while teams whose experience is mostly Windows domain administration will need training or outside help. Before committing, list who will own each area, who is on call and how you will test restores.
Does Kerberos single sign-on need Active Directory?
No, but it needs a Kerberos realm. Microsoft's comparison notes that Linux machines can authenticate against Active Directory as a Kerberos realm, which is one option. FreeIPA is a separate open-source platform that combines a 389 Directory Server LDAP directory, an MIT Kerberos KDC and a Dogtag certificate authority, and it can establish a cross-forest trust with an Active Directory domain on Windows Server 2008 R2 or later so AD users reach Linux resources. If your need is Linux single sign-on plus Windows users, evaluate that path alongside a plain OpenLDAP design. Confirm the trust configuration against the FreeIPA setup guide for your Windows Server version.
When does an outside partner help with a directory project?
A partner helps most when the scope crosses several teams, such as Windows administration, Linux operations, application owners and audit. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any attestations. Ask for a written scope that names the directory services, applications, backup tests and handover documents included.
Can a mixed estate keep both directories?
Yes, and many estates do. Active Directory can remain the source of truth for Windows devices and Group Policy, while OpenLDAP serves Linux hosts and LDAP-bound applications, with identities synchronized or federated between them. The cost is ongoing: two directories mean two sets of schema changes, two backup regimes and clear rules about which system owns each attribute. Microsoft's comparison notes that existing Active Directory organizations use Microsoft Entra Connect to sync identities to Microsoft Entra ID, which is a separate cloud path to evaluate. Write down the owner of each identity attribute before you build the sync.
How DeployOpen helps choose and implement a central directory
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For OpenLDAP vs Active Directory, we start by working out which directory your Linux, application and Windows dependencies actually need, then build and hand over only the pieces that fit that answer.
How we scope
- Inventory which applications bind over LDAP, which need Kerberos, and which depend on Group Policy or domain join.
- Map Windows device management and Linux login needs to the options each directory actually provides.
- Agree deliverables, timelines and responsibilities in writing before any work begins, since engagements are fixed-scope.
- Confirm current OpenLDAP and Windows Server licensing and support windows with the vendors before the scope is signed.
How we build
- Deploy slapd or the chosen directory inside your cloud accounts, data centers or air-gapped network.
- Configure TLS, SASL authentication, replication topology and backups to the agreed design.
- Integrate applications, Linux hosts and any Active Directory trust or sync path, testing each login flow.
- Run security testing against the directory and its integrations before go-live, and record the results.
How we hand over
- Document the directory schema, access controls, replication design and every integration point.
- Deliver runbooks for account lifecycle, password and certificate changes, backup restores and upgrades.
- Walk your operations and identity teams through the handover so they can run the directory without us.
- Provide compliance-ready evidence of controls where your assessors need it, without issuing any attestation.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan directory upgrades against the OpenLDAP release line and Windows Server lifecycle dates you run on.
- Review integrations and access controls when applications or identity policies change.
- Agree retainer scope and response expectations in writing, with the quote following from that scope.
