Homework 1.6 Authentication Failed

MongoDB University M310: MongoDB Security
#1

I am getting Authentication failed after creating adam user for Homework 1.6
I am able to run the testsaslauthd command successfully

0: vagrant@database:~/M310-HW-1.6$ sudo chmod 755 /var/run/saslauthd/
vagrant@database:~/M310-HW-1.6$ testsaslauthd -u adam -p password -f /var/run/saslauthd/mux
0: OK "Success."

I start my replSets with the necessary parameters to enable ldap mechanism (I believe)

REDACTED

I am able to connect, initiate the replSet primary and create the adam user

However when I attempt to authenticate I am getting:

MongoDB Enterprise hw16Repl:PRIMARY> db.getSiblingDB("$external").auth({ mechanism: "PLAIN", user: "adam", pwd: "password", digestPassword: false})
Error: Authentication failed.
0

I have completely removed the dbs and attempted again making sure I wasn’t missing anything or having any typos but I get the same result. I did run the setup file on the infrastructure server as well and I even changed the password using the python command to webscale and back to password. If I attempt to run the setup again it states everything already exists, which indicates it ran correctly the first time.

In case it helps here is my saslauthd.conf

ldap_servers: ldap://infrastructure.m310.mongodb.university
ldap_search_base: ou=Users,dc=mongodb,dc=com
ldap_filter: (cn=%u)

I have watched the relevant video a few times again to make sure I wasn’t missing anything but I am stumped.
Any help is greatly appreciated!

1 Like
#2

Hi Chris ,

I had to redact a lot of your post - we don’t want to post answers or potential answers.

I would double check that you can still successfully run testsaslauthd.

Depending on your steps - whether you’ve stopped and started sessions/VMs permission may have been reset or ldap service may have stop on infrastructure, etc.

Note / Hint : I don’t believe the following hint is your issue as posted above; however I did noticed an issue that would have appeared once you’ve authenticated, so keep in mind that LDAP is an external authentication mechanism only.

Hope this helps,

David

1 Like
#3

Sorry for potentially sharing answer info, I will try and keep an eye on that in the future!

Found my issue was with a tiny little typo :confused: (saslauthdb needed to be saslauthd in my mongod initilization) after fixing that I was able to add the user and authenticate in mongo.

However, now when I attempt to run the validation script I get the below which is reported as wrong for the homework, so hopefully since it is confirmed wrong won’t be a problem to have posted here. I can successfully run testsaslauthd, connect to each member of the replSet and they show the correct member state, I can authenticate with the ldap server using adam and authentication will fail if I change the password on the ldap server and attempt to use an old password with mongo which shows mongod is connecting properly to ldap. I am not sure why the validation would be failing since everything seems to be working as requested by the homework.
I noticed that it mentions Failed to connect to 127.0.0.1:31160 but I use database.m310.mongodb.university for the host everywhere, would this be a problem?

vagrant@database:~/shared$ ./validate-hw-1.6.sh
exception: connect failed
exception: connect failed
{ unauthorizedStatus: 2018-11-19T15:50:16.057+0000 W NETWORK [thread1] Failed to connect to 127.0.0.1:31160, in(checking socket for error after poll), reason: errno:111 Connection refused 2018-11-19T15:50:16.058+0000 E QUERY [thread1] Error: couldn't connect to server 127.0.0.1:31160, connection attempt failed : connect@src/mongo/shell/mongo.js:231:14 @(connect):1:21, memberStatuses: 2018-11-19T15:50:16.118+0000 W NETWORK [thread1] Failed to connect to 127.0.0.1:31160, in(checking socket for error after poll), reason: errno:111 Connection refused 2018-11-19T15:50:16.118+0000 E QUERY [thread1] Error: couldn't connect to server 127.0.0.1:31160, connection attempt failed : connect@src/mongo/shell/mongo.js:231:14 @(connect):1:21 }
#4

Hi Chris,

Glad you found that typo !

I usually associate that message to not having a server running on that port.

What is the output of rs.status() ?

Thanks

David

#5

Here is the rs.status()

