Thank you for opening, @rcritten. Additional detail is at https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/G3V2WBQUY4MK34K6IOD75THO2L7TZKOZ/

The "user" in this case is actually a host/machine account.

Thanks for the ML link. It was throwing a 503 when I tried to find the thread.

I don't believe this is object-type specific. I've seen it with users recently during other development work but hadn't bothered to open a ticket until you also saw it.

Thanks for the ML link. It was throwing a 503 when I tried to find the thread.
I'm hoping that's just a transient issue related to the infrastructure move

Updated link after Fedora infrastructure migration:

https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/G3V2WBQUY4MK34K6IOD75THO2L7TZKOZ/

Also reported at https://pagure.io/freeipa/issue/9997 with an analysis and a suggested fix by @ivarss:

Root cause

In ipalockout_postop() the lockout-state log emission is:

if (failedcount >= max_fail) {
    if ((lockout_duration == 0) ||
        (time_now < timegm(&tm) + lockout_duration)) {
        LOG_ALERT("User %s is locked out. Too many failed authentication attempts.\n", dn);
        goto done;
    }
}

When max_fail == 0 and failedcount == 0, 0 >= 0 is true; lockout_duration == 0 is also true; the ALERT fires even though no lockout has occurred.

The companion ipalockout_preop() function (the one that actually enforces lockout) correctly short-circuits in this case:

max_fail = slapi_entry_attr_get_uint(policy_entry, "krbPwdMaxFailure");
if (max_fail == 0) {
    goto done;
}

So enforcement is correct — only the log message in postop is wrong.

Suggested fix

Mirror the preop short-circuit at the start of postop's lockout check, e.g.:

if (max_fail == 0) {
    goto skip_lockout_log;
}
if (failedcount >= max_fail) { ... }

Or change the outer condition to failedcount > 0 && failedcount >= max_fail so a zero counter against a zero threshold doesn't trigger the alert.

Impact

Cosmetic, but high-noise: the ALERT fires on every bind from every host with the default host policy. Log monitoring systems flag it as a security event repeatedly.