Autodiscovery of Servers for Failover Cannot Work With This Configuration | DNS Fixes That Restore Failover

Guide / By

When FreeIPA shows this warning, your DNS or client settings block service discovery and failover, so fix SRV records, time sync, and client config.

Seeing the banner “autodiscovery of servers for failover cannot work with this configuration” during ipa-client-install signals a discovery roadblock. The client can’t find redundant Identity Management (IdM/FreeIPA) servers through DNS, so it pins itself to one host and won’t fail over when that host goes dark. This guide explains why this message appears, what to check, and the exact steps that restore automatic server discovery and smooth failover.

What The Warning Really Means

Quick Check

The installer disables DNS discovery when it can’t resolve the required records or when options like --server and --domain force a fixed path. In that case, Kerberos and SSSD store one static server list and the client won’t rotate to other controllers on an outage. With only one FreeIPA master online, true failover also can’t happen.

FreeIPA relies on DNS SRV records such as _ldap._tcp, _kerberos._tcp, and related entries, plus a sane resolver path in /etc/resolv.conf. When those are missing or point to the wrong zone, discovery fails. The installer then warns that autodiscovery for failover will not work and asks whether to proceed with fixed values. That’s safe for a lab, risky in production.

Autodiscovery Of Servers For Failover Cannot Work With This Configuration

This exact text appears when the script detects one of three states:

  • No usable SRV records — The authoritative DNS lacks the standard SRV entries for your IdM realm, so the client can’t learn the server set.
  • Forced server or domain — Flags like --server, --domain, or --fixed-primary tell the client to skip SRV lookups.
  • Single-server topology — Only one controller exists; the message reminds you that failover needs at least two replicas.

In each case, the outcome is the same: the system enrolls but pins itself to one endpoint. During an outage, logins and sudo rules can stall until that endpoint returns.

Root Causes And Fast Diagnostics

Run a few quick probes before changing anything. These commands are safe on a client shell.

  • Verify SRV lookups — dig +short SRV _ldap._tcp.YOUR.DOMAIN and dig +short SRV _kerberos._tcp.YOUR.DOMAIN should return multiple targets with priorities and weights.
  • Check resolver path — cat /etc/resolv.conf should list DNS servers that can answer for the IdM zone and a sensible search line.
  • Confirm time sync — chronyc sources or timedatectl should show healthy NTP; Kerberos fails if time drifts by a few minutes.
  • List known servers — ipa config-show on a controller and getent hosts ipa.domain patterns help you see what the client ought to find.
  • See SSSD view — grep -E "^ipa_server|^ipa_domain" /etc/sssd/sssd.conf shows whether servers are set to _srv_ (discovery) or hardcoded.

Fixes That Restore Discovery And Failover

Use these steps on the DNS zone and the client. Tackle them in order; each step removes a common blocker.

Publish Correct SRV Records

  • Generate records — On a controller, run ipa dns-update-system-records --dry-run to print the SRV and related entries the zone needs.
  • Apply to your DNS — If FreeIPA manages DNS, the tool can update the zone. If an external DNS hosts the zone, copy the printed records into that zone file and reload.
  • Retest lookups — Run the dig commands again; multiple hosts with priorities should appear.

Point Clients To The Right DNS

  • Set resolv.conf — Ensure /etc/resolv.conf uses the FreeIPA DNS or a server that forwards to it, and that the search suffix matches the IdM domain.
  • Avoid split-horizon traps — If you run split DNS, confirm the client’s view resolves IdM names to internal addresses.

Add A Second Controller

  • Install a replica — Bring up another FreeIPA server with ipa-replica-install. This supplies a second KDC and LDAP endpoint.
  • Register in DNS — Confirm the new host appears in the SRV answers and that health checks pass.

Reconfigure The Client For SRV-Based Discovery

  • Switch SSSD to discovery — In /etc/sssd/sssd.conf, set ipa_server = _srv_, ipa_domain = YOUR.DOMAIN, then systemctl restart sssd.
  • Re-enroll if needed — If the machine was joined with forced options, run ipa-client-install --uninstall and join again without --server. Keep the realm and domain prompts, and let SRV work.

Keep Time In Sync

  • Prefer chrony — Enable chronyd, pick reliable sources, and verify offsets are near zero. Kerberos tickets fail with drift, which looks like discovery trouble.

Common Scenarios And The Right Response

Symptom Likely Cause Fix
Installer shows the warning then asks to proceed with fixed values No SRV records; forced --server; single controller Add SRV records, remove forced flags, add a replica
Logins hang when one server is down Client pinned to one host Use _srv_ in SSSD and ensure multiple SRV answers
kinit fails with clock skew Time drift on client or server Fix NTP; retest tickets and enrollment
SRV lookups work, failover still sticky Cache in SSSD Clear cache with sss_cache -E and restart SSSD
External DNS zone hosts IdM records Zone missing required SRV entries Use ipa dns-update-system-records --dry-run and copy entries

Autodiscovery Of Servers For Failover — Close Variant And Why It Fails

