Auditing FreeIPA API changes: what the logs can and cannot tell you
An auditor or security lead who has to answer who changed a user, group, host or policy, and when, needs to know that FreeIPA changes reach the directory along three different paths. The first is the web UI and the command line, which both call the FreeIPA API. Those API calls are logged by Apache on the FreeIPA server that received them. The second is a direct write to LDAP made as root on a server, which skips the API entirely. The third is replication, because FreeIPA runs 389 Directory Server as a multi-master directory, so a change made on one replica is copied to the others. Each path leaves different evidence, and no single log answers every question.
Apache access logs show the request, the time and the source, and they may show the account used, depending on your authentication settings. Confirm with a test change on your FreeIPA version which fields carry the acting identity and whether the request content, which holds the attribute values that changed, is recorded. Also confirm what the logs do not show, such as failed authentication attempts, the intermediate steps of a multi-step change, or actions taken by scripts that run under a service account. The root LDAP path produces no API request, so its evidence depends on access and audit logging in 389 Directory Server on that server, which you must enable and verify. For replicated changes, confirm what the receiving server records, because it may show that a change arrived without identifying the administrator who made it on the origin server.
Teams need this evidence for three reasons. For compliance readiness, an assessor may ask you to show that privileged changes are attributable to a person or an approved process. For incident review, the question is whether an account gained access it should not have and when that happened. For access reviews, the history of group and host membership must be defensible for the period under review. Before work starts, map each of the three change paths to a log source, decide where logs are shipped and how long they are kept, and run one known change through each path to see what actually appears. Ask your auditor which evidence they accept, since DeployOpen prepares systems and evidence but does not issue assessment conclusions.
Which logs record which kind of change
A change to a FreeIPA user, group, host or policy can leave traces in four places, and each one answers a different audit question. Read them together, because the web UI and CLI calls, the directory writes they produce, the authentication context and the replication state each show part of the picture.
Apache access and error logs
Web UI and ipa CLI changes arrive as JSON-RPC calls to the FreeIPA API, which Apache serves. The access log records the request, timestamp, source address and response status, so it shows when a change was submitted and from where. Check whether the authenticated principal is recorded in your release, because the access log alone may not name the acting administrator. Confirm the exact log format on your target version before writing parsers.
389 Directory Server access and audit logs
Every write that reaches the directory, whether it came through the API or another path, passes through 389 Directory Server. Its access log records the bind identity and operation, and its audit log can record the modified entry. Use it to confirm what changed in the data, then match it to the API entry by time and target DN. Confirm which audit options are enabled by default on your release and what they retain.
FreeIPA server and KDC logs
The FreeIPA server logs and the MIT Kerberos KDC logs explain authentication context: which principal obtained a ticket, which service was used and whether a request failed. They help you tie an administrative session to a login event on a specific server. Review them on every server, not only the first one, since administrators may authenticate against different replicas.
Replication state
Replication shows whether a change made on one server reached the others and whether any server holds data that differs from its peers. This matters when a change was made on a single replica or when a restore has been performed. Compare replication status across all servers during an investigation, and treat a divergence as a finding to explain before you rely on any single log.
Direct LDAP changes as root
Changes made directly against LDAP as root bypass the API. No Apache request exists for them, and the directory write may not show the acting administrator's identity, only the local root context. Treat any direct LDAP write during an audit as a gap that needs a host-level explanation from shell history, privileged access records or change tickets. Confirm with your release notes and test in a lab which fields the directory logs for these writes.
How to set up change capture on FreeIPA servers
This sequence turns an unknown set of administrative paths into a tested capture setup, where each change type that matters for an audit leaves a record that someone can find, read and keep. It is written so that your team can check each stage before moving to the next.
Inventory every administrative path
Before touching configuration, list every way a change can reach FreeIPA: the web UI, the ipa command line over the API, Ansible or other automation using the API, scripts that call the LDAP directory directly, and root shell access on each server. Assign an owner to each path and note which accounts or hosts use it. Done means you have a written list covering users, groups, hosts, host groups, HBAC, sudo rules and certificate operations, with each path marked as logged, partly logged or not yet confirmed. Paths you cannot account for are the first gap to close.
Confirm where Apache and 389 Directory Server write logs
On a non-production FreeIPA server, identify the Apache access and error logs that record API calls and the 389 Directory Server audit log location for the installed version. Confirm which log levels are active and whether API request bodies or only request paths are recorded. Check the file paths and rotation settings in the packaged configuration rather than relying on defaults from older documentation. Done means you can name each log file, its owner, its rotation policy and the level it records at, and you have verified this against the installed package versions.
Enable directory audit logging
Turn on the 389 Directory Server audit log for the instance that backs FreeIPA, using the configuration keys documented for your installed version. Make the change on a non-production server first, then restart the directory service in a maintenance window agreed with your team. Confirm the exact configuration attribute names with the 389 Directory Server documentation and the FreeIPA release you run, since names can differ between versions. Done means the directory service starts cleanly and the audit log file begins to grow after a test write.
Set retention and file permissions
Decide how long each log is kept, who may read it and where copies go, then configure log rotation and file modes to match. Audit logs can contain user names, group membership and host details, so restrict read access to a small group of auditors and the logging agent, and make sure the logs are not world-readable after rotation. Confirm that rotated files keep the same ownership and mode. Done means a rotation test produces the expected files with the expected permissions and that a non-authorized account cannot read them.
Test with a known change on a non-production server
Make a labeled, known change through each administrative path on a non-production FreeIPA server: create a test user, add it to a test group, create a host entry, adjust an HBAC rule and change a sudo rule. Record the time and the operator for each change so you can compare it with the logs. Repeat one change directly against LDAP as root to see what is and is not recorded. Done means you have a table linking each change to the log entries it produced, with the gaps written down.
Confirm each change type appears in the logs
Check that every change type from your inventory appears in at least one log source with enough detail to identify the actor, the object and the action. Look for the API call in Apache logs, the directory modification in the 389 Directory Server audit log and any change you could only make from root. Where a change type does not show up, decide whether to add a control, such as restricting root access or changing an automation account, or to accept and document the gap. Done means every row in your inventory has a confirmed log source or a documented exception signed off by the control owner.
Document the capture setup and the gaps
Write down the final configuration: log locations, levels, retention, permissions, the test results and each accepted gap with its owner. Include the version of FreeIPA and the directory packages you tested against, because log formats and configuration keys can change between releases. Ask your auditors which evidence they expect to see and confirm the document answers it. Done means a reviewer who was not part of the setup can repeat the test steps and reach the same results on the same version.
Choosing where audit records are collected and kept
This table compares three places audit records can live: the local server, a central log platform, and an append-only archive with its own retention. Read each row against your audit questions, because no single option covers every case. In most regulated environments the answer combines a central copy with an archive the FreeIPA administrators cannot quietly edit.
| Option | What it captures | Gaps | When it fits |
|---|---|---|---|
| Local logs only | Apache access and error logs for API calls on each IPA server, plus system journal entries for root sessions and direct LDAP work | Logs sit on the machines that administrators control, so a root user can alter or delete them; a lost server can take its history with it; cross-server correlation is manual | Small test or lab deployments, or as a temporary buffer before forwarding is configured |
| Forwarded to a central SIEM or log platform | API calls and host-level events from every IPA server and replica in one searchable index, with alerting on changes to users, groups, hosts and policies | Forwarding can fail silently unless monitored; the platform admins may hold the same privileges as IPA admins; the parsing rules must be written and tested for FreeIPA log lines; retention is set by the platform's settings | Multi-server or multi-site deployments that need correlated investigations and alerts; confirm your platform's ingestion limits and retention terms with the vendor |
| Append-only archive with separate retention | A write-once or write-restricted copy of the same log streams, held under a retention policy managed by a different team or account | Does not by itself make events searchable; access review and key management become their own duties; it records what was logged, not intent behind the change | Evidence-driven environments where an assessor may ask for unaltered records for a defined period; confirm the storage immutability features your platform offers |
| Direct LDAP changes as root | Limited: changes made with ldapmodify against 389 Directory Server may leave only a directory-level trace or none in Apache logs | Bypasses the API layer, so API-based audit lines do not show the change; must be captured through directory access logging or host auditing | Not a storage option; it is a coverage gap to close in whichever option you choose |
Why changes made directly against LDAP as root need extra controls
A root user who edits the FreeIPA directory with LDAP tools such as ldapmodify bypasses the web UI and the JSON-RPC API, so the Apache access and error entries that record API calls never see the change. The write goes straight to 389 Directory Server, which is the store behind users, groups, hosts and policies. The audit trail you built around the API therefore has a blind spot, and the change may look like ordinary directory state the next time anyone checks. Treat this path as a known gap and plan controls for it before an auditor asks how it is covered.
The usual compensating controls work in layers. First, restrict who can reach a root shell on FreeIPA servers, and make sudo the only route to root with each elevation logged to a central system outside the FreeIPA hosts. Second, compare directory state against a known baseline: take periodic exports of the relevant subtrees, or use backups taken on a fixed schedule, and diff them to find entries that changed without a matching API record. Third, alert on direct writes to the directory, for example by forwarding directory access and modification entries and flagging writes from administrative sessions that did not come through the API. Confirm with your platform team which of these your directory logging actually produces and how much retention and storage they need.
What security, compliance and operations each need from the trail
Investigators need to answer a short list of questions quickly: who made the change, when, from which host, and what object was affected. A useful record ties each change to an authenticated identity, not only to a shared admin account, and shows the exact attribute or membership that moved. Be aware that changes made through the web UI or the API arrive at the server as HTTP requests, while changes made directly against the directory as root bypass that path entirely, so the trail for each channel must be checked separately.
- Actor: the Kerberos principal or session user that authenticated, plus any delegated or service account used by automation.
- Time: a timestamp with a consistent timezone across all IdM servers, which depends on chrony being healthy on every host.
- Source host: the client address that made the request, including whether a proxy or load balancer sat in front of the server.
- Object changed: the user, group, host, host group, HBAC rule, sudo rule or certificate profile, identified by its DN or name.
- Before and after values: where the channel records them, so an investigator can see a privilege grant rather than only that a request happened.
Confirm with your own test environment which of these fields each channel actually records before you write a detection rule that depends on them.",
Compliance leads usually need evidence that a control operated over a period, not a single log line. For access administration, that means showing that privileged changes were logged, that reviewers could see them, and that the records were kept for the period your policy or assessor requires. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors decide whether the evidence is sufficient.
- Control mapping: a written link from each logging requirement in your framework to the log source, the field, and the person who reviews it.
- Operating evidence: samples of change records and review sign-offs across the assessment period, not only a configuration screenshot.
- Retention: a retention period set by your policy and legal team, with the storage location and deletion process documented.
- Scope statement: which IdM servers, which channels (web UI, API, direct LDAP as root) and which administrators are in scope.
- Exception handling: how out-of-band changes are detected and explained when they occur.
Ask your assessor which evidence format they accept before you build the reporting, because the format determines how much of the trail must be exported and preserved.",
Platform operators care about whether the trail survives normal operations: replication, server rebuilds, log rotation and restores. FreeIPA runs as a multi-master topology, so a change can originate on any replica, and the audit path must cover every server that accepts writes. Backups and restores add a further risk: the backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restoring must not silently erase or rewrite the local audit record. Plan for this before an incident forces the decision.
- Per-server capture: Apache access logs and any directory audit output collected on every replica, not only the first server.
- Off-host shipping: logs forwarded to storage that a local administrator cannot quietly edit, with write-once or append-only controls where your platform supports them.
- Clock discipline: time sources verified on every host so events from different servers can be ordered.
- Rotation rules: log rotation sized so that events are shipped before they are compressed or deleted locally.
- Restore procedure: a documented step that preserves the current audit store before any restore, and a test that checks the trail after a restore in a lab.
Confirm with your own environment how log files behave during a replica re-initialization, because the answer changes where you collect from.",
Reviewers who read the trail after the fact need records they can trust without rebuilding the environment. They need a predictable format, a way to find events for a given object across all servers, and confidence that the record was not edited after the event. Their questions are often narrow: did this administrator grant themselves a role, did a host get added to a sensitive host group, did anyone touch a certificate profile during a maintenance window.
- Searchable index: events indexed by object, actor and time so a reviewer can answer a single question without reading raw files.
- Consistent identifiers: the same user and host names across servers, so events do not split across aliases.
- Review record: a dated, signed-off list showing who reviewed which period and what they found.
- Access to the trail: reviewers can read the logs but cannot change them, and their own reads are logged where your tooling allows.
- Gap reporting: a documented way to show periods where a server was down or a log source stopped.
Before a review cycle, pick a few known changes in your lab and confirm that a reviewer can trace each one from the object to the actor and source host.
Protecting audit logs from tampering and loss
An audit trail is only useful if it is complete, unaltered and available when someone asks what changed. The cards below cover the controls that keep FreeIPA logs trustworthy, from file permissions on the server to the people and clocks involved in reading them.
Restrict log file permissions
Apache access and error logs on each FreeIPA server record the API calls that administrators and tools make, so their files should be readable only by the accounts that need them. Check owner, group and mode on the Apache log directory after every package update or rebuild, because a changed mode can silently expose or lose records. Confirm that log rotation keeps the original ownership. Also confirm that unprivileged users on the server cannot truncate or replace the files.
Forward logs over protected transport
Copying logs off each server limits the damage if a host is compromised and an attacker edits local files. Send logs to a central collector over TLS with authenticated endpoints, and confirm that the forwarder retries and buffers when the collector is unreachable. Ask the collector team how gaps are reported, because a silent drop looks the same as a quiet day. Keep a local copy until the central copy is confirmed.
Separate log access from administration
The people who administer FreeIPA should not also be the only people who can read or delete its audit records. Give read access to the audit store to a separate group, such as security or compliance, and restrict deletion to a retention process. Review who holds root on the FreeIPA servers, since root can edit local logs and can also change directory data directly. Document this split in your access model so auditors can verify it.
Keep clocks synchronized
Investigators rely on timestamps to order a user change, a group change and a login, and FreeIPA runs Kerberos, which is sensitive to clock skew. Use the same time source on every server and client, and alert when offset grows. Check that Apache, the directory server and the forwarder all log in UTC or with explicit time zones. Mismatched clocks can make a correct sequence of events look reversed in a central search.
Verify log integrity
Detecting tampering needs a way to show that stored records have not changed. Options include hashing rotated files, signing batches, or writing to append-only storage with object lock, and each needs a documented owner and check schedule. Test the check by altering a copy of a file in a lab and confirming the alert fires. Record hashes or signatures in a location separate from the logs.
Track security releases when reading logs
FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws, and hardened authentication checks across the API. Before you trust an apparent sequence of changes, check the server version and the time of any upgrade, since an unpatched server may have accepted requests that a patched one rejects. Keep an upgrade record next to the audit store so reviewers can match log behavior to the software that produced it.
Questions teams ask before auditing FreeIPA changes
How much effort does it take to build a FreeIPA audit trail in-house?
Effort depends less on the FreeIPA software and more on how many paths can change your directory. A team needs to find every place a change can originate: the web UI and command line, API calls logged by the Apache web server in front of the API, and any direct LDAP writes made as root on a server. Each path has a different log location, format and retention behavior, so each one needs its own validation. Ask any provider to break its estimate down by these paths and by the number of servers that must be covered. Confirm the exact log locations and formats against the FreeIPA release you run, since they can change between versions.
What makes the audit work harder or easier to scope?
Four factors shape the work most:
- The number of replicas, since each server may hold local logs that must be collected and kept consistent.
- The number of administrative paths, including scripts, Ansible roles and any manual LDAP changes.
- SIEM integration, which depends on the log format your platform expects and how events must be parsed and tagged.
- Compliance evidence needs, such as which events must be retained, for how long, and how an auditor will sample them.
Each factor adds testing and documentation, not just configuration.
Can our own team build and run this audit trail without outside help?
Yes, a team with Linux, Apache and FreeIPA administration skills can build it, provided it has time to validate each change path and someone owns the result. The harder parts are proving completeness, handling direct LDAP access as root, and keeping the collection working after upgrades. Teams that lack a test server or a documented admin process often find gaps only during an audit. Outside help is most useful for a fixed-scope review of your admin paths, a tested collection design, and handover documentation your staff can operate.
What does the audit project need from our team?
Plan for three inputs before work starts. First, read access to the relevant logs on every FreeIPA server and to the central log platform where events will land. Second, a test FreeIPA environment that mirrors your production topology closely enough to prove that a change is recorded, so tests never run against live identity data. Third, named owners for each administrative process, such as the people who create accounts, change host policy or run ad hoc LDAP fixes. Those owners confirm which changes happen and when, which is the only reliable way to check coverage.
How long does it take to set up auditing, and what changes the timeline?
The timeline depends on scope, and no general duration is supplied here. The largest variables are the number of servers and replicas, how many administrative paths need validation, whether a SIEM integration must be built and accepted, and how much evidence must be documented for assessors. Access approvals and change windows on production servers often take longer than the technical work. Ask any provider for a written schedule tied to these variables and to the test environment you will provide.
What does a fixed-scope FreeIPA auditing engagement cover?
A fixed-scope engagement covers the agreed deliverables written down before work begins. Typically that means reviewing your administrative paths, configuring collection on the agreed servers, testing that representative changes are recorded and forwarded, and documenting how the trail is operated and reviewed. It does not include issuing audit reports or attestations, which independent auditors and certification bodies provide. Ongoing monitoring, log review and upgrade validation can be handled under a separate retainer if you want continued support.
Does DeployOpen issue compliance reports for our audit trail?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, including the audit trail records your assessor will review. Independent auditors and certification bodies make the determination and issue any reports or attestations. Ask your assessor early which evidence formats and retention periods they expect, so the design matches what they will sample.
Official FreeIPA references for this topic
Start with the FreeIPA About page to confirm which components sit under your deployment, since audit evidence for user, group, host and policy changes comes from the directory, the Kerberos KDC and the web and API layer. Then read the FreeIPA 4.13.4 release notes, which describe fixes to LDAP access control and hardened authentication checks across the API. Those fixes change what an unauthenticated or misconfigured client can do, so confirm the release on each server and record the version alongside any audit export you keep.
For the preservation question, read the backup documentation on the FreeIPA backup and restore page. It warns that restoring an outdated backup into an active replica topology can break replication. For auditing, this means a restore can roll back directory entries and make the record of who changed what look different from what was seen live. Agree with your team where audit logs are stored, whether they are included in the backup scope, and how a restore would be documented so the audit trail stays explainable.
Log locations, verbosity and field names vary between installed versions and between the Apache and directory layers, so treat the behavior described in any guide, including this one, as a starting point. Before you rely on a log for an audit, test a known change in a non-production deployment, confirm which log files record it, check whether the actor identity and the changed attribute appear, and confirm the result with the FreeIPA project documentation for your release.
