[SERVER-34267] Undesirable behaviour when using local authz with manually defined roles Created: 03/Apr/18  Updated: 27/Oct/23  Resolved: 22/May/18

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 3.4.13
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Nishant Bhardwaj Assignee: Spencer Jackson
Resolution: Works as Designed Votes: 1
Labels: Authentication, LDAP
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: Linux
Steps To Reproduce:

Steps
1. User "uid=alice,ou=Users,dc=mongodb,dc=com" created in ldap.

ldapadd -x -D "cn=Manager,dc=mongodb,dc=com" -w password -H ldapi:/// <<EOF
dn: uid=alice,ou=Users,dc=mongodb,dc=com
changetype: add
objectclass: person
objectclass: inetOrgPerson
cn: alice
sn: Alice
uid: alice
userPassword: secret
EOF

2. Following is the ldap configuration in mongod.conf

security:
  authorization: "enabled"
  ldap:
    transportSecurity: none
    servers: "127.0.0.1"
    bind: 
      queryUser: "cn=Manager,dc=mongodb,dc=com"
      queryPassword: "password"
setParameter:
   authenticationMechanisms: PLAIN

3. Using mongo shell, connect using a local userAdmin then create user in $external using internal authz by first using a local admin:

db.getSiblingDB("$external").createUser(
   { 
    user: "uid=alice,ou=Users,dc=mongodb,dc=com",
    roles: [ { role: "readWriteAnyDatabase", db: "admin" }]
 }
)

4. Now using mongo shell connect to this mongod instance using ldap user:

mongodb-linux-x86_64-enterprise-rhel62-3.4.13/bin/mongo --authenticationDatabase '$external' -u "uid=alice,ou=Users,dc=mongodb,dc=com" -p --authenticationMechanism PLAIN

5. Perform some CRUD operations using this user to confirm access.
6. From another ssh session, delete the user from ldap server:

ldapmodify -x -D "cn=Manager,dc=mongodb,dc=com" -w password -H ldapi:/// <<EOF
dn: uid=alice,ou=Users,dc=mongodb,dc=com
changetype: delete
EOF

6.. Authentication fails for any new sessions using this deleted ldap user:

Failed to bind to LDAP server at default: Invalid credentials. Bind parameters were: {BindDN: uid=alice,ou=Users,dc=mongodb,dc=com, authenticationType: simple}
2018-04-03T10:56:49.321+0000 I ACCESS   [conn29] PLAIN authentication failed for uid=alice,ou=Users,dc=mongodb,dc=com on $external from client 192.168.19.100:34012 ; OperationFailed: LDAP bind failed with error: Invalid credentials

7. Go back to the mongo shell with authenticated session (created in step4.) and the ldap user can still perform CRUD operations for almost infinite time.

Participants:

 Description   

ldapcacheinvalidation appears to only deal with external authz. So when using local authz with manually defined roles it creates undesirable behaviour related to security.

For an ldap user that has an authenticated session in MongoDB using $external and if this user is deleted on ldap server. Then the existing authenticated session remains unaffected and one can perform normal CRUD operations without any interruption.



 Comments   
Comment by Spencer Jackson [ 22/May/18 ]

Yes, this is works as designed. During LDAP authentication, the server forwards the provided plaintext credentials to the LDAP server, which validates them. After the LDAP server has granted access, the MongoDB server forgets the password it was provided, and is no longer able to validate the ability of the password to grant access to the user. The server also does not have a mechanism by which it can forcibly require a client to reauthenticate, short of terminating the connection. When the user entity is removed from the directory server, a description of the authorization rights remain in the $external database, and continue to be used for active authorization sessions, though new authentication attempts will fail. Because authentication and authorization are split in this deployment scenario, to complete the destruction of the user and all their active sessions, the user must be deleted from $external.To allow the destruction of users in the LDAP directory to revoke authorization privileges, the LDAP server must be made the source of authorization information, by enabling LDAP authorization.

Comment by Kelsey Schubert [ 04/Apr/18 ]

That matches my understanding as well.

spencer.jackson, would you confirm that this is WaD?

Comment by Andy Schwerin [ 03/Apr/18 ]

I believe this is by design. When local authorization is used, the user document stored in mongodb must be dropped to invalidate currently-authenticated connections.

Generated at Thu Feb 08 04:36:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.