MongoDB audit logging is Enterprise only

The fix/etc/mongod.conf

# Enterprise only — this will not start on Community:
# auditLog:
#   destination: file
#   format: JSON
#   path: /var/log/mongodb/audit.json

# What Community actually gives you:
systemLog:
  destination: file
  path: /var/log/mongodb/mongod.log
  logAppend: true
  verbosity: 0
  component:
    accessControl:
      verbosity: 1

The thing to know first

MongoDB’s auditing facility is Enterprise only. It is not available in Community Edition — not disabled by default, not behind a flag. The feature isn’t in the binary.

This is worth stating plainly because “enable audit logging” appears on nearly every MongoDB hardening checklist, generally without mentioning that following it requires MongoDB Enterprise Advanced or Atlas. If you’re running the Community edition you installed from MongoDB’s repo, auditLog in your config will stop the server from starting, and that is the only feedback you get.

If you genuinely need auditing for a compliance obligation, that is a purchasing decision, not a configuration one. Knowing that now is cheaper than finding out during an audit.

What Community actually gives you

Less than an audit log, but not nothing:

Authentication events in mongod.log. Successful and failed authentications are logged by the accessControl component. Raising that component’s verbosity to 1 gets you connection and authentication detail without the firehose of raising global verbosity. This is the closest thing to an authentication audit trail you have, and it is genuinely useful during an incident.

The profiler, with caveats. db.setProfilingLevel(2) records every operation into system.profile. It is built for performance analysis, not security, and it shows:

db.setProfilingLevel(2)
db.system.profile.find().sort({ ts: -1 }).limit(5).pretty()

Understand what you’re accepting before leaving it on:

• It is per-database, so you’d enable it everywhere and check everywhere.
• It costs performance on every operation.
• It writes your queries into a collection — including their filter values. That means personal data, tokens and anything else in a query predicate now lives in system.profile, which is inside the database with its own access rules and gets picked up by your backups. You may have created a disclosure problem while trying to create an audit trail.
• It is a capped collection, so it silently discards the oldest entries. It cannot answer “what happened last Tuesday”.

That last point is the one that matters: a capped, rotating buffer is not an audit log, and treating it as one will fail you exactly when you need it.

Why this is low

It closes no exposure. Nothing on this page makes an attack harder — it changes what you can reconstruct afterwards. That’s real value during an incident and zero value before one, which is what low means here.

Order matters more than completeness: authorization, binding and roles prevent the incident. This one only helps you write it up.

Verify it worked

Confirm which edition you’re running — this settles whether the rest of the page applies:

db.version()
db.serverBuildInfo().modules

modules: [] is Community. modules: [ "enterprise" ] is Enterprise.

Check your log is going where you think:

db.adminCommand({ getCmdLineOpts: 1 }).parsed.systemLog

Then confirm authentication events are actually recorded — connect with a wrong password and look:

mongosh -u app -p definitely-wrong --authenticationDatabase admin --quiet --eval 'db.version()' 2>/dev/null
sudo grep -i 'Authentication failed' /var/log/mongodb/mongod.log | tail -3

If nothing appears, you have no record of failed authentication at all — that is the finding, and it is fixable with the verbosity setting above.

Check the profiler isn’t quietly on in production:

db.getProfilingStatus()

Expect { was: 0, ... }. Anything else is costing you performance and possibly storing query values.

Before you apply this

Putting auditLog in a Community config stops the server from starting. The error names an unrecognised option, which is clear enough — but if you added it during a maintenance window along with five other changes, you’ll spend the window bisecting a config rather than reading it. Confirm your edition first.

Don’t leave the profiler at level 2. Beyond performance, it writes query predicates into system.profile, which:

• lands in your backups, spreading whatever was in those predicates;
• is readable by anyone with dbAdmin or read on that database, which is a wider group than you’d grant to the underlying data;
• fills a capped collection and rotates away, so it gives false confidence.

Use it briefly, on staging, for a specific question. Turn it off after:

db.setProfilingLevel(0)
db.system.profile.drop()

Log verbosity has a disk cost. accessControl at verbosity 1 is modest, but global verbosity above 0 on a busy server produces a lot of log. A full disk takes the database down — which would make this the only page here that causes the incident it was meant to help you investigate. Set up rotation:

systemLog:
  logRotate: reopen

and confirm logrotate is handling the file.

Related

• Enable authorization — there is nothing to log until users exist.
• MongoDB exposed to the internet — where you’ll wish you had this.