- The time of the login attempt.
- The client IP address.
- The authentication method.
- The reason for failure for failed attempts.
You can optionally collapse information about multiple similar attempts on the same date to avoid flooding the history for accounts that bind frequently. Records have an additional attempt count that tracks the number of attempts with the same client IP address, authentications method, and failure reason on the same date. You can also configure the server to maintain each attempt separately, or to only update the history at most once per day.
Recent login history is disabled by default. You can enable and configure the recent login history in password policy. Recent login history can be retrieved with the get recent login history control, available in the LDAP SDK or with the ldapsearch and ldapmodfy commands. The recent login history is also available in the ds-pwp-state-json JSON attribute and in the password policy state extended operation and the manage-account command-line tool.
- maximum-recent-login-history-successful-authentication-count - The maximum number of records that the server will maintain about recent successful authentications.
- maximum-recent-login-history-successful-authentication-duration - The maximum length of time for which the server will maintain information about recent successful authentications.
- maximum-recent-login-history-failed-authentication-count - The maximum number of records that the server will maintain about recent failed authentication attempts.
- maximum-recent-login-history-failed-authentication-duration - The maximum length of time for which the server will maintain information about recent failed authentication attempts.
- recent-login-history-similar-attempt-behavior - The
behavior that the server will exhibit for cases in which a user makes multiple
authentication attempts on the same date in which all of the fields in the
record other than the timestamp (client-ip-address, authentication-method, and
potentially failure-reason) match. Possible values for this property include the
following:
- collapse-similar-attempts-on-the-same-date - Indicates that the server will only maintain one record for any given date with the same values for all non-timestamp fields, and it will use the additional-attempt-count field to keep track of the number of additional attempts that were collapsed into the same record. The timestamp field for that record will reflect the most recent attempt on that date. This will be the default behavior.
- maintain-every-attempt - Indicates that the server will maintain a separate record for every attempt, regardless of how similar it is to a previous attempt although duplicate attempts within the same millisecond may not be preserved (see Replication considerations).
- update-at-most-once-per-day - Indicates that the server will only maintain one record for any given date with the same values for all non-timestamp fields. This can help reduce the number of writes needed to maintain a recent login history, but the value of the timestamp field may not accurately reflect the timestamp of the most recent attempt.
None of these properties are defined by default. If at least one of these properties is defined, the server maintains a recent login history within the specified constraints.
If both the maximum-recent-login-history-successful-authentication-count and maximum-recent-login-history-successful-authentication-duration properties are defined, the server uses the more-restrictive value that applies to a given user. This is also true for the maximum-recent-login-history-failed-authentication-count and maximum-recent-login-history-failed-authentication-duration properties. For example, if the password policy is configured to maintain a successful count of 10 and a successful duration of 30 days, then a user who successfully authenticates on more than ten dates in a 30-day period would be capped at ten records, while a user who authenticates less frequently would only have records for however many attempts they made within those 30 days.
The server can collapse multiple authentication attempts from the same date into a single record if other fields in the record (client-ip-address, authentication-method, and potentially failure-reason, match, this caps the number of records that will be maintained if you want to maintain records by duration rather than count. However, because multiple records may be generated for the same user on the same date if something is different (for example., a different IP address or authentication method), there is technically no limit to the number of records that may be generated when using only a duration-based cap. To help mitigate this, even if you generally want to maintain a duration-based cap, you can specify a maximum count to place an upper bound on what informatoin the server will maintain for a given user.
- maximum-recent-login-history-successful-authentication-count
- maximum-recent-login-history-successful-authentication-duration-seconds
- maximum-recent-login-history-failed-authentication-count
- maximum-recent-login-history-failed-authentication-duration-seconds
- An operation that may be used to retrieve the recent login history. The value returned in this operation will be a JSON object in the same format as used in the get recent login history response control and the ds-pwp-state-json virtual attribute.
- An operation that may be used to clear the recent login history for a user.