Pivotal Knowledge Base

Follow

UAA account cannot log on due to being locked after too many failed attempts

Environment 

Product Version
Pivotal Cloud Foundry® (PCF) 1.6.x, 1.7.x

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

Symptom

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, which indicates that the account has been locked because of too many failed attempts to log on.

[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]

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 zones.

The policy parameters apply to the default zone, which will override the global values for the default zone only.

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

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

Resolution

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

If you're not sure where the failed log on attempts come from, you can follow the steps below:

  1. Connect via SSH to one (or more) of your gorouter 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 log on attempts. <timestamp> here refers to part or all of the timestamp when there's login failure in UAA log.
  3. When you find one of the 401s, look at the IP addresses listed under the "x_forwarded_for fields". These will show you where the incoming failures are coming from.
  4. Locate what is sending the requests and stop it. Confirm that you no longer see the 401 responses in your gorouter logs.

This 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. 

Comments

Powered by Zendesk