Mongodb – Access Control not logging successful logins on MongoDB 3.4 Community

authenticationlogmongodb-3.4Security

After adjust the verbosity of the parameter "accessControl" with the command:

db.setLogLevel(5,"accessControl")

The log file still not login successful login.

On mongo 3.2:

2017-04-20T15:56:06.661+0200 I ACCESS [conn16895093] Successfully authenticated as principal username on admin

On mongo 3.4: Only unsuccessful auth like:

2017-04-25T15:07:04.478+0200 I ACCESS [conn291586] SCRAM-SHA-1 authentication failed for username on admin from client 127.0.0.1:37171 ; 
AuthenticationFailed: SCRAM-SHA-1 authentication failed, storedKey mismatch

So I can NOT upgrade my environment from 3.2 to 3.4 safely.

I'm using MongoDB Community Version by repos:

Debian: deb ....//repo.mongodb.org/apt/debian jessie/mongodb-org/3.4 main
Ubuntu: deb [ arch=amd64,arm64 ] ...://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse

Env1:

root@mongo01 /var/log/mongodb # uname -srvio
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) unknown GNU/Linux
root@mongo01 /var/log/mongodb # mongo --version
MongoDB shell version v3.4.2
git version: 3f76e40c105fc223b3e5aac3e20dcd026b83b38b
OpenSSL version: OpenSSL 1.0.1t  3 May 2016
allocator: tcmalloc
modules: none
build environment:
    distmod: debian81
    distarch: x86_64
    target_arch: x86_64

env2:

santanaj@mongo02:~$ uname -srvio
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) unknown GNU/Linux
santanaj@mongo02:~$ mongod --version
db version v3.4.2
git version: 3f76e40c105fc223b3e5aac3e20dcd026b83b38b
OpenSSL version: OpenSSL 1.0.1k 8 Jan 2015
allocator: tcmalloc
modules: none
build environment:
    distmod: debian81
    distarch: x86_64
    target_arch: x86_64
santanaj@mongo02:~$ 

env3:

root@mongo05:/var/log/mongodb# uname -srvio
Linux 4.8.0-46-generic #49~16.04.1-Ubuntu SMP Fri Mar 31 14:51:03 UTC 2017 x86_64 GNU/Linux
root@mongo05:/var/log/mongodb# mongod --version
db version v3.4.4
git version: 888390515874a9debd1b6c5d36559ca86b44babd
OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016
allocator: tcmalloc
modules: none
build environment:
    distmod: ubuntu1604
    distarch: x86_64
    target_arch: x86_64

Example of log on Ubuntu: one login unsuccessful and next one successful :

2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten] MongoDB starting : pid=21951 port=27017 dbpath=/var/lib/mongodb 64-bit host=mongo05.pim.prod.win.windeln-it.de
2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten] db version v3.4.4
2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten] git version: 888390515874a9debd1b6c5d36559ca86b44babd
2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016
2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten] allocator: tcmalloc
2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten] modules: none
2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten] build environment:
2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten]     distmod: ubuntu1604
2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten]     distarch: x86_64
2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten]     target_arch: x86_64
2017-04-28T10:51:39.477+0200 I CONTROL  [initandlisten] options: { config: "/etc/mongod.conf", net: { bindIp: "0.0.0.0", port: 27017 }, security: { authorization: "enabled" }, storage: { dbPath: "/var/lib/mongodb", journal: { enabled: true }, wiredTiger: { engineConfig: { cacheSizeGB: 4.0 } } }, systemLog: { destination: "file", logAppend: true, logRotate: "rename", path: "/var/log/mongodb/mongod.log", quiet: true } }
2017-04-28T10:51:39.501+0200 I -        [initandlisten] Detected data files in /var/lib/mongodb created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2017-04-28T10:51:39.501+0200 I STORAGE  [initandlisten] 
2017-04-28T10:51:39.501+0200 I STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2017-04-28T10:51:39.501+0200 I STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem
2017-04-28T10:51:39.501+0200 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=4096M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),
2017-04-28T10:51:40.739+0200 I FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '/var/lib/mongodb/diagnostic.data'
2017-04-28T10:51:40.739+0200 I NETWORK  [thread1] waiting for connections on port 27017
2017-04-28T10:53:27.906+0200 I NETWORK  [conn3] received client metadata from 127.0.0.1:43314 conn3: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.4.4" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
2017-04-28T10:53:27.920+0200 I ACCESS   [conn3] SCRAM-SHA-1 authentication failed for jeferson on admin from client 127.0.0.1:43314 ; AuthenticationFailed: SCRAM-SHA-1 authentication failed, storedKey mismatch
2017-04-28T10:53:35.048+0200 I NETWORK  [conn4] received client metadata from 127.0.0.1:43316 conn4: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.4.4" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
root@mongo05:/var/log/mongodb# 

The successful does not show the username. I just tested on Community version is it possible to have differences between Community and Enterprise version about LOG verbosity aspects?

Best Answer

I found the problem:

The systemctl call by default uses:

/usr/bin/mongod --quiet --config /etc/mongod.conf

After some testing I changed this to

/usr/bin/mongod --config /etc/mongod.conf

Procedures to change systemctl on Ubuntu:

Edit: /etc/systemd/system/multi-user.target.wants/mongod.service

Change: ExecStart=/usr/bin/mongod --config /etc/mongod.conf

Run: systemctl daemon-reload

And the problem was solved!