Maximum VPN Login Attemps using LDAP

[brunobaleizao27]

Good Afternoon,
I have deployments made in many customers with ASA / Firepower of RAS, VPN, with authentication of users with the AD Username/Password and other profiles using Tokens (username - password + TOKEN)
Everything is working fine, but I discover that if wrong password are sent, the account is locked in the AD.
If some malicious actors decide to exploit this, using the logins of these users to proposition lock their accounts, it will cause problems in the infrasctuture.In older deployments, I believe we can lock with a value - Maximum vpn login attempts.
Is this option also to Firepower - this can mitigate the problem?
Because the lock is needed it, I don't want to disable this lockout after 10 attempts, or we have another problem, brute force à la carte. But the actual picture is not good either.
Can someone give some lights?
Thanks in advance!

[Marius Gunnerud]

As far as I know, the lockout setting is done on the LDAP server and not the ASA.

[brunobaleizao27]

Hi Marius,

That is true, I have the lockout configure in GPO for lock after 5 attempt and unlock automatically after 30 min. But in my infrastructure, the LDAP Server is a domain controller, the problem is that this should be configured as it is, for all users. What I was wondering is that Firepower could block attempt logins for a user before the 5 attempt. This way, the firewall could block brute force attacks and the user won't be lock in Active Directory. Like I say, if you brute force an active username in VPN Logins, from outside organization, the account will be blocked in AD, this is the problem. This could be maybe overcome with another LDAP Server, between the Domain Controller and Firewall, or we could do as good practice says, don't use the Samaccountname - logon name in VPN but this may not be an option right now. I thong that Firepower have some way to mitigate this gap.

Thanks in advance

[Jeffrey Jost]

We are currently setup the same way and Have A TAC escalated service ticket 695847390. Cisco has informed us that their Firepower solution cannot prevent this attack. The solution was to move our Paloalto to the perimeter and decommission our Firepower solution.    "APT29 abused the Windows Credential Roaming in an attack."