FreeIPA security hardening

The Dogtag certificate authority signs trust for your FreeIPA realm. Host certificates, service certificates and any certificate issued through IdM chain back to it, so a compromised CA lets an attacker issue identities that the rest of the environment will accept. Hardening starts with two decisions: who can administer the CA, and on which machines it runs. Limit CA administration to a short, named list of administrators, require individual accounts instead of shared ones, and record every administrative action. Then decide where the CA runs and confirm that the hosts carrying it are dedicated to identity services and sit behind the same access controls you apply to domain controllers and privileged management systems.

The FreeIPA backup documentation states that the first server in the topology handles certificate renewal and CRL publication by default. That role makes it the most sensitive host in the deployment, so it needs tighter access than the other replicas. Identify it before go-live by checking which server holds the renewal and CRL role in your topology. Restrict SSH and administrative sessions to it, place it on a management network segment, and forward its authentication and audit logs to a central system that someone watches. Also confirm with the documentation for your release whether this role can be moved, and plan any move as a tested change, not as an emergency step during an incident.

The ipa-backup tool produces either full backups or online data-only backups. Both contain sensitive identity data, and depending on the scope you choose, they may include key material as well. A backup file therefore deserves the same protection as the live directory. Before the first scheduled run, decide where files are written, how they are encrypted at rest, which accounts can read or copy them, and how access is logged. Then test each control. Confirm that a non-administrator cannot read the backup directory, that offsite copies remain encrypted, and that an access to a backup file produces a log entry you can review. Agree retention periods with your compliance owner, because every retained copy extends the period in which stolen data remains useful to an attacker.

The backup documentation also warns that restoring an outdated backup into an active replica topology can break replication. A restore should therefore be a controlled change with a named owner, a written runbook, and an agreed decision on whether you recover a single server or rebuild the topology from it. Before anyone runs ipa-restore, confirm which backup is the newest known good copy, freeze changes that would diverge from it, and agree how replicas will be reinitialized afterward. Rehearse this procedure in a non-production realm built from a copy of your data. On certificates, FreeIPA 4.13.0 introduced random certificate serial numbers by default. Confirm in your version how the CA assigns serial numbers, whether any certificate profile overrides that behavior, and how restored CA data interacts with serials already issued.

Hardening is only finished when each control has been tested and the result has been written down. Start with the version. Run the installed FreeIPA package version on every server and compare it with the FreeIPA 4.13.4 release notes, which list two CVE fixes, including LDAP access control flaws that could let unauthenticated clients obtain credentials. Record the package versions, the date you checked, and the operating system release for each host. A server that reports an older build fails this check, even if its services appear to run normally. Next, test authentication from the client side. Sign in as a test user with a password alone and then with the password plus a token, using both a software token and a hardware token if you issue both. Confirm that accounts in scope cannot pass with a password alone where your policy requires OTP. For lockout, deliberately fail logins from a dedicated test account until the lockout threshold is reached, then confirm the lock lasts for the duration your password policy sets and that the account recovers as documented. Use values from your own policy export, not from memory, and note which service accounts would be affected by the same lockout.

Verify access control from the outside in. From a host or account that should have no directory rights, attempt anonymous and low-privilege LDAP searches against the IdM servers and confirm they are refused. Repeat the test with a user who should only see their own entry. Test host-based access control the same way: a user outside an HBAC rule should be denied on the target host, and the denial should appear in the logs. For certificate authority duties, confirm that certificate renewal and CRL publication are running on the server you intended, not on a replica that was added later. Check the CA renewal master setting and the certmonger tracking state on each server, and verify that the published CRL is reachable where your relying parties expect it. Test DNS over TLS from a dedicated test client, not from an IdM server. Confirm that the client resolver is configured to use the encrypted path to the IdM DNS servers, and capture a query to show that name resolution succeeds over that path. Then check how the client behaves when the encrypted service is unavailable. Your team needs to know whether resolution fails closed or silently falls back to plain DNS, because the answer determines your risk. FreeIPA 4.13.0 introduced DNS over TLS between clients and IdM DNS servers, so confirm the behavior on your exact version rather than assuming it from older guides.

Failure testing is where safe behavior is proven. For a lost OTP token, confirm who may reset a token, what identity check the help desk performs, and whether the reset is logged. Enroll a second test token, simulate losing the first, and walk through the reset. The test passes if the lost token stops working, the reset requires the approved steps, and no shortcut exists that skips OTP for that account. For a replica that is down, stop one replica in a test topology and confirm that clients fall back to the second DNS server listed in their resolver configuration, that logins still succeed, and that the replica rejoins replication cleanly once it returns. Check replication status on all remaining servers before and after. Rehearse a backup restore in an isolated environment that has no route to production replicas. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so the rehearsal should prove that your restore procedure keeps the restored system isolated until its state is verified. Time the steps, note what the operator had to decide, and list any manual actions that a runbook must cover. Repeat the rehearsal after any topology change, not only once at go-live. Record every test as evidence. For each check, keep the test identifier, the date, the FreeIPA and operating system versions, the exact commands or console steps, the output or captured logs, the expected result, the actual result, and the name of the person who ran and reviewed it. Store failures with the corrective action and the retest result. Ask your auditor or internal assessor which format they accept before you start, because a clear record of a failed test that was fixed is usually more useful than a clean page with no detail.