MongoDB Documentation, Release 3.0.4 Audit Guarantee The auditing system writes every audit event 18 to an in-memory buffer of audit events. MongoDB writes this buffer to disk periodically. For events collected from any single connection, the events have a total order: if MongoDB writes one event to disk, the system guarantees that it has written all prior events for that connection to disk. If an audit event entry corresponds to an operation that affects the durable state of the database, such as a modification to data, MongoDB will always write the audit event to disk before writing to the journal for that entry. That is, before adding an operation to the journal, MongoDB writes all audit events on the connection that triggered the operation, up to and including the entry for the operation. These auditing guarantees require that MongoDB run with journaling enabled. Warning: MongoDB may lose events if the server terminates before it commits the events to the audit log. The client may receive confirmation of the event before MongoDB commits to the audit log. For example, while auditing an aggregation operation, the server might crash after returning the result but before the audit log flushes. New in version 2.4. MongoDB Enterprise provides support for Kerberos authentication of MongoDB clients to mongod and mongos . Kerberos is an industry standard authentication protocol for large client/server systems. Kerberos allows MongoDB and applications to take advantage of existing authentication infrastructure and processes. In a Kerberos-based system, every participant in the authenticated communication is known as a “principal”, and every principal must have a unique name. Principals belong to administrative units called realms . For each realm, the Kerberos Key Distribution Center (KDC) maintains a database of the realm’s principal and the principals’ associated “secret keys”. For a client-server authentication, the client requests from the KDC a “ticket” for access to a specific asset. KDC uses the client’s secret and the server’s secret to construct the ticket which allows the client and server to mutually authenticate each other, while keeping the secrets hidden. For the configuration of MongoDB for Kerberos support, two kinds of principal names are of interest: user principals (page 331) and service principals (page 332). User Principal To authenticate using Kerberos, you must add the Kerberos user principals to MongoDB to the $external database. User principal names have the form: <username>@<KERBEROS REALM> 18 Audit configuration can include a filter (page 400) to limit events to audit. 331 6.2. Security Concepts Kerberos Components and MongoDB Principals Overview 6.2.7 Kerberos Authentication