cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
15514
Views
5
Helpful
9
Replies

Prevent AD account being locked out by failed authentications

pgerstenberger
Level 1
Level 1

Hello Community,

 

I got a little question regarding prevention of AD accounts being locked out by failed authentications. When a user changes his password for the AD account they forget to change it on their mobile devices and get locked out after 5 failed attempts. Is there any solution to prevent user locked out caused by failed RADIUS attempts. Something like this on Aruba Clear Pass?

 

https://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/How-to-prevent-AD-account-being-Locked-out-by-5-failed/ta-p/234571 

 

Thanks,

Philipp

1 Accepted Solution

Accepted Solutions

LDAP is your solution.  We even used that back in the ACS days.  It's brilliant and will of course integrate to your existing AD controllers out of the box (TCP/389).  We have systems that misbehave and then repeatedly use the wrong password against an active user account.  If we had used AD then the account would have been locked out.  With LDAP, this account is not locked out.  We can trawl the logs and then find the offending system and sort it out.  In our case it was 3G/LTE modems that misbehave and cache old password.  It's not a user error.

View solution in original post

9 Replies 9

anthonylofreso
Level 4
Level 4

I actually had this same question, and a Cisco employee worked with me to come up with the following solution:

Failed Login Attempts

On the ISE portal there is a mechanism that prevents user from logging into the guest portal too many times with incorrect username and/or password which counts as a failed guest authentication as viewed from the ISE GUI: Operations > Radius > Live Logs or from ISE GUI: Operations > Reports > Endpoints and Users > Radius Authentication [report].  

 

The default behavior is after 5 failed guest authentication attempts the guest portal on ISE will not allow anyone to login for a duration of 2 minutes.  Testing shows the “sign on” button becomes disabled; thus account is not actually being locked.  This feature should apply to either Sponsored Guest Portal or Self-Registered Guest Portal but not in Hotspot Portal.  

 

This feature is configurable in the Guest Portal itself, from ISE GUI: Work Centers > Guest Access: Portals & Components > Guest Portals {select guest portal that uses credentials} > Edit > section: Login Page Settings, as shown below:login ise.jpg

 

 

Recommend the value specified as “maximum failed login attempts before rate limiting” should be less than the lockout period in Active Directory and “time between login attempts when rate limiting” to be the same or exceed the duration period in Active Directory, for best results.   That way if failed authentication happens too many times on ISE Portal then after rate limit period expires and another round of failed guest authentication won’t lock user account in Active Directory on multiple round of failed guest authentication attempts.

 

Reference: Cisco Identity Services Engine Administrator Guide, Release 2.2 > Chapter: Guest Access User Interface Reference > Login Page Settings for Credentialed Guest Portals

You could try using LDAP instead of an AD Join Point.  If you use LDAP to authenticate against your AD domains, then you won't incur this account lockout issue.  LDAP is pretty cool because you can do everything that the AD Join Point does, without all this overhead that comes with AD Join Points. 

The biggest trick I find with LDAP is that you need to understand the schema mapping between ISE and your AD schema - most AD admins will help you with that.  There is also the sysinternals AD Explorer that helped me  a lot.

 

LDAP is really "Lightweight" - it's great!

Hi Anthonylofreso ,

thanks for the fast reply. Unfortunately we don´t use the Guest Portal on ISE for this authentication. Were just checking if the credential are correct and grand then access to the wifi (ISE is only RADIUS Server for the wifi located on aruba). But is it possible to check if the password is correct using LDAP instead of AD?

Cheers,
Philipp

scamarda
Cisco Employee
Cisco Employee

Have not tried this but could you not have a condition which looks at the Bad Password Count and set the value to one lower than the max amount.  When it matches that condition the user could be redirected to a portal page that gives the user a warning about password lockout and to wait x amount of minutes.  I believe the you can control the bad password count timer and the portal page will continue to display until the timer in AD/LDAP has reset.  

 

Not the ISE or AD expert just offering some thoughts.

 

Sam

 

hslai
Cisco Employee
Cisco Employee

That is not exactly a good solution. If allowing users to use password-based .1X authentications on wireless., esp. on mobile endpoints, it would be better off by disabling the AD account lockout policy altogether.

LDAP is your solution.  We even used that back in the ACS days.  It's brilliant and will of course integrate to your existing AD controllers out of the box (TCP/389).  We have systems that misbehave and then repeatedly use the wrong password against an active user account.  If we had used AD then the account would have been locked out.  With LDAP, this account is not locked out.  We can trawl the logs and then find the offending system and sort it out.  In our case it was 3G/LTE modems that misbehave and cache old password.  It's not a user error.

LDAP doesn't support all the authentication methods that are available to AD, so it depends on how they authenticate their supplicants.  

 

However if LDAP is a good pick for them then according to the ISE performance and scaling guides it allows for more authentications per second for supported authentication methods, so that's a plus.

Hi, Arne
I integrated ise with ldap but the account is still blocked after wrong password attemps. What else needs to be configured so that accounts are not blocked? 

Hey @fira - the thread I replied to is from 2018 and a lot has probably changed since then. I have not worked much with LDAP since then. It certainly the behaviour then - perhaps with newer Windows Server platforms, Microsoft may have changed the behaviour. What version of Server are you using?