[DOCS-14044] Investigate changes in SERVER-51457: Improve log line for failed speculative auth attempts Created: 10/Dec/20  Updated: 13/Nov/23  Due: 09/Jul/21  Resolved: 23/Jul/21

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: 4.9.0, 4.4.6, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Andrew Feierabend (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
backported by DOCS-14351 [BACKPORT] [v4.4] Improve log line fo... Closed
Documented
documents SERVER-51457 Improve log line for failed speculati... Closed
Participants:
Days since reply: 2 years, 28 weeks, 5 days ago
Epic Link: DOCSP-9747
Story Points: 2

 Description   

Description

Downstream Change Summary

Audit events for authentication may now reflect the result error code `334 - MechanismUnavailable` in addition to `0 - Success` and `18 - Authentication Failed`. The new error code should be updated in the System Events Audit Messages docs page and generally treated as a specialization of `Unauthorized`.

Description of Linked Ticket

If a user is created with auth mechanism SCRAM-SHA-1 and the URI provided to the driver does not have an authMechanism parameter, the driver will attempt to do speculative authentication using the SCRAM-SHA-256 mechanism per the MongoDB Handshake specification. On a 4.4+ server, this generates a log line like

{"t":{"$date":"2020-10-06T13:09:11.911-04:00"},"s":"I",  "c":"ACCESS",   "id":20249,   "ctx":"conn14","msg":"Authentication failed","attr":{"mechanism":"SCRAM-SHA-256","principalName":"user","authenticationDatabase":"admin","client":"127.0.0.1:51939","result":"AuthenticationFailed: Unable to use SCRAM-SHA-256 based authentication for user without any SCRAM-SHA-256 credentials registered"}}

According to sara.golemon, logging this is important because otherwise, an attacker could try to brute force password guesses in isMaster attempts and the server wouldn't log anything. However, this is a confusing line to see in access logs because it makes it seem like something went wrong when everything is actually behaving as expected. Would it be possible to clarify that this is due to a failed speculative authentication attempt in the log?

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Githook User [ 23/Jul/21 ]

Author:

{'name': 'andf-mongodb', 'email': 'andrew.feierabend@mongodb.com', 'username': 'andf-mongodb'}

Message: DOCS-14044 add audit log auth code 334
Branch: master
https://github.com/mongodb/docs/commit/ae1b9078689a12cb5a7519c9798ba270ddd64c7e

Generated at Thu Feb 08 08:09:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.