Introduction

An identity migration can stand up a new FreeIPA realm while enrolled Linux clients still authenticate against the old one. Local logins and SSH may appear normal at first, but identity lookups or Kerberos authentication keep resolving through the retired realm, one server joins the new realm while another still follows the previous domain and KDC path, or failures begin only after the old realm is restricted because SSSD settings, Kerberos realm config, and DNS discovery often move unevenly.

Treat this as a client realm-selection problem instead of a generic Linux authentication outage. Start by checking which realm, domain, and KDC an affected client actually uses at runtime, because migrations often validate the new realm with fresh enrollments while existing systems continue following older SSSD and Kerberos settings.

Symptoms

  • A FreeIPA client still authenticates against the old realm after migration
  • Users can log in locally, but identity lookups or Kerberos flows still resolve through the retired realm
  • One Linux host uses the new realm while another still uses the previous one
  • Authentication failures begin only after the old IPA server, realm, or DNS records are removed
  • The new realm is healthy, but migrated clients never use it consistently
  • The issue started after moving FreeIPA, IPA replicas, Kerberos realm names, or client enrollment workflows

Common Causes

  • sssd.conf still points to the old IPA domain, realm, or server set
  • Kerberos config still references the previous realm or KDC mapping
  • DNS SRV or resolver search paths still direct clients to the retired IPA infrastructure
  • A host was reconfigured partially, but its enrollment or local keytab still belongs to the old realm
  • Golden images, cloud-init, or automation keep reenrolling hosts into the earlier domain
  • Validation confirmed the new realm accepted test logins but did not verify which realm existing clients actually queried

Step-by-Step Fix

  1. Capture one affected client and record the active realm, IPA domain, KDC resolution, SSSD target, and enrollment state it actually uses, because the live realm path determines where authentication and identity lookups really land.
  2. Compare that active client path with the intended post-migration identity design, because one stale realm or resolver setting can keep large host groups tied to the retired FreeIPA environment.
  3. Review sssd.conf, Kerberos realm config, resolver settings, DNS SRV discovery, enrollment status, and automation templates for references to the old realm, because FreeIPA client behavior depends on both static config and service discovery.
  4. Check each host image, subnet, and enrollment workflow separately if behavior differs, because migrations often update one client path while another still joins or resolves through the previous realm.
  5. Update the authoritative client realm configuration and enrollment workflow so affected hosts authenticate against the intended FreeIPA environment, because standing up the new realm alone does not retarget existing clients.
  6. Clear or refresh client cache as needed and run a controlled identity lookup or Kerberos authentication test, because a host staying online does not prove the right realm now handles authentication.
  7. Verify the old realm no longer receives client lookups, Kerberos requests, or enrollment traffic from migrated hosts, because split identity paths can remain hidden while both realms stay reachable.
  8. Review time sync, trust configuration, certificates, and host principals if authentication still fails, because the destination can be correct while Kerberos trust or enrollment state still blocks the new path.
  9. Document which team owns client enrollment, DNS discovery, and migration validation so future FreeIPA cutovers verify the actual runtime realm target before retiring the previous environment.