Kerberos authentication: user creation on Mongo side

In the video “Enabling Kerberos” @kirbyk shows the creation of a Mongo user for his Kerberos account.

https://university.mongodb.com/mercury/M310/2018_November/chapter/Chapter_1_Authentication/lesson/581823ce7a0f5e3959b4871d/tab/581823d339776e6fc5284372

You can see it around 04:35.

Right before creating the user, Kirby starts the MongoD with the GSSAPI authentication method and then “you can use the Mongo shell to connect to the MongoD”. He then switches to “$external” and enters the db.createUser() command.

All fine and dandy, but what I don’t understand is how he actually logs in to perform this step! :smiley: He actually does not show the mongo shell invocation in the video, but skips over it.

That’s a big shame because I’m lost. If the MongoD is set to GSSAPI and we’re about to create our first GSSAPI user account, isn’t that a deadlock?! How can you link your first Kerberos user if the daemon is already running in Kerberos-auth mode?

I’ve actually gotten things mostly working by using my testbed’s AD controller as the KDC. The “kinit” with the keytab works wonderfully and MongoD starts up just fine. I just am missing that one little step in-between.

@kirbyk or @dschupp , want to pitch in here please?

HA! I’ve answered my own question :smiley:

@kirbyk and @dschupp, there’s a fix needed in this chapter. The video does NOT make it clear that MongoD should be started with --auth, but without GSSAPI. And it also requires one internal user account that has userAdmin rights on $external (or more, like root on admin).

Once I had my normal userAdmin account setup I could create the Kerberos user in $external just fine.

EDIT:
Mind you, it still doesn’t work for me :smiley: When running the db.auth() for my own user account it still returns “GSSAPI Error […] Server not found in Kerberos database”. Which is odd, because the following worked without failure:

kinit -k -t "/etc/m310.keytab" mongodb/database.m310.mongodb.university@MYDOMAIN.LOCAL

Hi Tess,

That’s a big shame because I’m lost. If the MongoD is set to GSSAPI and we’re about to create our first GSSAPI user account, isn’t that a deadlock?! How can you link your first Kerberos user if the daemon is already running in Kerberos-auth mode?

I would think Kirby’s is using the local host exception to create the first user.

I will verify with Kirby.

You probably double checked the steps - there is a lot of them ! - But I’ll mention a few that seem relevant.

  • authenticated to Kerberos: kinit user
  • krb5.conf
    • [default_realm]
    • [realms]
    • [domain_realm]

If you want to post screen shots of file configurations I can look for any potential typos / syntax issues.

David

That’s what I expected as well, but for some reason I could not use the local host exception to edit $external. It could have been an error on my side, but in the end I had to disable GSSAPI on startup, then use the local host exception to login and make a root account on “admin”, after which I could use the root account to edit $external. Only at the end could I restart MongoD with GSSAPI enabled.

I’ll get back to you on my other tests.

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!

Hi Tess,

I was able to duplicate Kirby’s steps.

A summary of the steps I took

  • I reviewed the vagrant provisioning scripts, both provision-infrastructure and provision-database, they have kerberos install and config steps - that had been commented out. I executed the steps “manually”. So that’s how I configured Kerberos.

  • I then followed the steps in the lesson.

What wasn’t in the lesson was launching the mongo shell. I reviewed the documentation

https://docs.mongodb.com/manual/tutorial/control-access-to-mongodb-with-kerberos-authentication/index.html

I think I would remove the bind_ip option from the mongod for now - and I would use the FQDN for the mongo host option.

Note: I was able to use the local host exception to create the user. I had no previous user created.

Also, you can increase the verbosity of the logs per component with

db.setLogLevel()

https://docs.mongodb.com/manual/reference/log-messages/index.html

David

My MongoD call did not have a bind_ip option to begin with, so there’s nothing to remove :smiley:

But you did make me think of something!! I actually added the bind_ip field to the MongoD startup!

vagrant@database:~$ mongod --auth --bind_ip database.m310.mongodb.university --setParameter authenticationMechanisms=GSSAPI --dbpath /data/db

And then in the other window:

root@database:~# mongo --host database.m310.mongodb.university:27017
MongoDB shell version: 3.2.21
connecting to: database.m310.mongodb.university:27017/test
MongoDB Enterprise > use $external
switched to db $external
MongoDB Enterprise > db.auth({mechanism:"GSSAPI", user:"tess@CORP.BROEHAHA.NL"})
1

ventage-bingo

So what was going wrong? By not adding the bind_ip directive, MongoD was running on localhost. Thus, despite having the right keytab it was not identifying as mongodb/database.m310.mongodb.university, but as mongodb/localhost.

I’ll make a short write-up for my blog about how I got this to work with Active Directory :slight_smile:

Here we go! My blog post about configuring MongoDB and Active Directory for Kerberos auth.

https://www.kilala.nl/index.php?id=2437