User Lockout inconsistency between VIP AuthHub and Siteminder

Products

• Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Issue/Introduction

In the environment the external LDAP store is configured this way:

Configured user lockout, following the document: https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/vip-authentication-hub/3-4/Configuring/User-Locker-Behaviour.html

userMaxStrikes: 5

Tested on various flows. The OTP flows: EMailOTP, SMSOTP, successfully reported the user exceeded max login attempts. However, the user was not locked.

When the same number of strikes was repeated on the same user, the user was locked.

Looks like each alternate time a user is locked. This gives effectively a user (2 * userMaxStrike) attempts to guess the OTP.

Environment

VIP AuthHub

Release: 3.4.1

Policy servers = FullVersion=12.9.000.3079

Linux 3.10.0-1160.135.1.el7.x86_64 #1 SMP Tue May 13 01:53:34 EDT 2025 x86_64 x86_64 x86_64 GNU/Linux

Red Hat Enterprise Linux Server release 7.9 (Maipo)

 Proxy server = FullVersion=12.9.000.3079

Linux 3.10.0-1160.136.1.el7.x86_64 #1 SMP Tue Jul 8 07:32:00 EDT 2025 x86_64 x86_64 x86_64 GNU/Linux

Red Hat Enterprise Linux Server release 7.9 (Maipo)

Resolution

VIP Authentication Hub:
userMaxStrikeCount - This property allows administrators to specify how many failed authentication attempts are allowed before the user is locked out.

SIteminder:
Account disabled after successive incorrect password
Specifies the number of consecutive failed log in attempts a user can make before the user account is disabled. Limiting the number of unsuccessful attempts protects against programs designed to access a resource by repeatedly trying passwords until the correct one is found. If a user fails to login correctly after the specified number of attempts, the Policy Server disables the user’s account. The account must be re-enabled by an administrator.

Even though both refers to the same functionality, there is a gap. AH considers the strike count value as the last failure attempt and locks the user. however, SM considers the after configured number, if the next attempt is wrong then only disables user. 

Right now, work around is to configure 'n' at SM and 'n+1' and AH.

Siteminder team also provided a fix to address this issue.