Unexpected Admin Account Lockouts Without Failed Login Attempts

Products

Clarity PPM On Premise Clarity FedRAMP Clarity PPM SaaS

Issue/Introduction

The admin account is being locked multiple times without any intentional login attempts or known user activity, which appears to be unexpected behavior and requires further investigation. Under standard conditions, the account lockout mechanism functions as expected—after multiple failed login attempts (e.g., on the third invalid credential entry), the account is locked. This behavior was validated through testing with incorrect credentials.

However, there are also instances where the admin account is being locked without any failed login attempts or increments in the “bad login count,” which is inconsistent with expected system behavior. This suggests that the lockouts may be triggered by background processes, system-level activities, or an unidentified automated mechanism rather than manual login failures. Assistance is required to identify the root cause and provide recommendations to prevent these unexpected account lockouts.

Environment

Clarity All Supported Version

Cause

Since standard failed password attempts always increment the bad login counter before locking the account, a zero bad login count strongly suggests that the lockout is not being triggered by a user or an automated script entering incorrect passwords through the Clarity login interface or XOG API. Instead, it appears that the account status is being explicitly updated to “Locked” by an external mechanism, an automated background process, or a direct database update.

Below are the most probable causes

Identity Governance & Provisioning Synchronization (Most Common Scenario): Recommend checking whether your organization uses an Identity and Access Management (IAM) solution such as SailPoint, Okta, LDAP, Active Directory synchronization, or a custom GEL-based synchronization job within Clarity.
Custom Database Scripts or Maintenance Jobs: Recommend reviewing any scheduled database jobs, SQL Agent jobs, security hardening scripts, or account maintenance scripts managed by the DBA or infrastructure team. For example, a script intended to lock dormant accounts (e.g., users inactive for 90 days) may be running in the background. If the filtering logic is too broad, it could unintentionally include the admin account and directly update the USER_STATUS_ID field using an UPDATE statement.
SSO / External Authentication Layer Interference: If the admin account is configured to authenticate through Single Sign-On (SSO / SAML / OIDC) rather than remaining a strictly local account, recommend validating whether an external system may be triggering authentication attempts. For instance, an old integration, stale network share, mobile device, scheduled task, or automated process may still be attempting authentication using expired credentials.

Resolution

Recommended Diagnostic Steps: To identify the exact trigger, my recommendation would be to determine when the lockout occurs and what process is updating the account status.

Step 1: Query the Database Immediately After Lockout: As soon as the account becomes locked, I recommend running the following query against the Clarity database before unlocking the account, since unlocking may overwrite the metadata
```
select
	u.id,
	u.user_name,
	u.user_status_id,
	u.last_updated_date,
	u.last_updated_by,
	(
	select
		user_name
	from
		cmn_sec_users
	where
		id = u.last_updated_by ) as updated_by_user
from
	cmn_sec_users u
where
	u.user_name = 'admin';
```
- last_updated_date → This provides the exact timestamp when the account was locked. I recommend correlating this timestamp with scheduled tasks, IAM synchronization jobs, Clarity background jobs, or security processes.
- updated_by_user → If this points to a specific integration/service account (for example, an SSO sync user or provisioning account), this may help identify the source of the lock. If the value is -1 (System) or admin, it may indicate an internal Clarity process, XOG integration, or automation.
Step 2: Review Audit Trail (If Enabled): If auditing is enabled for the CMN_SEC_USERS object, I recommend reviewing the audit trail to identify historical account status changes.This can help establish a pattern regarding frequency, timing, and trigger conditions for the lockouts. You can review this through:
- Administration → Audit Trail or by querying the cmn_audit table for changes to the user_status_id field associated with the admin user ID.
Step 3: Review Clarity System Logs: Once the exact lock timestamp is identified, recommend reviewing the app-ca.log and bg-ca.log files for that specific timeframe.
- Any activity associated with the admin user
- Incoming XOG requests
- REST API calls targeting user resources
- Authentication or provisioning activity

Step 4: Review Internal GEL Scripts and Background Processes: A custom GEL script may be executing SQL or XOG logic that updates user status under certain conditions. In some cases, error-handling logic or outdated hardcoded credentials may unintentionally trigger account locking. Recommend reviewing scheduled processes under: Administration → Data Administration → Processes. Specifically, focus on custom processes related to:

User synchronization
Security/account management
Resource maintenance
Scheduled integrations

The following query may help identify scripts referencing admin, passwords, or secrets:

select
	p.process_code,
	nls.name as process_name,
	step.step_code,
	action.action_code,
	script.script_text
from
	bpm_def_processes p
join bpm_def_process_versions pv on
	p.id = pv.process_id
join bpm_def_stages stage on
	stage.process_version_id = pv.id
join bpm_def_steps step on
	step.stage_id = stage.id
join bpm_def_step_actions action on
	action.step_id = step.id
join cmn_custom_scripts script on
	script.id = action.script_id
join cmn_captions_nls nls on
	p.id = nls.pk_id
	and nls.table_name = 'BPM_DEF_PROCESSES'
	and nls.language_code = 'en'
where
	LOWER(script.script_text) like '%admin%'
	and ( LOWER(script.script_text) like '%password%'
		or LOWER(script.script_text) like '%secret%' );