Diagnosing FreeIPA UNREACHABLE status

Complete the following diagnostic workflow before any repair-freeipa action on an UNREACHABLE FreeIPA node.

  1. Confirm FreeIPA service health directly on the VM.
    ssh cloudbreak@<freeipa-vm>
    sudo ipactl status

    If all services indicate RUNNING status, then the FreeIPA node is healthy, and the issue is reachability, not faulty service. Do NOT REBUILD.

  2. Check Cluster Connectivity Manager (CCM) agent health on the FreeIPA VM.
    sudo systemctl status ccm
    sudo cdp-telemetry doctor ccm status
  3. If neither of the previous tests returns a failure (for example, CCM accessible: False or DNS Anwser: Failed), check outbound network reachability.
    sudo cdp-doctor network status

    Look for the asymmetric pattern:

    • cloud-provider endpoints reachable
    • *.cloudera.com, *.altus.cloudera.com, or *.ccm.cdp.cloudera.com inaccessible.
  4. Check DNS resolution.
    cdp-telemetry doctor network status
    If DNS resolvers point to 127.0.0.1, verify local BIND (named) and its upstream forwarder.
  5. If steps 1-4 have all passed, investigate the FreeIPA issues as a service issue and proceed with the FreeIPA repair operation. If the repair operation was unsuccessful, open a support ticket with Cloudera Support.

Expected behavior after the fix:

  • Control plane reachability to FreeIPA was restored within minutes of the DNS allowlist update.
  • No repair-freeipa action required.
  • No destructive REBUILD was performed on healthy nodes.
  • Full identity-management recovery without data loss.

Verify FreeIPA status.

  1. The cdp environments get-freeipa-status command returns HEALTHY for both FreeIPA nodes.
  2. The cdp-telemetry doctor ccm status command returns CCM accessible: True and DNS Answers: Success.
  3. Cloudera Management Console reflects FreeIPA status as healthy.
  4. Downstream symptoms (SolrEntitiesInfoFetcher 403s, Knox/Ranger authorization noise) clear without additional intervention.