Re: FMC external authentication with RADIUS locks AD user

Robin-H · ‎12-17-2025

In FMC 7.6.x, we configured two ISE servers as RADIUS External Authentication Object.

The ISE are forwarding the authentication to our Windows AD.

The user now makes one bad login attempt to FMC and the AD account is being locked. AD is set to lock the account after the third bad attempt.

Can I prevent this by setting the "RADIUS-Specific Parameters - Retries" in FMC to 1? It´s currently set to 3. Or is the ISE trying too hard?

nspasov · ‎12-17-2025

One question and answers below:

Are you saying that a failed authentication triggers 3 or more attempts resulting in AD account lockout? I am asking because I just tested this in my lab with versions 7.7.10 and 10.0 and I could not replicate the issue and only see 1 x failed attempt.
The value for "Retries" dictates the number of attempts against the primary AAA server before switching to the secondary.
You can also explore the Failed Authentication Protection feature in ISE located under the Advanced Settings in your AD ISE configurations

Thank you for rating helpful posts!

Thank you for rating helpful posts!

Robin-H · ‎01-27-2026

@nspasov wrote:
Are you saying that a failed authentication triggers 3 or more attempts resulting in AD account lockout? I am asking because I just tested this in my lab with versions 7.7.10 and 10.0 and I could not replicate the issue and only see 1 x failed attempt.

Yes. In the ISE Live Logs, I can see four attempts.
Three with "Failure Reason 24408 User authentication against Active Directory failed since user has entered the wrong password"
The fourth one with "Failure Reason 24415 User authentication against Active Directory failed since user's account is locked out"

In ISE, we use two different policies for FMC and FTD login.
Weird thing is that the FTD login function is fine, with just one failed attempt.
The policy conditions differ a tiny bit and the only other difference is the FMC policy using an Identity Source Sequence with AD first, internal users second whereas the FTD only uses the AD.

Now I´m wondering where to look further, in ISE or in FMC?

I had a case in the past with a NAC tool using RADIUS. Three DCs where configured for redundancy and during the login process, all three where tried and this would lock the AD account. Deleting one DC from the configuration solved the problem.

Cristian Matei · ‎01-27-2026

Hi,

@Robin-H Failed Authentication Protection is used in order to avoid brute force attacks and ending up with the account locked, as well as preventing the account to be locked out when a legit user is trying to authenticate however types a wrong password several times; this feature will tell ISE to no longer send authentication requests to AD after x failed attempts, in your case if AD account gets locked out after three failed attempts, you should configure X equal 2, see more info in following document, under section Configure Maximum Password Attempts for Active Directory Account.

https://www.cisco.com/c/en/us/td/docs/security/ise/3-5/admin_guide/b_ise_admin_3_5/b_ISE_admin_asset_visibility.html

Note that, the badPwdCount value needs to be reset at AD level, as after ISE has reached the configured number of failed attempts, it should no longer try to authenticate the user until the value for badPwdCount has not been reset at AD level, just to keep this in mind, as you win something (AD account not being locked out) but you also loose something (ISE no longer tries to authenticate the user until the value for badPwdCount has not been reset to be under the configured value in ISE). This is by design, and although tracked in a bug, it is expected behaviour. So enabling this feature or not, it depends on what you choose, as long as you're aware of the outcome:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwp00643

So, are you saying that you try to authenticate only ONCE, with wrong credentials, and the result of that is you see four failed authentication attempts on ISE? This is anyways not expected behaviour. We need to see where the problem lies:

1. It may be the browser sending multiple authentication requests (can you repeat the scenario using Chrome in Incognito mode and see if results are the same?)

2. It may be FMC sending multiple authentication requests (can you go to expert mode in FMC, enable the following debugs, try to authenticate only once, collect logs to see how many RADIUS requests are being sent by FMC, disable debugging at the end):

sudo su
pmtool disablebyid webui
pmtool enablebyid webui --debug
tail -f /var/log/messages | grep "auth"
!
!
!After collecting logs, disable debug
!
pmtool disablebyid webui

3. If, in both above cases, there is a single authentication request being sent, it means ISE is misbehaving. Try again authentication with wrong credentials and verify that ISE actually sends 4 requests. While an ISE patch upgrade or version upgrade could fix the issue, this also has the potential to break other things, I would avoid doing it just in the hope of fixing something. Since you've had past experiences, better off leave just the AD in the Identity Sequence and see if now ISE behaves as expected, sending a single auth request to AD, since it received a single auth request from FMC.

Thanks,

Cristian.

Robin-H · ‎02-11-2026

Hello @Cristian Matei !

Thanks for your explanation!
I agree that the badPwdCount attribute has it´s drawbacks and is not the actual solution.

Regarding your questions:

1. I don´t have Chrome available. I was able to try it with Firefox and the result was the same (four failed attempts in the ISE live log)

2.
This was a login with correct credentials:

Feb 11 15:39:52 FMC1 SF-IMS[542]: [542] (none):AUTH [WARN] parseconfig.c:414:parseconfigfile(): obj initial name ISE

This was a login with a wrong password:

Feb 11 15:44:40 FMC1 SF-IMS[9397]: [9397] (none):AUTH [WARN] parseconfig.c:414:parseconfigfile(): obj initial name ISE
Feb 11 15:44:40 FMC1 SF-IMS[9397]: [9397] (none):SFAUTH [ERROR] rad_intf.c:512:execute_radclient_command(): radclient exited with status 1
Feb 11 14:44:42 FMC1 SF-IMS[1469]: Last message '[9397] (none):SFAUTH' repeated 3 times, suppressed by syslog-ng on FMC1.domain.lan

I´m not 100% sure if this is accurate. During several tries, I sometimes only got one or two "SFAUTH [ERROR]" entries, even though in ISE it shows four failed attempts every time.

In ISE, it´s always two events to the first PSN and then two events to the second PSN when wrong credentials are used.

Regarding the debug itself:

grep with "auth" didn´t show anything specific but "AUTH" showed the above.
"pmtool statusbyid webui" didn´t produce an output and even after using "pmtool disablebyid webui", the AUTH events were still shown in the log. Could it be that in 7.6, there´s no webui process?
- In case there was a webui process, should your debug manuel have ended with "pmtool enablebyid webui"?

3. I´ll file a change to get the AD as the only identity source in the ISE and test again.

Greetings,

Robin