What this check reads
Greps /etc/mongod.conf for a line matching ^[[:space:]]*authorization:[[:space:]]*enabled (the security.authorization YAML key), reading the file through the script's root helper because it is not world-readable. The pattern is anchored to the start of the line but allows leading whitespace, so the normal indented form under security: matches while a commented-out # authorization: enabled does not. One matching line is the PASS; no match anywhere in the file is the FAIL.
When it applies
Runs only when MongoDB is detected (HAS_MG=1: a mongod binary, a running mongod, or /etc/mongod.conf). It then needs /etc/mongod.conf to exist at that exact path (MGCONF) - any other config location yields WARN - and root/sudo to read it, otherwise SKIP. This is a config-file grep only: the script never connects to the server, so authorization enabled by a command-line flag or by a replica-set keyFile is not seen.
What each result means
| Result | When | What it means |
|---|---|---|
| SKIP | MongoDB not installed | Nothing was checked. No mongod binary, process or config file was found on this host. |
| WARN | `mongod` present but `/etc/mongod.conf` missing | MongoDB is here but its config was not, so authorization is unconfirmed in either direction. Check whichever file your instance actually loads. |
| PASS | `authorization: enabled` found | The config on disk demands credentials. Confirm mongod was restarted after the line was added. |
| FAIL | Not found | As configured, every client that can reach the port has full admin access to every database. |
| SKIP | No root to read the file | Nothing was read. The file is there but was unreadable, so this is not a pass. |
Why it matters
MongoDB ships with access control disabled. Without security.authorization: enabled every client that reaches the port has full admin rights. This, combined with binding to 0.0.0.0, produced the 2017 "MongoDB ransom" wave where tens of thousands of databases were wiped. MongoDB Security Checklist item 1: "Enable Access Control and Enforce Authentication". CIS MongoDB: "Ensure authentication is enabled".
Why it fails, and when it is wrong
- Server started with
mongod --authon the command line (systemd unit override) or with--keyFile/security.keyFilein a replica set: both enforce authorization but are not matched by the grep. False FAIL. - Config at a non-default path (
/etc/mongodb.conf,/opt/mongo/mongod.conf) gives WARN "not found". Checkps -o args -C mongodfor-f/--config. - Commented-out
# authorization: enabledis correctly ignored. - Indented under
security:is the normal form and is matched.
How to fix it
Create the MongoDB admin user first
Do this while authorization is still off, otherwise you lock yourself out.
use admin
db.createUser({user:"admin", pwd: passwordPrompt(), roles:[{role:"userAdminAnyDatabase",db:"admin"},"readWriteAnyDatabase"]})Enable MongoDB authorization
In /etc/mongod.conf:
security:
authorization: enabledThen systemctl restart mongod, because the check reads the file but the server only enforces what it loaded at startup.
Give Redis a credential
Redis on the same host has the same default and is worth doing in the same change. Set a requirepass in /etc/redis/redis.conf, or an ACL with a user line or an aclfile, then systemctl restart redis.
requirepass a-long-random-string-not-a-wordUpdate every client
Both changes break existing connections the moment the service restarts, so update application connection strings first, not after. Then confirm the credential works:
mongosh -u admin --authenticationDatabase adminVerify the fix
# Ask the running server, which is authoritative:
mongosh --quiet --eval 'db.adminCommand({getParameter:1, authenticationMechanisms:1})'
# On an auth-enabled server an unauthenticated admin command is refused:
mongosh --quiet --eval 'db.adminCommand({listDatabases:1})'
# expected: MongoServerError ... requires authentication
# And an authenticated connection works:
mongosh -u admin --authenticationDatabase admin --quiet --eval 'db.adminCommand({listDatabases:1})'Debugging
Confirm with command -v mongod; pgrep -a mongod; ls /etc/mongod.conf.
The file exists but the audit account cannot read it. sudo grep -n authorization /etc/mongod.conf.
The server uses a different config path. Find the real one with ps -o args= -C mongod and look for -f/--config. The check only ever reads /etc/mongod.conf, so a server configured elsewhere cannot produce PASS.
This is the known blind spot. If mongod is started with --auth, or the replica set uses security.keyFile (which implies authorization), the grep finds nothing. Confirm real enforcement with the mongosh command above and record the finding as a false positive. Setting security.authorization: enabled explicitly in /etc/mongod.conf both documents the intent and clears the check.
The config was changed and not restarted. systemctl restart mongod, then retest with mongosh.
Sources
- MongoDB: Security Checklist
- MongoDB: Enable Access Control (self-managed)
- MongoDB: Configuration File Options,
security.authorization - MongoDB: Internal/Membership Authentication (keyFile implies auth)
- Background on the open-MongoDB ransom wave
How the script reads this
Next
Re-run the Authentication audit after applying the fix and confirm this check moves to PASS. CtrlOps runs all 8 checks over your existing SSH connection and scores the result, so the change is visible without reading another config file.
All 8 Authentication fixes