Managing User Lockout in Symantec IDSP
Article ID: 436943
Updated On:
Products
Issue/Introduction
This article provides a comprehensive overview of the User Locker behavior within the Symantec (VIP) Authentication Hub. It details how the system handles repeated failed authentication attempts, how to configure lockout thresholds, and the administrative procedures for unlocking user accounts across different identity stores (Internal, SiteMinder,or Zero Footprint/ZFP).
Environment
Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)
Cause
A user account is transitioned to a "Locked" state when the number of consecutive unsuccessful login attempts exceeds the globally defined security threshold. This mechanism is designed to mitigate brute-force attacks and credential stuffing.
Trigger: Reaching the userMaxStrikeCount.
Affected Factors: Lockout applies to various authenticators including Password, SMS OTP, and Email OTP.
Tracking: Enabled via the trackLastLogin tenant property.
Resolution
1. Configuration of Lockout Policy
Administrators can define lockout behavior using the following tenant-level properties within the Global/Tenant settings:
| Property Name | Default Value | Description |
userMaxStrikeCount | 0 (Disabled) | Specifies the number of failed authentication attempts allowed before the user is locked out. |
userAutoUnlockPeriodMinutes | 0 (Disabled) | Specifies the duration (in minutes) a locked account remains locked before it is automatically unlocked. |
trackLastLogin | false | Enables the system to track whether the last authentication attempt was successful or unsuccessful. |
2. Identity Store Authority
The system determines whether to lock the user in the Hub database or the external directory based on the isAuthoritativeForIDLCM attribute in the Identity Store configuration:
When True: Authentication Hub triggers a lock directly in the external authoritative source (e.g., LDAP or SiteMinder).
When False: Authentication Hub becomes the authoritative source; the user is locked locally within the Hub database, even if the external store remains unlocked.
ZFP / SAML JIT: For users without a back-end directory entry, the lock is managed entirely within the Hub database.
3. Manual Unlock Procedures (REST API)
Authorized administrators can manage account status using the UserLocker API. This requires the urn:iam:t.idstoreconfigs privilege.
Check User Status (GET):
GET https://{{host}}/{{tenantName}}/idstore/v1/UserLocker/{{userLoginid}}
Unlock User Account (POST):
POST https://{{host}}/{{tenantName}}/idstore/v1/UserLocker/{{userLoginid}}
Content-Type: application/json
{
"locked": false
}
Note: For OTP authenticators (SMS/Email), the lockout mechanism correctly identifies the authoritative store and applies the strike count. However, when integrated with SiteMinder, ensure the strike counts are synchronized between both systems to avoid "off-by-one" login attempt discrepancies.
Feedback
