Ensure auditd Service Is Enabled: How to Fix It on RHEL and Ubuntu

“Ensure auditd service is enabled” is a CIS Level 2 Linux check that fails when the Linux audit daemon is missing, disabled at boot or, in newer benchmark versions, not running. Fix it by installing the audit package, running systemctl –now enable auditd, adding audit=1 to the kernel command line, rebooting and rescanning.

The daemon part takes a minute. The details that trip people up are the kernel parameter, a stray audit=0 that silently keeps the service from starting, and the fact that Red Hat and Debian ship different service units.

What the scanner is actually detecting

This finding comes from a Tenable compliance scan that runs a CIS Linux Level 2 audit file over an authenticated SSH session. It is a configuration check, not a vulnerability plugin, and there is no CVE behind it. The item number and exact wording change between benchmarks and versions, so search your report by title:

Older items only care whether the unit is enabled for boot. Newer ones are titled “enabled and active” and their remediation unmasks, enables and starts auditd, so a host that is enabled but not running still fails. On the host, that is what systemctl is-enabled auditd and systemctl is-active auditd report.

The same audit section usually contains companion items that fail alongside this one: “Ensure auditd packages are installed” (or “Ensure auditd is installed”), “Ensure auditing for processes that start prior to auditd is enabled” (the audit=1 kernel parameter) and “Ensure audit_backlog_limit is sufficient”. Fixing all of them in one change window saves a second reboot.

Real-world risk, stated honestly

A disabled auditd is not something an attacker can exploit. It is a visibility gap. auditd is the userspace component of the Linux Auditing System and writes audit records to disk, by default to /var/log/audit/audit.log. The CIS rationale is that those records let administrators determine whether unauthorized access is happening.

Without the daemon, the audit rules that the rest of the benchmark asks for (changes to identity files, sudoers, privileged commands and so on) produce no audit trail, so an incident responder has less evidence to work with. That matters most on servers where you already need to answer “who did what, and when”. It does not make the host more likely to be breached on its own, and it should be prioritized below exploitable vulnerabilities on the same system.

How to confirm it on the host

Run these as an administrator:

# Is the unit installed, enabled at boot and running?
systemctl is-enabled auditd
systemctl is-active auditd

# Kernel audit status (needs root)
sudo auditctl -s

# Was the kernel booted with audit=1, or with audit=0?
cat /proc/cmdline

# Is the package installed?
rpm -q audit audit-libs          # RHEL, Rocky, AlmaLinux, Oracle Linux
dpkg -s auditd | grep Status     # Debian, Ubuntu

How to read the results:

• is-enabled prints enabled when it is set to start at boot. disabled or masked fails the check, and an error saying the unit file does not exist means the package is not installed.
• is-active should print active.
• auditctl -s reports the kernel audit status. enabled 1 means auditing is on, enabled 2 means on and locked (immutable until reboot), and pid should be the auditd process ID rather than 0. lost counts discarded records.

How to fix it

RHEL 8 and 9, Rocky Linux, AlmaLinux, Oracle Linux

Install the packages, then unmask, enable and start the service:

sudo dnf install audit audit-libs
sudo systemctl unmask auditd
sudo systemctl enable auditd
sudo service auditd start

The CIS remediation text uses systemctl –now enable auditd, which enables and starts it in one step. Red Hat’s own documentation says the service command is the only way to correctly interact with auditd, so that the auid of the administrator is recorded properly, and limits systemctl to enable and status. Either route passes the check. The Red Hat route gives cleaner audit records of who started the daemon.

Next, turn on auditing for processes that start before auditd does:

sudo grubby --update-kernel ALL --args 'audit=1'
sudo grubby --info=ALL | grep -E '^(kernel|args)'

The CIS RHEL 9 v2.0.0 remediation also tells you to add audit=1 to the GRUB_CMDLINE_LINUX= line in /etc/default/grub, keeping any existing parameters, so that a later regeneration of the GRUB configuration does not drop it:

GRUB_CMDLINE_LINUX="quiet audit=1"

If you are also fixing the backlog item, add the parameter the same way. 8192 is the example value in the CIS text:

sudo grubby --update-kernel ALL --args 'audit_backlog_limit=8192'

Reboot for the kernel parameters to take effect.

Ubuntu and Debian

Minimal Ubuntu and Debian installs often do not include auditd, so install it first:

sudo apt install auditd audispd-plugins
sudo systemctl unmask auditd
sudo systemctl --now enable auditd

Then edit /etc/default/grub and add audit=1 (and, if you are fixing that item too, audit_backlog_limit=8192) inside the quotes of GRUB_CMDLINE_LINUX, keeping anything already there:

GRUB_CMDLINE_LINUX="audit=1 audit_backlog_limit=8192"

sudo update-grub
sudo reboot

If the service is enabled but will not start

Check the kernel command line first. The upstream auditd unit carries ConditionKernelCommandLine=!audit=0 and !audit=off, so systemd quietly skips the service when the kernel was booted with auditing disabled. The kernel documentation is explicit that with audit=0, kernel audit “can not be enabled until the next reboot”. Remove it and reboot:

