Skip to Content
avatar image
Former Member

User is still locked

Hello Experts,

We are facing a problem with our systems. I have observed some of the users got locked due to multiple login with incorrect password.

Exact message in SU01-

Password logon not allowed (too many failed logons)

When I unlock user it says "User XXXXXXX is still locked" I do not have access to database to change the UFLAG in USR02. UFLAG for this user is 128 (locked due to incorrect logins). We are not using CUA.

Can any one of you suggest us the procedure to unlock the user?

TIA,

Amit Thombare

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    avatar image
    Former Member
    Dec 03, 2007 at 11:55 PM

    never heard this happening.

    but by tomorrow morning your user will be unlocked automatically because of profile parameter login/failed_user_auto_unlock =1(default).

    if you are on Basis 700 system, it won't work as above unless you have a user defined value '1' for the above mentioned parameter. because SAP changed the default value to '0', not sure why they did so.

    Add comment
    10|10000 characters needed characters exceeded

  • Dec 05, 2007 at 06:27 PM

    That sounds like a bug.

    If you have unlocked the user (using SU01) then USR02-UFLAG must no longer be set to 128 (bit-wise operations apply).

    Well, are you using an ABAP system which consists of multiple server instances? And is your release > 4.6? In that case table USR02 is buffered and this buffering might have caused the effect: if you are performing the SU01 unlock operation one server instance and then try to logon at another server instance before the updated record was synchronized then this could explain the problem.

    I'd recommend to switch-off the buffering for table US02, then.

    It will be switched-off by default as of NetWeaver 7.10.

    Cheers, Wolfgang

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      A possible explnation is the SOLMAN is the CUA master. This means that the RFC user in it's own logical system is the "call back" user but you are expecting it also to perform the CUA client tasks (for itself).

      CUA "hogs" the logical system names with the same name as the technical connections, but the master is a child of itself.

      --> Check the auths of the user in the logical system of SOLMAN and your SCUM settings.

      --> Check for programs doing DB updates on USR02...

      --> Check for locks on the user in Sm12 (this is also a common cause of confusion, as you are locally in change mode (lock) and the RFC user in logsys wants to change it as well...)

      ps: There is a setting in table USR_CUST via which you can relax the locks, but you should actually fix the problem....

      A good solution is an IDM and only maintain identities from there.

      Cheers,

      Julius

  • avatar image
    Former Member
    Dec 03, 2007 at 10:25 PM

    Hello Amit,

    What is your release level?

    What is the error message (number)?

    Cheers,

    Julius

    Add comment
    10|10000 characters needed characters exceeded