Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

User is still locked

Former Member
0 Kudos

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

1 ACCEPTED SOLUTION

Former Member
0 Kudos

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.

6 REPLIES 6

Former Member
0 Kudos

Hello Amit,

What is your release level?

What is the error message (number)?

Cheers,

Julius

Former Member
0 Kudos

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.

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

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

0 Kudos

Hi Wolfgang,

I interpreted the question as a message in SU01 when unlocking the user, stating that it is still locked, not a message at logon explaining to the user that they are still locked.

I was curious and found an old note (cannot remember the note number anymore, the message was "SU01 01 333") but I discarded it because that was 5 years ago... The message number is however still used.

@ Amit: You need to provide more information about the system and the message and possibly even the user(s). There <i>might</i> even be some relics from the past which are preventing the unlock?

Kind regards,

Julius

0 Kudos

Hi Julius,

I am also getting same issue.

User is locked in Solman due to in correct login. System is connected through CUA.

When i am trying to unlocking it locally, getting bellow message.

User XXXXXX is still locked

Message no. 01333

SAP_BASIS support pack is SAPKB70210

Seeking for your comment.

Thanks-

Guru Prasad Dwivedi

0 Kudos

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