Thanks for offering your help @dschupp.
It’s an odd situation I’m in… Everything looks to be in order, except for the fact that MongoDB can’t auth my user. Here’s the setup.
On the Active Directory domain controller:
PS C:\users\Tess\Documents> setspn -Q mongodb/database.m310.mongodb.university
Checking domain DC=corp,DC=broehaha,DC=nl
CN=svc-mongo,CN=Users,DC=corp,DC=broehaha,DC=nl
mongodb/database.m310.mongodb.university
Existing SPN found!
The keytab for the user was created as follows:
ktpass /out m310.keytab /princ mongodb/database.m310.mongodb.university@CORP.BROEHAHA.NL /mapuser svc-mongo /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /pass PASSWORDHIDDEN
The user account in AD (svc-mongo) was configured to allow AES256 Kerberos auth.
My Kerberos config on the Vagrant box is plain:
vagrant@database:~$ cat /etc/krb5.conf
[libdefaults]
default_realm = CORP.BROEHAHA.NL
[realms]
CORP.BROEHAHA.NL = {
kdc = corp.broehaha.nl
admin_server = corp.broehaha.nl
}
[domain_realm]
.corp.broehaha.nl = CORP.BROEHAHA.NL
corp.broehaha.nl = CORP.BROEHAHA.NL
[logging]
default = FILE:/var/log/krb5.log
And authenticating both my own user and the SPN for MongoDB works fine:
vagrant@database:~$ kinit -k -t "/etc/m310.keytab" mongodb/database.m310.mongodb.university@CORP.BROEHAHA.NL -V
Using default cache: /tmp/krb5cc_1000
Using principal: mongodb/database.m310.mongodb.university@CORP.BROEHAHA.NL
Using keytab: /etc/m310.keytab
Authenticated to Kerberos v5
And in another user’s window:
root@database:~# kinit tess@CORP.BROEHAHA.NL -V
Using default cache: /tmp/krb5cc_0
Using principal: tess@CORP.BROEHAHA.NL
Password for tess@CORP.BROEHAHA.NL:
Authenticated to Kerberos v5
Starting MongoDB doesn’t show errors:
vagrant@database:/etc$ mongod --auth --setParameter authenticationMechanisms=GSSAPI --dbpath /data/db
2018-11-21T21:36:10.524+0100 I CONTROL [initandlisten] MongoDB starting : pid=1970 port=27017 dbpath=/data/db 64-bit host=database
2018-11-21T21:36:10.525+0100 I CONTROL [initandlisten] db version v3.2.21
2018-11-21T21:36:10.526+0100 I CONTROL [initandlisten] git version: 1ab1010737145ba3761318508ff65ba74dfe8155
2018-11-21T21:36:10.526+0100 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.1f 6 Jan 2014
2018-11-21T21:36:10.527+0100 I CONTROL [initandlisten] allocator: tcmalloc
2018-11-21T21:36:10.528+0100 I CONTROL [initandlisten] modules: enterprise
2018-11-21T21:36:10.529+0100 I CONTROL [initandlisten] build environment:
2018-11-21T21:36:10.529+0100 I CONTROL [initandlisten] distmod: ubuntu1404
2018-11-21T21:36:10.530+0100 I CONTROL [initandlisten] distarch: x86_64
2018-11-21T21:36:10.530+0100 I CONTROL [initandlisten] target_arch: x86_64
2018-11-21T21:36:10.530+0100 I CONTROL [initandlisten] options: { security: { authorization: "enabled" }, setParameter: { authenticationMechanisms: "GSSAPI" }, storage: { dbPath: "/data/db" } }
2018-11-21T21:36:10.556+0100 I - [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2018-11-21T21:36:10.556+0100 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=1G,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),verbose=(recovery_progress),
2018-11-21T21:36:10.651+0100 I STORAGE [initandlisten] WiredTiger [1542832570:651931][1970:0x7f440b3edd00], txn-recover: Main recovery loop: starting at 14/6400
2018-11-21T21:36:10.705+0100 I STORAGE [initandlisten] WiredTiger [1542832570:705762][1970:0x7f440b3edd00], txn-recover: Recovering log 14 through 15
2018-11-21T21:36:10.707+0100 I STORAGE [initandlisten] WiredTiger [1542832570:707367][1970:0x7f440b3edd00], txn-recover: Recovering log 15 through 15
2018-11-21T21:36:10.804+0100 I CONTROL [initandlisten]
2018-11-21T21:36:10.805+0100 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2018-11-21T21:36:10.806+0100 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2018-11-21T21:36:10.807+0100 I CONTROL [initandlisten]
2018-11-21T21:36:10.807+0100 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2018-11-21T21:36:10.808+0100 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2018-11-21T21:36:10.809+0100 I CONTROL [initandlisten]
2018-11-21T21:36:10.812+0100 I NETWORK [HostnameCanonicalizationWorker] Starting hostname canonicalization worker
2018-11-21T21:36:10.813+0100 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2018-11-21T21:36:10.814+0100 I NETWORK [initandlisten] waiting for connections on port 27017
But in the end, authenticating my own user account barfs, because AD tells me it can’t find an SPN for the service:
root@database:~# mongo --host localhost:27017
MongoDB shell version: 3.2.21
connecting to: localhost:27017/test
MongoDB Enterprise > use $external
switched to db $external
MongoDB Enterprise > db.auth({mechanism:"GSSAPI", user:"tess@CORP.BROEHAHA.NL"})
Error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
0
Originally I thought this could be down to timing issues, as the Vagrant VM was set to a different timezone. Fixing that did not alleviate the problem.
Also considered that it could be an issue with name resolution, so I made sure that both the Vagrant VM and the domain controller could resolve eachother’s FQDN and IP. But the problem persists.
Is there a spot where I can debug MongoDB’s authentication to the AD KDC? There are no errors on the mongodb output, no errors in /var/log/messages or syslog. It’s oh-so-strange!
He actually does not show the mongo shell invocation in the video, but skips over it.
