How to distinguish locked vs disable account

[Marc.Bergeron]

Hi, in my password Policy, I always get AUTHREASON=7 for a disable or a locked account. Is there a simple way to distinguish them?

I'm on 12.52 SP1 CR04 using Active directory as a user store.

Thanks

[Legacy User]

The most important thing to consider is that if the reason "Admin disable" is set, then you will get SmAuthReason 7, as "Admin disable" is given precedence over any other type of reason.

 

Disabled flag with values as 1, 5, 7, 9, 11, 13, 15 etc will have SMAuthreason as 7 as all of these will be having '1' (disabled due to admin) as one of reasons.

 

There is a Tech Note on this "https://support.ca.com/us/knowledge-base-articles.tec573873.html"

[Marc.Bergeron]

From what I understand, I tried to set this attribute "Disabled Flag (RW)" on my user store to this value "userAccountControl" but I still always get SMAuthreason=7. Do I have to setup something else?

[Legacy User]

Policy Server will map the Disable Flag to the SmAuthReason like this :

Reason
Disabled Flag Value
SmAuthReason
 
 
Admin disabled    
1
7
 
Inactivity
4
25
 
Max login failed
2
4
 
PwExpired
8
19
 
PwMustChange
16777216
20
 
 
 

So if SM_DISABLED_FLAG attribute has value as "2" (locked out), then SmAuthReason would be issued as "4".
However if SM_DISABLED_FLAG attribute has value as "3" (locked out + Admin disabled i.e. 2 + 1), then SmAuthReason would be issued as "7".
If AdminDisabled (i.e. 1) is added to any other condition, the AdminDisabled takes precedence and SmAuthReason will be returned as "7".



It seems like you are using AD as User Store. Are we using Enhanced AD Integration? AD has a better integration with CA SSO for Password Policy. CA SSO can understand AD Password Policy response and then set the SmAuthReason. What I mentioned above is TRUE for SM Password Policy. In the case of AD Password Policy and Enhanced AD Integration, We need to see if the same premise is adopted.

[Legacy User]

Marc

 

Review the notes here in this link. e.g. Remove userAccountControl from SM_DISABLED_FLAG.

 

https://docops.ca.com/ca-single-sign-on/12-7/en/administrating/adjust-policy-server-global-settings#AdjustPolicyServerGlobalSettings-EnableEnhancedActiveDirectoryIntegration

[barka11]

SiteMinder will make the SmAuthReason on the base of the value of userAccountControl. This means, this Authentication Scheme is based on the account state and not the password state.

So, the all possible values of the Disable Flag go like this:

smdisabledflag=0

smdisabledflag=1

smdisabledflag=10

smdisabledflag=16777216

smdisabledflag=16777217

smdisabledflag=16777218

smdisabledflag=16777220

smdisabledflag=2

smdisabledflag=4

smdisabledflag=6

smdisabledflag=8

smdisabledflag=9

which means:

public static final int DMSUSER_DISABLED_ADMINDISABLED 1

public static final int DMSUSER_DISABLED_DISABLEDMASK 16777215

public static final int DMSUSER_DISABLED_ENABLED 0

public static final int DMSUSER_DISABLED_INACTIVITY 4

public static final int DMSUSER_DISABLED_MAXLOGINFAIL 2

public static final int DMSUSER_DISABLED_PEERDISABLED 16

public static final int DMSUSER_DISABLED_PWEXPIRED 8

public static final int DMSUSER_DISABLED_PWMUSTCHANGE 16777216

The remaining reason codes are combinations of what you see from the chart above as:

3 = 1(DMSUSER_DISABLED_ADMINDISABLED) + 2

(DMSUSER_DISABLED_MAXLOGINFAIL)

5 = 4(DMSUSER_DISABLED_INACTIVITY) + 1

(DMSUSER_DISABLED_ADMINDISABLED)

6 = 4(DMSUSER_DISABLED_INACTIVITY) + 2(

DMSUSER_DISABLED_MAXLOGINFAIL )

7=4+2+1

9=8+1

16777217=16777216 + 1

16777218=16777216 + 2

16777220=16777216 + 4

16777221=16777216 + 4+ 1

16777222=16777216 + 4+ 2

So, the Disabled Flag attribute is just a 32-bit integer stored as part of each user's directory record. The Policy Server's directory access layer simply reads and writes the values from the directories. For user directories based on Active Directory, the directory access layer actually computes the Disabled Flag value from various AD status values. When the Policy Server sends a Disabled Flag value to the directory access layer for storage on AD, the reverse computations are made and the AD status values are modified accordingly.

So said, the Policy Server will map the Disable Flag to the SmAuthReason like this:

Reason Disabled flag SMAUTHREASON

Admin disabled 1 7

Inactivity 4 25

Max login failed 2 4

PwExpired 8 19

PwMustChange 16777216 20

[...]

The most important thing to consider is that if the reason "Admin disable" is set, then you will get SmAuthReason 7, as "Admin disable" is given precedence over any other type of reason.

Disabled flag with values as 1, 5, 7, 9, 11, 13, 15 etc will have SMAuthreason as 7 as all of these will be having '1' (disabled due to admin) as one of reasons.

That is why the return codes 532 533 701 you may get from Active Directory for example is not followed browsing LDAP are not corresponding to the SmAuthReason. SiteMinder rely on the Disable Flag value and then, if the SmAuthReason is set to 7, there are big chance that the bit 1 is set to all users Disable Flag values.

Further, SiteMinder treats the "Disabled Flag" integer value as a collection of 32 indicator bits; the low-order 24 bits are reserved as user account disabled bits, and the high-order 8 bits are reserved as user-specific status bits.