UAA Account cannot log on due to too many failed attempts
search cancel

UAA Account cannot log on due to too many failed attempts

book

Article ID: 297839

calendar_today

Updated On:

Products

VMware Tanzu Application Service for VMs

Issue/Introduction

Symptoms:

UAA account cannot log on and gives the error message, "Credentials were rejected, please try again".

The following is a sample output in a testing environment: 

$ cf login
API endpoint: https://api.<pcf system domain>

Email> admin

Password> 
Authenticating...
Credentials were rejected, please try again.

In the UAA log, there are messages like the one shown below:

[2016-08-05 07:55:08.571] uaa - 6064 [http-bio-8080-exec-3] .... WARN --- PeriodLockoutPolicy: User admin and id 9bc25988-8e07-4386-97b1-00fff0afefb5 has 5 failed logins within the last checking period.
[2016-08-05 07:55:08.571] uaa - 6064 [http-bio-8080-exec-3] .... WARN --- AuthzAuthenticationManager: Login policy rejected authentication for admin, 9bc25988-8e07-4386-97b1-00fff0afefb5. Ignoring login request.
[2016-08-05 07:55:08.573] uaa - 6064 [http-bio-8080-exec-3] .... DEBUG --- ChainedAuthenticationManager: Chained authentication exception:Your account has been locked because of too many failed attempts to login. at:org.cloudfoundry.identity.uaa.authentication.manager.AuthzAuthenticationManager.authenticate(AuthzAuthenticationManager.java:97)
[2016-08-05 07:55:08.573] uaa - 6064 [http-bio-8080-exec-3] .... DEBUG --- ChainedAuthenticationManager: Chained Authentication status of org.springframework.security.authentication.UsernamePasswordAuthenticationToken@807b260b: Principal: admin; Credentials: [PROTECTED]; Authenticated: false; Details: remoteAddress=192.168.27.1, clientId=cf; Not granted any authorities with manager:org.cloudfoundry.identity.uaa.authentication.manager.ChainedAuthenticationManager$AuthenticationManagerConfiguration@68f54b30; Authenticated:false
[2016-08-05 07:55:08.573] uaa - 6064 [http-bio-8080-exec-3] .... DEBUG --- BackwardsCompatibleTokenEndpointAuthenticationFilter: Authentication request for failed: org.cloudfoundry.identity.uaa.authentication.AuthenticationPolicyRejectionException: Your account has been locked because of too many failed attempts to login.
[2016-08-05 07:55:08.581] uaa - 6064 [http-bio-8080-exec-3] .... DEBUG --- DefaultOAuth2ExceptionRenderer: Written [error="unauthorized", error_description="Your account has been locked because of too many failed attempts to login."] as "application/json" using [org.springframework.http.converter.json.MappingJackson2HttpMessageConverter@22e43836]
 

This message indicates that the account has been locked after too many failed attempts to log on.

Environment


Cause

UAA will temporarily lock a user out for a short period (5 minutes by default) after 5 failed logins within the previous hour. The failure count is reset when a user successfully authenticates.

The parameters are set in the /var/vcap/jobs/uaa/config/uaa.yml file. 

authentication:
 policy:
 lockoutAfterFailures: 5
 countFailuresWithinSeconds: 3600
 lockoutPeriodSeconds: 300
 global:
 lockoutAfterFailures: 5
 countFailuresWithinSeconds: 3600
 lockoutPeriodSeconds: 300

The global parameters apply to all the zones.

The policy parameters apply to the default zone and it overrides the global values for the default zone.

  • lockoutAfterFailures is the number of the allowed failures before the account is locked.
  • countFailuresWithinSeconds is the number of seconds in which lockoutAfterFailures failures must occur in order for the account to be locked.
  • lockoutPeriodSeconds is the number of seconds to lock out an account when lockoutAfterFailures failures are exceeded.

The sample configure file shown above means that if there are 5 login failures in the past one hour, then the account will be locked for 5 minutes. 