MongoDB Enterprise hw16Repl:PRIMARY> rs.status()
{
	"set" : "hw16Repl",
	"date" : ISODate("2018-11-19T20:14:09.654Z"),
	"myState" : 1,
	"term" : NumberLong(1),
	"heartbeatIntervalMillis" : NumberLong(2000),
	"members" : [
		{
			"_id" : 0,
			"name" : "database.m310.mongodb.university:31160",
			"health" : 1,
			"state" : 1,
			"stateStr" : "PRIMARY",
			"uptime" : 17102,
			"optime" : {
				"ts" : Timestamp(1542641650, 4),
				"t" : NumberLong(1)
			},
			"optimeDate" : ISODate("2018-11-19T15:34:10Z"),
			"electionTime" : Timestamp(1542641395, 1),
			"electionDate" : ISODate("2018-11-19T15:29:55Z"),
			"configVersion" : 1,
			"self" : true
		},
		{
			"_id" : 1,
			"name" : "database.m310.mongodb.university:31161",
			"health" : 1,
			"state" : 2,
			"stateStr" : "SECONDARY",
			"uptime" : 17065,
			"optime" : {
				"ts" : Timestamp(1542641650, 4),
				"t" : NumberLong(1)
			},
			"optimeDate" : ISODate("2018-11-19T15:34:10Z"),
			"lastHeartbeat" : ISODate("2018-11-19T20:14:08.867Z"),
			"lastHeartbeatRecv" : ISODate("2018-11-19T20:14:08.499Z"),
			"pingMs" : NumberLong(0),
			"syncingTo" : "database.m310.mongodb.university:31162",
			"configVersion" : 1
		},
		{
			"_id" : 2,
			"name" : "database.m310.mongodb.university:31162",
			"health" : 1,
			"state" : 2,
			"stateStr" : "SECONDARY",
			"uptime" : 17065,
			"optime" : {
				"ts" : Timestamp(1542641650, 4),
				"t" : NumberLong(1)
			},
			"optimeDate" : ISODate("2018-11-19T15:34:10Z"),
			"lastHeartbeat" : ISODate("2018-11-19T20:14:08.867Z"),
			"lastHeartbeatRecv" : ISODate("2018-11-19T20:14:09.447Z"),
			"pingMs" : NumberLong(0),
			"syncingTo" : "database.m310.mongodb.university:31160",
			"configVersion" : 1
		}
	],
	"ok" : 1
}

Thanks again for the help!

#6

Hi Chris,

Everything looks good on your replica set cluster and it seems you can connect, authenticate, and run rs.status from the mongo shell - so why can’t the validate script do the same ?

And you’re executing the validate script on the database server ? It’s like you have two different database hosts. Very odd. I don’t think it’s anything to do with the mongods or saslauthd. If you want you can private message with the mongod options, I believe if you click on my “D” icon there is a link to send message.

David

#7

Hey David,
I think I figured it out. I had to update the validation file to use the --host option. Also, it wouldn’t let me message you but perhaps it won’t be needed now.
I had a suspicion this might be the case as the info of needing to specify a host came up in another lesson but wasn’t actually mentioned on the homework or in the videos(I think I got that from you on a different answer maybe). After having the script use the host I get the desired response and confirm that it shows as the correct answer on the homework.
Here is the new validate-hw-1.6.sh:

#!/bin/bash

primaryPort=31160
host="database.m310.mongodb.university"

username="adam"
password="webscale"


statusStr="var status = rs.status();
           delete status.codeName;
           print(JSON.stringify(status))"
memberStr="db = db.getSisterDB('\$external');
           db.auth({
             mechanism: 'PLAIN',
             user: '$username',
             pwd: '$password',
             digestPassword: false
           });
           var status = rs.status();
           var statuses = status.members.map((member) => (member.stateStr)).sort();
           print(JSON.stringify(statuses));"

function mongoEval {
  local port=$1
  local script=$2
  local host=$3
  echo `mongo --quiet --port $port --host $host --eval "$script"`
}

function getUnauthorizedStatus {
  local port=$1
  local host=$2
  echo $(mongoEval $port "$statusStr" $host)
}

function getMemberStatuses {
  local port=$1
  local host=$2
  echo $(mongoEval $port "$memberStr" $host)
}

echo "{ unauthorizedStatus: $(getUnauthorizedStatus $primaryPort $host), memberStatuses: $(getMemberStatuses $primaryPort $host) }"

Since I used the --host option when creating my mongod instances and that caused the homework to fail initially, should I have not done that?

Thanks again,
Chris

#8

Hi Chris,

I’m glad you got it working !

If you’re referring to the bind_ip option it’s a good security practice to implement. Note: In this class we’re using MongoDB 3.2 the default behavior for this option was changed beginning in 3.6.

bind_ip

As for this class and the validation scripts whether it will be an issue will depend on the assignments and what IP/hostname you’re using. With that in mind you may decide not to use the option for the assignments.

David

#9

you could also use comma separated list of domains include localhost, like:
– bind_ip `database.m310.mongodb.university, localhost

#10

This entire dialog was really valuable. Thanks Christopher_79126 for asking the right questions, and dschupp for your responses.

1 Like