Locked user (UFLAG - 128) still can login thru EP5

[Former Member]

We have a situation where users who are locked due to incorrect logons (UFLAG = 128) can still logon to the system thru Enterprise Portal (SSO).

Do anyone knows if this default by system design or if there are system parameters that control this.

Thanks.

[Former Member]

Hi Tse,

In my opinion this is because of SSO.In SSO is there so that the need to input passwords everytime a log on is tried is eliminated.An initial password logon is needed and after that no checking per se happens.For starting level info on SSO read OSS note 138498.

I guess other forum members can throw better light on this.

Regards.

Ruchit.

Message was edited by: Ruchit Khushu

[Wolfgang_Janzen]

This is intended - I can confirm what Ruchit states:

the password lock (notice: different from the account lock) is only evaluated when performing a password-based user authentication.

When accessing the ABAP backend system through the EP, SAP logon tickets will be used for SSO. In that case password locks will be ignored.

This is documented in <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/0498889">SAP Note 498889</a>.

Regards, Wolfgang

[Former Member]

Hi Wolfgang,

Was hoping for your reply since in my opinion ur THE expert in SSO and related areas (though this is not the only area ur expert in ). Thanks for the confirmation.

Hi Tse,

I guess this should solve the issue for you.

Regards.

Ruchit.

Message was edited by: Ruchit Khushu

Message was edited by: Ruchit Khushu

[Former Member]

Hi Lye,

Limiting the "Valid to" date on the user master should work the same as locking their account for GUI access, and / or limit the "Valid to" on their role assignments to limit their access.

Cheers,

Julius

[Wolfgang_Janzen]

Hi Julius,

you need to differentiate between

(1) account attributes (validity, account lock)

(2) password attributes (here: password lock)

(3) assigned authorizations (roles, profiles, reference user)

(And then there are other user attributes as well, such as address, user parameters, user group, ...)

The password-specific attributes are only evaluated when performing a password-based user authentication. With one slight exception: even when performing a non-password authentication the system will check whether the user is able(!) to perform a password authentication as well. If this is the case and if the password needs to be changed, the system might also prompt the user to change his password (unless the system is instructed not to do so, see profile parameter login/password_change_for_SSO and <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/0869218">SAP Note 869218</a>).

Regards, Wolfgang

[Former Member]

THanks Wolfgang!

I did not know that there was a difference in behaviour between 128 and 64 for the same field. It seemed a bit redundant to me considering deactivating the password achieves the same, but now makes a bit more sense. How does the system behave when more than one condition occurs (i.e. UFLAG = 160 or 192)?

If given the choice, I still favour the use of validity dates (on the user account and role attributes) over locking a user account.

Thanks for clarifying.

Cheers,

Julius

[Wolfgang_Janzen]

Yes, those are bit flags. Combinations are possible:

128 (password lock) + 64 (local account lock) = 222

128 (password lock) + 32 (global account lock) = 160

Whether you prefer "account lock" or "account expiration date" is up to you. But please notice that "password lock" is something entirely different: the password lock is set by the system when the maximum number of permissible (subsequent) failed password logon attempts is exceeded (to prevent further password logon attempts).