Resolution

After lockoutPeriodSeconds time (5 minutes by default) has passed, the account will be unlocked automatically following the last failed login request. 

If you are not sure where the failed login attempts come from, you can follow the steps below:

  1. Connect via SSH to one (or more) of your Gorouter Virtual Machines (VMs). Go to /var/vcap/sys/log/gorouter
  2. grep 'oauth/token' access.* | grep -w 401 | grep <timestamp>. This should filter the 401 response from the /oauth/token endpoint. These are failed login attempts. <timestamp> here refers to part or all of the timestamp when there is a login failure in UAA log.
  3. When you find one of the 401s, look at the IP addresses listed under the "x_fogorouter logs
  4. rwarded_for fields". These will show you where the incoming failures are coming from.
  5. Locate what is sending the requests and stop it. Confirm that you no longer see the 401 responses in your Gorouter logs.

Given below is a sample output from the testing environment: 

# grep 'oauth/token' * | grep -w '401' | grep '07:55'
access.log.1:login.systems.sunyi.com - [05/08/2016:07:55:02.960 +0000] "POST /oauth/token HTTP/1.1" 401 51 62 "-" "go-cli 6.19.0+b29b4e0 / linux" 192.168.27.71:49340 x_forwarded_for:"192.168.27.1, 192.168.27.71" x_forwarded_proto:"https" vcap_request_id:c4bf14ba-7590-4fef-59d3-a23f93cbb916 response_time:0.388317547 app_id:
access.log.1:login.systems.sunyi.com - [05/08/2016:07:55:03.797 +0000] "POST /oauth/token HTTP/1.1" 401 51 62 "-" "go-cli 6.19.0+b29b4e0 / linux" 192.168.27.71:49350 x_forwarded_for:"192.168.27.1, 192.168.27.71" x_forwarded_proto:"https" vcap_request_id:a1dd4e19-1c39-42e5-4571-8356758a693e response_time:0.058793049 app_id:
access.log.1:login.systems.sunyi.com - [05/08/2016:07:55:04.412 +0000] "POST /oauth/token HTTP/1.1" 401 51 62 "-" "go-cli 6.19.0+b29b4e0 / linux" 192.168.27.71:49358 x_forwarded_for:"192.168.27.1, 192.168.27.71" x_forwarded_proto:"https" vcap_request_id:dcdec171-312d-4571-5c77-c89dc82675ef response_time:0.081940249 app_id:
access.log.1:login.systems.sunyi.com - [05/08/2016:07:55:07.376 +0000] "POST /oauth/token HTTP/1.1" 401 51 62 "-" "go-cli 6.19.0+b29b4e0 / linux" 192.168.27.71:49396 x_forwarded_for:"192.168.27.1, 192.168.27.71" x_forwarded_proto:"https" vcap_request_id:198be2d5-dacd-4ff1-5004-5e715a192dee response_time:0.054656915 app_id:
access.log.1:login.systems.sunyi.com - [05/08/2016:07:55:07.916 +0000] "POST /oauth/token HTTP/1.1" 401 51 62 "-" "go-cli 6.19.0+b29b4e0 / linux" 192.168.27.71:49404 x_forwarded_for:"192.168.27.1, 192.168.27.71" x_forwarded_proto:"https" vcap_request_id:3393ced8-ed2a-4a51-5c76-7647cf63dc19 response_time:0.114442052 app_id:
access.log.1:login.systems.sunyi.com - [05/08/2016:07:55:08.516 +0000] "POST /oauth/token HTTP/1.1" 401 51 121 "-" "go-cli 6.19.0+b29b4e0 / linux" 192.168.27.71:49411 x_forwarded_for:"192.168.27.1, 192.168.27.71" x_forwarded_proto:"https" vcap_request_id:3202cd80-f4f7-4435-494c-af329d5bed3f response_time:0.066517793 app_id:
 

If you need further assistance tracking down the source of the requests, please open a support ticket.