Cisco ISE | PEAP Bad Password attempts for AD joined laptops

[JPavonM]

Hi chaps,

I anyone suffering this issue where AD joined laptops, authenticating into wireless with a profile configured to use PEAP-MSCHAPv2 and machine-auth only, are failing with the next error in ISE?

25113

Number of bad password attempts for AD instance is higher than the configuration in Active Directory, Skipping the AD authentication.

This is happening randomly in time and on the impacted devices, and when a laptop is impacted, sometimes it can't connect with that error, and then after a while it connects, and then, again, it fails... or not.

Wireless NIC on the impacted laptops are different, all running latest driver version, but the problem, if on the laptop side, may be with Windows or the supplicant, not the wNIC driver as this is not in charge of the authentication piece.

It all seems to point to a wrong password in the AD for the machine object, but we have 2 different ISE deployments at this time, one where we are seeing this error that is running latest v3.3 patch 4, and other one where there aren't any of that kind running v3.2 Patch 3. I wonder if ISE is not checking the object password, or if it is but it is modifying the payload of the query to the AD.

I have a TAC case open, but I was wondering if any is suffering this as well.

[JPavonM · Accepted solution]

We finally found where the issue was, and the problem was with the "Prevent Account Lock-Out" feature enabled in the AD joint point.

When “Prevent Account Lock‐Out” is enabled, ISE does a quick LDAP read of the AD badPwdCount attribute before it ever forwards an Access‐Request to AD. If that count is at—or above—the threshold you’ve configured (N – 1), ISE will drop the request locally and you’ll see a “max bad password attempts reached, stopping authentication” event in the logs.

Why it appears “random” under the enabled setting? For machine accounts, AD often doesn’t increment badPwdCount the way it does for user accounts, so ISE may be reading stale or unexpected values (often zero) and still interpreting those readings against your threshold. That mismatch causes ISE to believe the account is about to lock out and so it stops the request.

TAC Workarounds and Recommendations:

1. If you need “Prevent Account Lock‑Out” for user logins, keep it enabled only in your User‑PEAP policies, and disable it on your Machine‑PEAP rules. You can achieve this by:
   – Creating two separate AD Identity Store joins (e.g. “AD‑Users” with lock‑out enabled, “AD‑Machines” with it disabled)
   – Or by using an Identity Source Sequence that points first to “AD‑Users” for user auth, then to “AD‑Machines” for machine auth. Both approaches are fully supported.
2. If you prefer a single AD join, leave “Prevent Account Lock‑Out” off completely for machine authentication and rely on AD’s native lock‑out controls.