# RHEL family
sudo grubby --update-kernel ALL --remove-args 'audit=0'

# Debian and Ubuntu: delete audit=0 from /etc/default/grub, then
sudo update-grub

For any other failure, read the unit log with journalctl -u auditd -b. It usually points at a syntax error in /etc/audit/auditd.conf or a problem with the log directory.

How to verify the fix and rescan

After the reboot, run:

systemctl is-enabled auditd      # expect: enabled
systemctl is-active auditd       # expect: active
sudo auditctl -s                 # expect: enabled 1 (or 2), pid not 0
grep -o 'audit=1' /proc/cmdline  # expect: audit=1
sudo tail -n 3 /var/log/audit/audit.log

Then rerun the same compliance scan, with the same audit file and credentials, against the host. Confirm the companion items (packages, audit=1, backlog limit) changed state too. If you edited the kernel command line but have not rebooted yet, a live check of /proc/cmdline will still show the old value.

What can break and how to roll back

Starting auditd by itself rarely breaks anything. The risks come from what you configure around it:

• Disk usage: audit logs grow under /var/log/audit. How much disk they take depends on max_log_file, num_logs and max_log_file_action in /etc/audit/auditd.conf. Review them before you add a large rule set.
• Companion items that can halt a host: other CIS items in the same section set max_log_file_action = keep_logs and admin_space_left_action or disk_full_action to single or halt. With those in place, a full audit partition can drop the system into single user mode or shut it down. That is intended in high-security contexts, but it needs a separate /var/log/audit partition and monitoring.
• Lost boot events: with audit=1, the kernel buffers records in RAM until auditd starts, up to audit_backlog_limit, which defaults to 64. Anything beyond that during boot is lost, which is why CIS pairs the two items.
• Performance: overhead depends on the audit rules you load, not on the daemon itself. Test broad syscall rules on busy database or build hosts before you roll them out.

To roll back on RHEL-family systems, remember that systemctl stop auditd is refused there (the unit sets RefuseManualStop=yes). Use the service command:

sudo systemctl disable auditd
sudo service auditd stop
sudo grubby --update-kernel ALL --remove-args 'audit=1'

Debian’s package removes RefuseManualStop, so on Debian and Ubuntu:

sudo systemctl disable --now auditd
# remove audit=1 from GRUB_CMDLINE_LINUX in /etc/default/grub
sudo update-grub

Reboot for the kernel parameter change to take effect.

Common false positive reasons

• Scanning a container, not the host. Containers normally do not run their own auditd. Kernel auditing belongs to the host, so running a host CIS benchmark against a container image or a lightweight guest reports this item as failed.
• Insufficient scan privileges. Commands such as auditctl -s need root. If the scan account cannot escalate, results for the audit section can be wrong or incomplete. See our guide to setting up authenticated Linux scans with SSH and sudo.
• Another agent owns the audit stream. Elastic documents that Auditbeat in unicast mode needs other daemons such as auditd stopped, while multicast mode (kernel 3.16 and newer) runs alongside auditd. If a team disabled auditd for that reason, switch the agent to multicast or record a documented exception with the compensating control.
• Wrong profile. This is a Level 2 item. If the host was meant to be measured against Level 1 only, the failure is a policy mismatch in the scan configuration, not a host problem.

FAQ

Is systemctl enable auditd enough?

Not for newer benchmark versions. enable only affects the next boot, and “enabled and active” items also expect the daemon to be running now. Use –now or start the service, and fix the separate audit=1 item as well.

Do I need to reboot?

Not for the service itself. The audit=1 and audit_backlog_limit kernel parameters only take effect at the next boot.

Why does Red Hat say to use service instead of systemctl?

So that the audit trail records the real administrator’s auid when the daemon is started or stopped. On RHEL, systemctl stop auditd is refused outright.

Does auditd record anything without custom rules?

Some audit-aware programs, such as PAM-based login tools, send records on their own, but the detailed coverage CIS expects comes from the rules in its other audit items. Enabling the daemon is the foundation, not the whole control.

Tracking this finding across many hosts

On a large Linux estate, the hard part is catching hosts where auditd was enabled but never started, or where an old audit=0 keeps it down. If you use SITEY, you can upload the .nessus export from the compliance scan, have its AI draft a host-specific remediation script that runs only after a human approves it, deploy it through SITEY agents on Linux endpoints, and then re-test to verify the finding is closed. Duplicate findings are merged per scanner, not across scanners.

Sources

• Tenable: CIS Red Hat EL9 Server L2 v1.0.0, 4.1.1.4 Ensure auditd service is enabled
• Tenable: CIS Ubuntu Linux 22.04 LTS v2.0.0 L2 Server, 6.3.1.2 Ensure auditd service is enabled and active
• Red Hat: RHEL 9 Security hardening, Auditing the system
• Linux kernel documentation: kernel parameters, audit= and audit_backlog_limit=
• auditctl(8) manual page