When a FreeIPA hidden replica fits your topology
A FreeIPA hidden replica is an IdM server that runs every service it would normally run but is kept out of service discovery, so clients never pick it. Use one when you need a server for backups, bulk jobs or staged maintenance and do not want clients to start using it while that work is in progress. The server holds a full copy of the directory, so it can take on work that would otherwise load a production replica, but it stays invisible to the rest of the topology.
Hiding works by omission. A hidden replica has no DNS SRV records and no enabled LDAP server roles, so IPA clients and SSSD ignore it. According to the FreeIPA design for hidden replicas, Kerberos clients using dns_lookup_kdc do not discover it, and certmonger does not use it to renew certificates. That makes the hidden replica a poor fit for any role that clients must reach, such as serving logins, answering DNS for enrolled hosts or handling certificate requests from machines in the field. Confirm each of those roles against your own client configuration before you rely on the server staying quiet.
Before you add one, decide what the server is for and how long it will stay hidden. Confirm with your team whether the server will run the Dogtag CA or DNS, since those services still need the replication and renewal planning described in the deployment recommendations. Check the replica count and replication agreement limits in your topology, because a hidden server still takes part in replication. If the server will be promoted to a visible role later, plan that change as a topology change with its own verification steps, not as a configuration toggle.
Which jobs suit a hidden replica
A hidden replica is a sensible place to rehearse restores and to hold data you may need to recover, because no client will authenticate against it or try to renew a certificate from it. Clients keep using the visible servers while your team restores into a separate environment and checks the results. This keeps experimental or partially restored data away from production logins.
- Keep restore tests off the live path: Clients never discover the replica through SRV records, so a half-restored server does not receive Kerberos or LDAP traffic.
- Do not restore an old backup into an active topology: Restoring an outdated backup into a running replica topology can break replication, so restores should be rehearsed on an isolated copy first.
- Watch certificate duties: The backup documentation notes that the first server handles certificate renewal and CRL publication by default, so confirm which server holds those roles before any restore.
- Record what was tested: Keep a dated log of each restore rehearsal, including the backup used and the checks passed.
- Plan the promotion path: Decide in advance whether a restored server will ever rejoin the production topology, and how.
Before you rely on this pattern, confirm with your own runbook which server performs backups and how your team will verify a restored directory.
Large batches of user, group or policy changes generate a lot of directory writes and replication traffic. Running them against a hidden replica lets the team check the scripts and the resulting data before the same changes reach servers that clients depend on. It also gives administrators a place to measure the effect without interrupting logins.
- Test imports and migrations first: Run bulk loads against a hidden copy to catch attribute errors, duplicate names and policy conflicts.
- Keep client-facing servers stable: Because clients do not use the hidden server, a faulty batch does not immediately affect enrolled machines.
- Mind replication direction: Changes made on a hidden replica still replicate to the rest of the topology, so the hidden server is not a sandbox unless it is isolated from the other servers.
- Use an isolated copy when you need a true sandbox: If the changes must never replicate, build a separate test deployment instead of relying on a hidden replica.
- Schedule and document the run: Record the batch, the operator and the rollback steps before the production run.
Ask your team to confirm whether the planned bulk changes will replicate, and agree who signs off before any production run begins.
A hidden replica can receive a new package version or a configuration change while visible servers keep serving clients. Staging maintenance this way lets the team observe behavior on a real server with real data before the change reaches the rest of the topology. Because clients ignore the hidden server, a problem found during the test does not reach user logins directly.
- Stage package and configuration changes: Apply the change to the hidden server first, then check services, replication status and logs.
- Test before you promote: Confirm that the server behaves correctly before it is given client-facing roles, if it ever is.
- Plan the server role change explicitly: Making a hidden server visible means enabling SRV records and LDAP server roles, which clients will then use. Treat that step as a planned change with its own check.
- Check release notes for each version: Review the FreeIPA release notes for the target version and any security fixes before testing.
- Keep a rollback path: Know how to return the server to its previous state if the test fails.
Confirm with your vendor or your own test results which upgrade steps apply to your version and whether a hidden server can be promoted without service interruption.
How DNS SRV records, server roles and discovery treat a hidden replica
A hidden replica is invisible to the discovery mechanisms clients use by default. It runs the full set of FreeIPA services, but it publishes no DNS SRV records and has no LDAP server role enabled. As a result, IPA clients and SSSD skip it when they choose a server, Kerberos clients that rely on dns_lookup_kdc never list it as a KDC, and certmonger does not pick it when it renews certificates. The practical consequence is that every client keeps talking to the visible servers, and the hidden server receives traffic only when something points at it by name, such as a manually edited configuration file or a script that calls it explicitly.
Plan for that explicit path before you rely on it. Clients that are pinned to a hidden server will not fail over to other replicas through discovery, so a hidden server that goes down can leave those clients without a working server. Keep the list of explicit targets short, record which systems use them, and remove the pinning when the maintenance or bulk job is finished. Also decide which server should renew certificates while a replica is hidden, because certmonger will not choose it on its own.
Confirm the exact ipa commands and options for hiding and promoting a server in your release before you write a runbook, since the way roles and SRV records are changed can differ between versions. Check the current design notes at the FreeIPA project documentation and test the procedure on a non-production topology. Then verify the result from a client: query the SRV records for the domain, confirm that the hidden host is absent, and confirm that a Kerberos ticket request still succeeds against the visible KDCs.
Hidden, visible and dedicated replica options compared
This table compares a visible replica, a hidden replica and a dedicated maintenance replica on client discovery, certificate renewal, DNS SRV presence, backup use and removal effort. Read each row as a question you need answered for your topology, then check the hidden replica row against your client and renewal design before you decide.
| Aspect | Visible replica | Hidden replica | Dedicated maintenance replica |
|---|---|---|---|
| Client discovery | Enrolled IPA clients and SSSD can discover and use it | Ignored by IPA clients and SSSD; Kerberos clients using dns_lookup_kdc do not find it | Depends on configuration; confirm whether it is hidden or visible before clients enroll |
| Certificate renewal role | Can be selected by certmonger for renewals | Not used by certmonger to renew certificates | Renewal use depends on whether its roles are enabled; confirm with your CA layout |
| DNS SRV records | Published for its enabled server roles | None published, since it runs all services without enabled LDAP server roles | Confirm with your administrator whether any SRV records exist for it |
| Backup use | Can run backups, but its state is part of live replication | Suitable for taking backups without affecting client-facing service | Often the place for ipa-backup runs; restoring an outdated backup into an active topology can break replication |
| Removal effort | Requires planned replication and role cleanup before removal | Low client impact, since clients never relied on it | Low client impact, but confirm that no workload or script points at it before removal |
| Replica count guidance | Plan two to three replicas per datacenter, with no more than four agreements per replica | Counts as a replica in the topology, so include it in agreement limits | Count it against the same per-datacenter and agreement guidance as other replicas |
Trade-offs of running a hidden server
A hidden replica is useful only if the team accepts what it does not do. The cards below cover the trade-offs that follow from the hidden design: lighter client-facing load, no automatic failover, replication limits, certificate renewal ownership, and the cost of sizing and patching one more server.
Reduced client load
Because a hidden replica publishes no DNS SRV records and no enabled LDAP server roles, IPA clients and SSSD never send requests to it. It serves its share of replication and back-end work without taking part in daily logins, host lookups or Kerberos ticket requests. Check which servers your clients actually reach by reviewing SRV records and SSSD server lists after each change, since the hidden server should not appear there.
No automatic failover
Clients do not discover a hidden server, so it cannot take over when a visible server fails. Kerberos clients using dns_lookup_kdc skip it, and certmonger does not use it for renewals. Failover capacity must come from the visible servers. If your plan relies on the hidden server as a standby, you need a documented procedure to make it visible, which is a manual change to the server roles and DNS records.
Replication agreements count toward the limit
A hidden replica still joins the replication topology, so each agreement it creates counts against the recommended limit of no more than four replication agreements per replica. Adding a hidden server to a busy site can push an existing replica past that limit. Map every agreement on the planned topology before you add the server, and confirm the count on the replicas it connects to.
Certificate renewal ownership
certmonger does not use a hidden replica to renew certificates, but the first server in a topology still handles certificate renewal and CRL publication by default. Teams that run a hidden server for backups can misread which host is doing that work. Record which server holds the renewal role, confirm that role is on a visible replica that runs PKI, and check renewal status after any topology change.
Sizing and patching the extra server
A hidden replica still runs all services, so it needs CPU, memory, storage and network capacity, and it needs the same security updates and FreeIPA release level as the rest of the topology. Keeping it on a different patch cycle creates version drift during replication. Ask your team to name an owner for the hidden server, a patch window that matches the other replicas, and a sizing check against the workload it will carry.
Setting up a hidden replica in sequence
This sequence takes a dedicated FreeIPA server from topology planning to a documented hidden replica that runs services for backups, bulk operations or staged maintenance while clients and certmonger continue to ignore it. Each step ends with a check you can record before moving on.
Confirm topology and replica count
Before any server is built, the platform team confirms where the hidden replica sits in the existing topology and how many replicas each datacenter already runs. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, and at least one replica per datacenter running PKI or DNS if those services are used, so the hidden replica is an addition to a layout that already meets these points, not a substitute for it. Record the planned purpose (backup, bulk operations or staged maintenance), the datacenter, and which services it will run. The check is a written topology diagram that shows the new agreement count for each neighboring replica.
Take a verified backup before changing topology
Before adding any server or replication agreement, take a full backup with ipa-backup on the current first server and confirm the archive is readable. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so this backup is a recovery point for the existing deployment, not a convenience. Store a copy outside the affected hosts and note the time and the server that produced it. The check is a backup archive you have tested with a restore procedure in a non-production environment, or a documented decision by the owner that the test is out of scope.
Install the server on dedicated hardware
Provision a host for the replica and install the FreeIPA server packages on it, keeping the machine dedicated to FreeIPA without other applications, as the deployment recommendations advise. Enroll the host as a client of the existing domain first so it resolves the realm correctly, then run the replica installation against an existing server. Confirm DNS resolution of the new host's name from both directions, because replica installation depends on it. The check is a successful installation exit with the host listed in the server inventory on the first server.
Establish replication and confirm agreement count
Create replication agreements from the hidden replica to the chosen peers, and confirm the new agreement count stays within the recommended limit of four per replica. Check that the directory replicates both ways by making a test change on one server and reading it on the other. The check is a replication status report that shows no errors on any agreement, and a test user or group created on one server that is visible on the other within the same replication cycle.
Verify services and role status on the hidden replica
Confirm that the services the replica is meant to run are active, such as the directory server, Kerberos KDC and, where planned, the certificate authority or DNS. Use the FreeIPA health check and service status commands on the host, and confirm that the server appears with the expected roles on the first server. The check is a clean service status for every planned component and an inventory entry showing the expected roles. If a service you planned is missing, resolve it before the next step, because the later checks assume the replica is fully running.
Confirm the hidden status and client behavior
Verify that the replica is hidden in practice. Query the DNS SRV records for the IPA domain from a client network and confirm that the hidden host does not appear in the _ldap, _kerberos or _kpasswd records. On a test Linux client, confirm that SSSD does not select the replica, that a Kerberos client with dns_lookup_kdc does not contact it, and that certmonger renewals continue to go to the other servers. The check is a recorded set of DNS query results, SSSD and Kerberos log extracts, and one certificate renewal request that the hidden host does not handle.
Document the role and operating limits
Write a short runbook entry for the hidden replica that records its purpose, the datacenter, the services it runs, the agreements it holds, the backup schedule that depends on it, and the procedure to bring it into or out of service. State clearly that clients do not use it, so any operator who needs to route work to it knows to connect to it directly. Add it to the topology diagram and the monitoring inventory. The check is a runbook entry reviewed by the owner of the identity service, with its last verification date recorded.
Security and operational risks of hidden replicas
A hidden replica is easy to forget because clients never use it and never report on it. The risks below come from its full copy of directory data, from the backup and restore work it is often built for, and from the monitoring gaps that appear when no client touches the server.
Outdated backups break replication
Restoring an old backup into a running topology can break replication between servers. The FreeIPA backup documentation warns about this, so a hidden replica used for restore testing must never be pointed back into production. Restore tests should run on an isolated copy, and the team should confirm the restore procedure in the backup documentation before any production restore is attempted.
Full directory data on hidden servers
A hidden replica runs all services and holds the complete directory, including user accounts, group memberships, host records and password hashes. Because it is not visible to clients, it can be overlooked in access reviews and patch cycles. Treat it with the same controls as the first server, including host hardening, encrypted storage, network restrictions and the same administrative access rules.
Restricted access to backup staging
Backups taken on a hidden replica often land in a staging directory before they move elsewhere. Anyone who can read that directory can read credentials and key material from the backup. Limit read access to the backup operator account, confirm file permissions and retention after each run, and record who may copy backups off the host.
Monitoring must include hidden servers
Clients do not contact a hidden replica, so an outage or replication fault on it produces no failed logins and no visible error for users. Monitoring must query each hidden server directly for service health, replication status and certificate expiry. Ask your team to confirm that alerts reach the people who run the topology, not only the people who handle client tickets.
Certificate renewal stays with the first server
Certmonger does not use hidden replicas to renew certificates, and the first server handles renewal and CRL publication by default. A hidden replica therefore does not reduce the renewal dependency on that server. Check which server performs renewal and CRL publication in your topology, and plan for that server's availability as part of the design.
Questions teams ask before running a hidden replica
Is a FreeIPA hidden replica a failover target?
No. A hidden replica runs all the services, but it has no DNS SRV records and no enabled LDAP server roles, so IPA clients and SSSD ignore it, and Kerberos clients using dns_lookup_kdc do not find it. Clients will not fail over to it on their own. It is a server you point at deliberately, for backups, bulk operations or staged maintenance. If you need automatic failover for logins, plan that with visible replicas placed in each datacenter, following the project's deployment recommendations.
How much effort do setup and testing take, and what drives it?
Effort depends mostly on the current topology, not on the hidden flag itself. The main drivers are the number of existing replicas and replication agreements, whether the replica will run PKI or DNS, how many clients use hard-coded server names or static resolv.conf entries, and how thoroughly you test promotion, demotion and restores before you rely on the server. Ask any provider to price the work from a written scope that lists the replicas, the services on each, the test cases and the rollback plan. Setup is usually one-time; monitoring, patching and periodic restore tests recur.
What does the internal team need to provide?
The work needs people who can operate the existing FreeIPA estate and make decisions about it. Typically that means someone who knows the current replication topology, someone who owns DNS and certificate policy, and someone who can schedule maintenance windows and approve changes. You will also need access to the servers, the backup storage and the change process, plus a clear record of which clients depend on which server names. Confirm these responsibilities in writing before the engagement starts, so nobody assumes a step is covered by someone else.
Can our own team build and run a hidden replica?
Often yes, if your engineers already run FreeIPA replicas and have tested restores. The project documents the hidden role, and the steps are a matter of installing a replica and not enabling its service roles. The risk sits in the details: a restored or outdated backup loaded into an active topology can break replication, and the first server handles certificate renewal and CRL publication by default. Build it yourself if you can rehearse those procedures and keep a runbook. Use a partner if your team lacks that depth or needs independent validation before production use.
How does a hidden replica change upgrades and certificate renewal?
A hidden replica still takes part in replication, so it must be upgraded in step with the rest of the topology, and you should check the release notes for each 4.x version before you start. Because certmonger does not use a hidden replica to renew certificates, renewals continue through the servers that advertise the CA roles. Confirm which server holds the renewal and CRL duties in your deployment, and do not let a hidden replica quietly become the only server able to renew certificates. Test renewal after every upgrade step.
Who is the right owner for the cost of this work?
The cost has two parts: the people who design and test the change, and the ongoing operation of the extra server. Setup is one-time work. Hosting, patching, monitoring and periodic restore tests recur for as long as the replica exists. Costs rise with the number of replicas, the size of the topology, the number of services on the hidden server, and the amount of testing your compliance or change process requires. When you request a quote, ask for the scope, the deliverables, the test evidence and the handover documentation, so the figure can be compared with doing it in-house.
What happens if we restore a backup onto a hidden replica?
Treat that as a high-risk operation. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Use hidden replicas for restore rehearsals and staged maintenance only after you have a documented procedure, and check replication health before and after each step. Keep the restored server isolated from production clients until replication is confirmed. Record the backup age, the restore command and the verification results so that auditors and on-call staff can follow the sequence later.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports FreeIPA inside infrastructure you control, including the placement and handling of hidden replicas. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- Inventory which replicas must stay invisible to clients and which must stay discoverable for DNS and Kerberos
- Record which services each hidden replica runs, such as backup, bulk operations or staged maintenance
- Confirm which certmonger renewals and client discovery paths the design must not change
How we build
- Deploy the hidden replica and verify it has no DNS SRV records or enabled LDAP server roles
- Test that IPA clients, SSSD and Kerberos clients with dns_lookup_kdc ignore the replica during normal logins
- Confirm certificate renewal still runs on the intended servers before the replica is put into service
How we hand over
- Deliver a written runbook covering promotion, demotion and removal steps for each hidden replica
- Document the discovery and renewal checks used during acceptance testing, with results recorded
- Walk your operations and identity teams through backup, restore and maintenance procedures
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review the replica topology when FreeIPA releases change DNS, certificate or Kerberos behavior
- Repeat discovery and renewal checks after server changes, using the agreed scope as the baseline