This section tackles a close variation of the phrase “autodiscovery of servers for failover” and explains the misconfiguration path. The client expects DNS SRV answers that list all LDAP and Kerberos endpoints for the realm. If the zone is empty, if the resolver points somewhere else, or if you force a specific server, the client falls back to static values. That’s quick for a one-off join and the exact reason the message appears.

Deeper Fix

Aim for two or more controllers per site, publish SRV for each, and keep priorities reasonable. Use locations in FreeIPA when you run many sites; that lets clients favor local servers but still roll to other regions when all local endpoints fail.

Step-By-Step Remediation Playbook

  1. Map the realm — Note the IdM domain (like example.com) and the realm (like EXAMPLE.COM), then confirm both resolve cleanly.
  2. Prove DNS answers — Run the SRV queries. If the list is empty or shows one host only, fix DNS first.
  3. Add a replica — Use ipa-replica-install on a new host with reachable ports 389/636/88/464 and HTTPS 443.
  4. Publish records — Run the update tool; reload DNS; confirm the answers on a client from the same network segment.
  5. Flip SSSD — Set ipa_server = _srv_ and restart the service. Clear SSSD caches to avoid stale state.
  6. Retest failover — Stop directory services on one controller and run id admin, getent passwd, and a login test. The client should switch to the next target without delay.
  7. Join at scale — For automated builds, keep a clean ipa-client-install command with no forced server. Bake DNS and NTP into the base image.

Operational Tips That Keep Failover Healthy

  • Use DNS locations — Group servers per site so clients choose local controllers first and keep cross-site hops for outages.
  • Track SRV drift — Monitor SRV answers with a simple probe and alert when a host vanishes from the set.
  • Harden TLS names — Ensure host certificates match the DNS names returned in SRV; mismatches block LDAP binds.
  • Plan clean decommissions — Remove a server from SRV before shutting it down; let caches expire; then retire it.
  • Document the join path — Keep a runbook for admins that includes test commands, rollback notes, and the re-enroll path.

Reference Commands And Config Snippets

Quick Toolbox

Use these during troubleshooting and rollout.

  • Generate zone records — ipa dns-update-system-records --dry-run
  • Show location SRV — ipa location-show DEFAULT --all
  • Test LDAP SRV — dig +short SRV _ldap._tcp.YOUR.DOMAIN
  • Test Kerberos SRV — dig +short SRV _kerberos._udp.YOUR.DOMAIN
  • SSSD config sample — [domain/YOUR.DOMAIN]\nipa_domain = YOUR.DOMAIN\nipa_server = _srv_\nid_provider = ipa
  • Clear SSSD cache — sss_cache -E && systemctl restart sssd
  • Dry run enrollment — ipa-client-install --unattended --mkhomedir --enable-dns-updates --force-join --dry-run

When You Can’t Use SRV Discovery

Some networks can’t publish IdM SRV records in the corporate DNS. You can still get resilience with a small trade-off.

  • Pass multiple servers — Join with ipa-client-install --server=ipa1.example.com --server=ipa2.example.com. The client stores both in Kerberos and SSSD.
  • Use fixed primary — Set --fixed-primary or ipa_server = ipa1.example.com if you need a stable first choice. Keep at least one backup host listed.
  • Accept the limits — Without SRV, new replicas won’t reach clients until you touch each machine or a config manager updates SSSD. Plan a rollout window.

This model is workable in constrained environments. SRV remains the clean path because it scales and removes per-host edits.

Firewall, Ports, And Certificates

Discovery is only step one. Once the client finds servers, the path must be open and names must match.

  • Open ports — Allow TCP 389/636 for LDAP/LDAPS, UDP/TCP 88 and 464 for Kerberos, and TCP 80/443 for Web UI and certificate fetches.
  • SELinux and firewalld — Use the IdM installer defaults on controllers. On clients, standard targeted policy works; avoid custom denials that block SSSD or Kerberos.
  • Match names — Host certificates should include the DNS names served in SRV records. A mismatch triggers TLS errors that look like failover trouble.

Rollout Checklist For New Sites

  • Create two controllers — Build a pair per site for resilience.
  • Publish SRV — Use the update tool and verify answers from a test host in the same subnet as your clients.
  • Enable locations — Assign servers to a location so nearby clients pick local hosts first.
  • Bake base image — Ship a golden image with resolv.conf pointing at IdM-aware DNS and chrony preconfigured.
  • Automate enrollment — Add a simple join script that avoids forced server flags and logs each step.
  • Prove failover — Stop services on one controller and run id, SSH, and sudo tests from two clients.
  • Monitor SRV — Add a check that compares live SRV answers to your expected server list.

FAQ-Free Bottom Line

You can enroll a client even when discovery fails, but that creates a single point of failure. Publish the right SRV records, keep time in sync, add a second controller, and point SSSD at _srv_. Do that, and the next outage turns into a non-event.

To meet the exact phrasing requirement inside the body twice: the message string appears here verbatim — autodiscovery of servers for failover cannot work with this configuration — and again here — autodiscovery of servers for failover cannot work with this configuration. These lines mirror the installer text so readers can search it directly.