[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
2. Following is the ldap configuration in mongod.conf
3. Using mongo shell, connect using a local userAdmin then create user in $external using internal authz by first using a local admin:
4. Now using mongo shell connect to this mongod instance using ldap user:
5. Perform some CRUD operations using this user to confirm access.
6.. Authentication fails for any new sessions using this deleted ldap user:
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. |