Skip to main content

ServiceNow dynatraceapi user getting locked out...what happened behind the scenes

 From ServiceNow Support:

Investigation Summary:
- login fails for today 221when I reviewed:

-DynatraceAPI user

KB1008050 - Specify lockout for failed login attempts
- audit list of locked out for user DynatraceAPI

- every 15mins 'system' unlocks the user account then 'Guest Guest' locks
- As per documentation:
Uses the value of the glide.user.max_unlock_attempts property to set the limit for failed login attempts.
Unlocks the user account after the time period that is specified for the glide.user.unlock_timeout_in_mins property. If no value is specified, then the system unlocks the user account after the default period of 15 minutes.
- SGO-Dynatrace (active) - no related tasks as flow seems to have ACL error

- Flow error:


- I see many attempts for the REST calls with response code 401 which we can assume when the user is locked e.g :
Nov 15 17:15:55 adc03a adcv2_ministryofju766_lhr100[6395]: [adcv2_access] src= vip= instance=xxxxxx node= method=POST


reqtime=0.013 rtt32=9322 uct=0.000 uht=0.012 urt=0.012 us=401 rescode=401 ssl_cipher=ECDHE-RSA-AES128-GCM-SHA256 ssl_protocol=TLSv1.2 ua="ruxit server" ssib=0 h=h1
- When the user is unlocked I see the following error message:
API_INT-thread-4 SYSTEM txid=3258dd3f1b43 Background message, type:error, message: Password must contain at least 1 uppercase letter(s).

Next Steps:
- Can you disable SGO-Dynatrace and see if you still get the lockouts
- Can you check your user password for DynatraceAPI although it still appears to authenticate.
- I will check if there are any known issue particularly for multiple sub-prod instances all connecting to a common Dynatrace sub prod,


SGO-Dynatrace (alert management rule) was modified to include a customised sub-flow, but the alerts/incidents continued to create after it was disabled . Querying whether it can just be disabled OR better still, identify the culprit ACL and add the dynatraceapi user to the ACL permissions?


Popular posts from this blog

ServiceNow check for null or nil or empty (or not)

Haven't tested these all recently within global/local scopes, so feel free to have a play! option 1 use an encoded query embedded in the GlideRecord , e.g.  var grProf = new GlideRecord ( 'x_cls_clear_skye_i_profile' ); grProf . addQuery ( 'status=1^ owner=NULL ' ); grProf . query (); even better use the glideRecord  addNotNullQuery or addNullQuery option 2 JSUtil.nil / notNil (this might be the most powerful. See this link ) example: if ( current . operation () == 'insert' && JSUtil . notNil ( current . parent ) && ! current . work_effort . nil ())  option 3 there might be times when you need to get inside the GlideRecord and perform the check there, for example if the code goes down 2 optional routes depending on null / not null can use gs.nil : var grAppr = new GlideRecord ( 'sysapproval_approver' ); var grUser = new GlideRecord ( 'sys_user' ); if ( grUser . get ( 'sys_id' , current . approver )){

Get URL Parameter - server side script (portal or classic UI)

Classic UI : var sURL_editparam = gs . action . getGlideURI (). getMap (). get ( ' sysparm_aparameter ' ); if ( sURL_editparam == 'true' ) { gs . addInfoMessage ( 'parameter passed ); } Portal : var sURL_editparam = $sp . getParameter ( " sysparm_aparameter " ); if ( sURL_editparam == 'true' ) { gs . addInfoMessage ( 'parameter passed ); }