FreeIPA version: 4.13.1-3.el9_8.2 (AlmaLinux 9)
389-ds-base version: (check with rpm -q 389-ds-base and include)
Component: daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c

Description

After upgrading to FreeIPA 4.13.1-3.el9_8.2, the IPA server logs ALERT-level messages claiming host principals are locked out, even though they are not locked and authentication continues to work normally:

ns-slapd[2745]: [27/May/2026:19:23:42.146872138 +0300] - ALERT - ipalockout_postop - User fqdn=tiger.cfi.lu.lv,cn=computers,cn=accounts,dc=cfi,dc=lu,dc=lv is locked out. Too many failed authentication attempts.

The affected host principals have:

• krbLoginFailedCount: 0
• krbPwdMaxFailure: 0 (Default Host Password Policy — lockout disabled)
• krbLastFailedAuth from years ago (a long-resolved historical failure)

ipa host-show confirms the host is not disabled, and kinit -k host/... continues to succeed.

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.