Open-source alternative to PingDirectory: the short answer
The self-hosted candidates for replacing PingDirectory as the user store behind PingFederate or other applications are 389 Directory Server, OpenLDAP and FreeIPA, and the right one depends on what the directory serves. If the directory is a general LDAP store for several applications, 389 Directory Server is the closest match, with asynchronous multi-supplier replication and online schema and access control updates. If you also need Kerberos single sign-on, certificates and DNS for Linux and UNIX hosts, FreeIPA packages 389 Directory Server with those services. OpenLDAP suits teams that want a lean slapd server and can manage its configuration themselves. Decide this before any data moves, because the choice sets the operating model you will run for years.
The directory is usually the easiest component to move, because it holds entries and little application logic. The effort sits in three places: schema, replication and bind behavior. Attribute names, object classes and matching rules in your current directory must map to the target schema before entries are loaded, and applications that query custom attributes can fail quietly if a mapping is missed. Replication topology decides how many replicas you run and where writes land. Bind behavior, meaning how PingFederate and each application authenticate to the directory, which password hash schemes they accept and how account lockout is applied, decides whether cutover succeeds. Test a bind from every application against the new directory before you change any client configuration.
Check licenses and support before you choose. The 389 Directory Server code is licensed under GPLv3 and its documentation under CC BY-SA 4.0. OpenLDAP is available under the OpenLDAP Public License. FreeIPA is licensed under GPL-3.0-or-later and has no paid edition of its own, so any commercial support comes from a third party. Ask whoever will run the directory which releases they will patch, how quickly they apply security fixes and who owns the backup and restore runbook. DeployOpen plans, implements, hardens and documents these directories in your environment and runs security testing, but it does not issue audit reports, attestations or certifications. If an assessor needs evidence, the independent auditor decides what is sufficient.
Which open-source directory covers which PingDirectory capability
This table maps the main directory capabilities teams rely on in PingDirectory to 389 Directory Server, OpenLDAP and FreeIPA. Check marks show where the supplied facts confirm a capability, while dashes and text notes flag where you must test or confirm it yourself before committing to a platform.
| Capability | 389 Directory Server | OpenLDAP (slapd) | FreeIPA |
|---|---|---|---|
| LDAPv3 directory service | Yes | Yes | Uses 389 Directory Server as its LDAPv3 directory for users, groups, hosts and policies |
| TLS and SASL support | Yes | LDAPv3 with SASL and TLS, plus certificate authentication | Inherits 389 Directory Server LDAP security, with Kerberos as the main SSO path |
| Multi-supplier replication | Asynchronous multi-supplier replication, suited to fault tolerance and write performance | Multi-provider replication for environments where a single point of failure is not acceptable | Multi-master directory with replica topology limits in the deployment guidance |
| Online schema and ACI changes | Schema, configuration and ACIs changeable online with zero downtime | Confirm online change behavior for your schema and overlays in your own tests | Managed through IPA tooling; confirm which changes need restarts |
| Backup and tooling | dscreate, dsctl, dsconf, dsidm and a Cockpit console | LDIF tools and command line utilities; backup approach depends on your chosen backend | ipa-backup and ipa-restore; restoring an outdated backup into a live topology can break replication |
| Active Directory interoperability | Not applicable | Not applicable | Cross-forest trust with Active Directory via Samba components; IPA domain must not overlap AD DNS domains |
| Migration tooling from existing LDAP | openldap_to_ds converts OpenLDAP on a best-effort basis | Source for conversions; confirm entry and schema fidelity from other vendors | ipa migrate-ds imports users and groups; sudo and HBAC rules need manual LDIF migration |
| PingDirectory-specific features (password policies, proxying, custom plugins) | Not covered in the supplied facts; confirm with the vendor and your own tests | Not covered in the supplied facts; confirm overlays and proxy needs | Not covered in the supplied facts; confirm against your application requirements |
When 389 Directory Server, OpenLDAP or FreeIPA fits
PingDirectory is an LDAP store, so the replacement has to speak LDAP to PingFederate and your other apps. The three open-source options below differ less in protocol than in what they bundle around the directory, which decides how much of your identity stack you end up operating.
389 Directory Server as a standalone store
Choose 389 Directory Server when you need a dedicated LDAP store for a large account base and do not want Kerberos or DNS bundled in. It is licensed under GPLv3, with documentation under CC BY-SA 4.0. Its multi-supplier replication is asynchronous, so check your conflict handling and replication lag against your write patterns before cutover. Schema, configuration and ACIs can change online, which helps during rollout. Ask your team who will own the dsconf and dsidm tooling after the migration.
OpenLDAP as a lightweight slapd
OpenLDAP suits teams that want a small, well-understood slapd with the MDB backend and single-provider or multi-provider replication. It is released under the OpenLDAP Public License, a permissive license, which simplifies embedding in internal tooling. The trade-off is that you assemble more yourself: schema management, overlays, Kerberos integration and certificate issuance are separate projects. Confirm which OpenLDAP branch your support team will follow, since 2.7 is the feature release and 2.6 is the long term support line.
FreeIPA for Linux identity
Choose FreeIPA when the goal is Linux and UNIX identity, with Kerberos single sign-on, an integrated Dogtag certificate authority and DNS. It is GPL-3.0-or-later and has no paid edition, so the cost sits in the staff and support you buy for it. FreeIPA already runs 389 Directory Server underneath, so you get that directory without operating it separately, but you also take on its topology rules, such as dedicated replicas per datacenter. Check whether your PingFederate integrations need LDAP only or also Kerberos and certificates.
Replication model and failure behavior
Ping environments often treat the directory as a single source of truth for several applications, so replication design matters more than the server brand. 389 Directory Server uses multi-supplier replication, OpenLDAP offers single-provider and multi-provider modes, and FreeIPA manages replicas for you within its own rules. Map which applications write to the directory and which only read. Test what happens when one supplier fails during a password change, because that is where directory migrations usually surprise teams.
Schema and attribute compatibility
Each application expects specific object classes and attribute names, and PingDirectory deployments often carry custom schema added over years. Before choosing, export the schema and compare it with the candidate server's defaults. 389 Directory Server offers an openldap_to_ds tool that converts OpenLDAP data on a best-effort basis, which covers schema and some overlays but not everything. Treat conversion output as a starting point and validate each attribute against the application that reads it.
Operations and staffing
The licence cost of all three options is zero, so the comparison comes down to who operates the directory. Ask whether your platform team already runs LDAP tooling, whether you need a commercial support contract for the Linux distribution, and who handles backups and restores. FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore runbooks need to be written and rehearsed before go-live.
How schema and replication differ from PingDirectory
Before any entry moves, inventory every attribute name, object class, syntax and password policy that PingDirectory enforces today. Record which custom attributes PingFederate, your applications and your provisioning jobs read or write, and which are unused. Schema mismatches are the most common reason an import fails or silently drops data, so treat the inventory as the input to the new schema, not a by-product of the export. Confirm how each password policy setting (history, lockout, expiry and hash scheme) maps onto the candidate directory, because some settings will need to be rebuilt rather than copied.
On the directory side, 389 Directory Server can change schema, configuration and access controls online through LDAP operations, without a restart, so schema additions can be staged during the migration window. It uses asynchronous multi-supplier replication, which means writes can land on more than one server and then propagate, so conflicting edits to the same entry are resolved by the server rather than prevented. OpenLDAP offers multi-provider replication for environments where a single point of failure is not acceptable. Both designs trade write availability for the possibility of conflicts, so confirm how each handles a credential change or a deleted account that is edited on two nodes during a network partition.
FreeIPA, which uses 389 Directory Server internally, recommends at least two to three replicas in each datacenter and no more than four replication agreements per replica. Keep your own topology to a similarly small mesh unless testing shows otherwise. Build a test topology that mirrors your datacenters, induce a partition, make conflicting changes to a password and a group membership, and record what survives. Repeat the test after a restore from backup, since restoring an outdated backup into an active replica topology can break replication. Document the results as part of your cutover evidence.
Exporting PingDirectory entries as LDIF and loading them
This sequence turns PingDirectory's users, groups and service accounts into a tested LDIF set, loaded into a test directory and verified against application binds before any cutover.
Inventory object classes, attributes and bind accounts
The directory owner and the administrators of each application that binds to PingDirectory list the object classes in use, the attributes each application reads or writes, and every bind user and service account with its purpose. Include the search base DNs, group structures and any custom schema extensions. Confirm with Ping, in the documentation for your PingDirectory version or through your support channel, which export formats and tools your edition supports. The step is done when the inventory is signed off by each application owner and every attribute has a named consumer or is marked for removal.
Confirm what password hashes can leave PingDirectory
Before any export runs, the identity team asks Ping in writing whether password hashes can be exported from your PingDirectory deployment, in which format, and under what conditions. Do not assume they transfer. If hashes cannot be exported, plan for users to reset passwords or for applications to federate authentication to the new directory while credentials are migrated over time. Record the answer in the migration decision log. The step is done when the written answer is on file and the cutover plan reflects it.
Export entries as LDIF using the vendor's supported method
The PingDirectory administrator exports the base DNs in scope using the export method Ping documents for the installed version, writing LDIF files per branch. Keep the export on an encrypted, access-controlled volume and log who ran it. Strip or transform attributes as the inventory dictates: remove password hashes if Ping confirmed they cannot be used, drop operational attributes that the target server will regenerate, and exclude service account entries that will be recreated. Keep the original export untouched as the source of record. The step is done when each branch has an LDIF file and a count of entries that matches the source.
Load LDIF into a test instance
The platform engineer prepares a test instance of the chosen server, such as 389 Directory Server, OpenLDAP or FreeIPA, with the same schema extensions identified in the inventory. For 389 Directory Server, the dsconf and dsidm tools handle schema and suffix setup, and LDIF can be imported with the server's import tooling for the chosen version. For OpenLDAP, use the LDIF tools that ship with the release. Record any entries rejected for schema violations, fix the mapping, and reload from the untouched source export. The step is done when the test load completes with no unresolved rejections.
Validate counts, group membership and application binds
Compare entry counts per branch between the source export and the test instance. Check that group membership matches for a sample of groups and for every group that controls application access. Then have each application owner test binds with the migrated service accounts and a set of pilot user accounts, including the password path if hashes were migrated, and confirm each attribute the application reads is present and correctly formatted. Log every mismatch with its owner and resolution. The step is done when counts match, group checks pass and each application completes a successful bind and attribute read in the test environment.
Plan the cutover and a rollback path
The team agrees a cutover sequence with each application owner, covering the order of repointing LDAP URLs, the freeze on changes in PingDirectory during the final export, and the reconciliation of changes made after the export. Define the rollback step explicitly: which application configurations revert, how the original PingDirectory remains available, and who decides to roll back. Rehearse the sequence against the test instance. The step is done when the runbook is approved and the rollback has been rehearsed.
Cut over and keep PingDirectory available for rollback
On the agreed window, the team freezes writes to PingDirectory, runs the final LDIF export, loads it into the production target, and repoints applications one at a time while monitoring bind failures and login rates. Leave PingDirectory running and read-only for the rollback period agreed in the runbook. Reconcile any changes made during cutover. The step is done when every application authenticates against the new directory, error rates return to baseline, and the rollback window closes with a signed record of the result.
Questions teams ask before moving PingDirectory
How much effort does moving off PingDirectory take?
The effort depends mostly on how many applications bind to the directory, how complex the schema is, and how replication is arranged today. A single directory feeding one or two applications is a contained project. Each additional application adds bind credentials, attribute mappings, group logic and test cases that must be verified before cutover. Password hash handling is a separate workstream: you need to confirm whether the existing hashes can be exported and whether the target directory and applications accept the same hash schemes. Ask any implementation partner to break the estimate into schema mapping, application changes, replication design, data migration and parallel running, and to state which of those parts it assumes you will staff.
Can our team move PingDirectory to 389 Directory Server alone?
A team with solid LDAP skills can usually handle a small directory on its own, especially when the user base is modest and the applications are few and well documented. 389 Directory Server has command line tools (dsconf, dsidm, dscreate and dsctl) and a Cockpit web console, and it ships an openldap_to_ds converter for OpenLDAP sources. Multi-app estates are harder. Each application team must confirm its bind method, attribute expectations and group membership model, and someone must own replication, backups and TLS certificates after go-live. If nobody on the team has run an LDAP directory in production, plan for outside help with the design and first cutover.
What do we need to provide before the migration starts?
Three inputs decide whether the project stays on schedule. First, a schema inventory: every custom object class and attribute, the syntax of each, and which applications read or write it. Second, named application owners who can state how each app authenticates, what it caches, and who must sign off on its test results. Third, test windows that match your change calendar, with a rollback plan for each cutover. You should also collect the replication topology, the list of service accounts, and the export format each system can produce. Entries are typically moved as LDIF, so confirm early that the source export preserves the attributes your applications need.
Can FreeIPA replace PingDirectory for applications that do not run on Linux?
FreeIPA can serve non-Linux applications, but it is not a general LDAP directory for every workload. FreeIPA uses 389 Directory Server as its multi-master LDAPv3 directory and adds MIT Kerberos, the Dogtag certificate system and DNS, so applications that accept LDAP bind, Kerberos or certificate-based login can use it. Windows and macOS clients join through standard protocols and can be integrated with an Active Directory trust. Applications that expect a custom schema or Ping-specific attributes will need schema changes or an intermediate mapping layer. Confirm each application's authentication method against FreeIPA's supported protocols before you commit, and treat FreeIPA as an identity platform with its own operating model rather than a drop-in directory.
How do the cost components split between software, infrastructure, migration and operations?
The software itself is the smallest line item. 389 Directory Server is GPLv3 and FreeIPA is GPL-3.0-or-later, and OpenLDAP is available under the OpenLDAP Public License, so no license fee applies to the directory. The recurring costs sit elsewhere: servers or virtual machines for at least two or three replicas per datacenter (as FreeIPA's deployment recommendations advise), backup storage, monitoring, and staff time for patching and certificate renewal. Migration is mostly one-time: schema mapping, application changes, testing and parallel running. Ask any partner to quote each of these separately, and to state whether support contracts for the directory or operating system are included or optional.
Will password hashes and credentials survive the export?
Not automatically, and you should confirm this before scoping. An LDIF export of entries may carry hashed passwords, but whether they can be read, which scheme they use, and whether the target directory and each application accept that scheme all need checking. Some applications will not accept a hash they cannot verify, which can force password resets for those users. Plan for how you will handle users who must reset credentials, and confirm that service account passwords are rotated and stored in a secrets manager during cutover. Keep the export files encrypted and access-controlled, because they contain identity data.
How do replication and rollback work during cutover?
Plan replication as a design decision, not a copy step. 389 Directory Server provides asynchronous multi-supplier replication, and OpenLDAP offers single-provider and multi-provider replication. Run the old and new directories in parallel for a defined period, with a clear owner for which system is authoritative for writes at each stage. Rollback requires that you can point applications back to PingDirectory without losing changes made in the new directory. Test this path in a non-production window, and record the steps and timings before you schedule production cutover.
What should we test before we switch applications to the new directory?
Test authentication and authorization for every application, not only the directory itself. For each app, verify the bind account, the search base and filter, the attributes it reads and writes, and how group membership maps to roles. Include failure cases: expired passwords, locked accounts, a replica going offline, and certificate validation over TLS. Run the tests with real application owners in a test window, and keep a signed record of results for your change board. The directory tests alone do not prove that an application behaves the same way.
Running the new directory beside PingFederate and other apps
A directory cutover rarely happens in one step. PingFederate and every application that binds to PingDirectory need a defined path for the period when both directories hold data. The cards below cover the risks that appear during that window and the checks that keep it controlled.
Freeze PingDirectory as read-only
Once the new directory holds a full copy, writes to PingDirectory must stop or be routed deliberately. If two directories accept changes for the same users, password resets, group memberships and account lockouts will diverge quickly. Confirm with each application team which write paths exist, such as self-service password changes or provisioning jobs, and decide whether each one is disabled, redirected or replayed. Keep the read-only state documented so it can be reversed if the cutover is rolled back.
Test the PingFederate data store
Point PingFederate's data store at the new directory in a test environment before any production change. Check that the bind account, search base, attribute names and group lookups return what the attribute contract expects, since 389 Directory Server and OpenLDAP may name or structure attributes differently from PingDirectory. Run a sample of real authentication flows, including password policy responses, and record every difference. Confirm the exact configuration steps with your PingFederate version and the directory vendor's documentation.
Inventory apps that bind directly
Some applications connect to the directory over LDAP without going through PingFederate, using service accounts, hard-coded hostnames or local configuration files. These connections are easy to miss because they do not appear in the federation configuration. Build a list from firewall logs, LDAP access logs on the old server and application configuration reviews, then record the bind DN, TLS settings and search filters for each one. Each entry needs an owner who signs off on the new endpoint and on a rollback plan.
Keycloak LDAP federation as a bridge
Keycloak can federate with an existing LDAP server, which lets it authenticate users whose accounts remain in the old directory while applications move to Keycloak. This bridge pattern reduces how many systems must change on the same day. Keep the federation read-only or import-on-demand until the directory migration is complete, and test how Keycloak maps the directory's attributes and password checks. Keep in mind that the bridge adds a dependency on the directory during the transition, so monitor its availability.
FreeIPA trusts with Active Directory
If users or services still depend on Microsoft Active Directory, FreeIPA can establish a cross-forest trust with it through Samba components, so AD users can reach FreeIPA resources without duplicate accounts. The IPA domain must use a DNS name that does not overlap with any domain in the AD forest, which is a planning decision to make before installation. Confirm the trust design, name resolution and the supported forest topology in the FreeIPA trust documentation before relying on it for production access.
What the directory migration costs by component
The software licence line is the smallest variable in this migration. 389 Directory Server is GPLv3 and OpenLDAP is available under the OpenLDAP Public License, so neither carries a licence fee, and FreeIPA is GPL-3.0-or-later with no paid edition of its own. Some vendors sell paid support for these projects, so ask any implementation partner or support provider to state whether support is included in the quote, what it covers and whether it is priced per server, per node or per year. Your own PingDirectory licence and maintenance terms are the baseline to compare against, and your renewal paperwork is the place to confirm what they include.
The larger costs are labor and infrastructure, and they fall into two groups. One-time work includes replication design, schema and data migration, rebuilding ACIs or access rules, converting entries with LDIF exports and the openldap_to_ds tool where OpenLDAP is the source, and re-testing every application that binds to the directory. Re-testing is often the biggest item because each bind, search and group lookup path must be checked against the new server. Recurring work includes patching, monitoring, backups with dsctl or ipa-backup, and staff time for on-call and directory changes. Ask each bidder to price these as separate line items so you can see which costs fall away after cutover and which continue.
Infrastructure cost depends on topology. FreeIPA's deployment recommendations call for at least two to three replicas in each datacenter, dedicated servers and at least one replica per datacenter running PKI or DNS if you use them, so a highly available design means more servers than a single-instance PingDirectory test system. The quote should state the replica count per site, the hardware or virtual machines assumed, the replication topology, the backup target and retention, and who owns the monitoring stack. Confirm these assumptions against your own environment before comparing totals, because the number of replicas and sites is what most often changes the recurring cost.
How DeployOpen scopes and delivers a directory replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move off PingDirectory, that means agreeing a written scope for the directory, its consumers and its replication topology before any entries are moved.
How we scope
- Inventory every application and PingFederate connection that binds to the PingDirectory user store today.
- Agree in writing whether 389 Directory Server, OpenLDAP or FreeIPA fits the identity and replication requirements.
- Record schema attributes, password policy and replication topology as named deliverables before work starts.
How we build
- Export entries from PingDirectory as LDIF and map attributes and object classes to the target schema.
- Build replication, TLS and access controls, then test bind behavior for each dependent application.
- Run a timed test migration in a non-production environment and document every attribute that did not carry over.
How we hand over
- Deliver runbooks for backup, restore, replica addition and schema change on the chosen directory.
- Document cutover steps, rollback criteria and the evidence captured at each stage of the migration.
- Provide compliance-ready control descriptions for your assessors, noting that independent auditors issue any formal reports.
How we support
- Fixed-scope engagements have deliverables and timelines agreed in writing before work begins.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask for the written scope to show which items are one-time work and which recur under a retainer.
