Question

Could someone please shed some light on these mongodb 3.6.5 server log messages on the primary node of a 3-member replicaset? rs.status() says all the nodes are up and running but seeing a ton of (I)nformational logs.

2019-01-16T00:07:24.819+0000 I ACCESS [conn95] Unauthorized: not authorized on admin to execute command { replSetGetStatus: "1", $db: "admin", $clusterTime...

Was it helpful?

Solution

Unauthorized: not authorized on admin to execute command { replSetGetStatus: "1", $db: "admin", $clusterTime...

The message indicates there is a user or application trying to run the replSetGetStatus command without having the correct privileges.

This command returns the current state of your replica set from the point of view of the server that processed the command. If this error is logged frequently, it is likely the result of a monitoring script or agent.

You can track down the source by searching the MongoDB server logs for related connection history. The first few lines for a given connection ID will usually include client metadata (optional, so will vary by driver/application) as well as the username used with authentication enabled.

For example, using a Linux-like command line to find the first entries for conn95:

> grep conn95 mongod.log | head -2
2019-01-15T21:41:19.026+1100 I NETWORK  [conn95] received client metadata from 192.168.1.123:59354 conn95: { driver: { name: "PyMongo", version: "3.6.0" }, os: { type: "Darwin", name: "Darwin", architecture: "x86_64", version: "10.14.2" }, platform: "CPython 2.7.14.final.0", application: { name: "monitoring-agent v1.2.3-dev" } }
2019-01-15T21:41:19.027+1100 I ACCESS   [conn95] Successfully authenticated as principal monitoring-agent on admin

These log lines include the following info:

  • the connection originated from 192.168.1.123
  • the client application identified itself as monitoring-agent v1.2.3-dev
  • the application successfully authenticated as user monitoring-agent via the admin database

If this is an expected connection from a monitoring agent, the likely fix would be to grant a role which includes the required access for replSetGetStatus (for example, the built-in clusterMonitor role):

use admin;
db.grantRolesToUser("monitoring-agent", [{ role: "clusterMonitor", db: "admin" }]);

If the connection is unexpected, you could determine an appropriate action based on the source IP or other details. You may wish to shutdown a monitoring app that is no longer required or remove the associated user account and block connections via your firewall. See MongoDB Security Checklist for some available security measures to consider.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top