Locked due to incorrect logons ! (Lock 130)

[Former Member]

users are being locked due to incorrect logon attempts, but the usual lock type of 128 for this type of error is not happening.

these users are being locked with 130.

when trying to replicate the problem using a test user on the same system, the account is locked with 128.

any thoughts?

[Former Member]

Hi,

Where are you seeing this '130'? (SE16? a report output? an external tool?)

Cheers,

Julius

[Former Member]

Hi,

Usualy the messge is ' User is locked" is 128 /130 your help desk number ? please tell what these numbers are.

Thanks

[Former Member]

Is there a client '130' in this system or any other within a CUA landscape?

It would be helpfull to know where this '130' is appearing?

Cheers,

Julius

[Former Member]

• upated: when looking in the change documents (su01) history for the account, the new lock value is 130 with text "incorrect logon lock" which i've never seen before. apologies for the confusion. basically 128 is the 'usual' value i'm used to seeing associated with incorrect logon attempts, and i'm curious if anyone has seen 130 before? **

users are being locked due to incorrect logon attempts, but the usual lock type of 128 for this type of error is not happening.

these users are being locked with 130.

when trying to replicate the problem using a test user on the same system, the account is locked with 128.

any thoughts?

[Former Member]

Assuming..Again .Assuming ..that the number is directly linked to the "lock", in my little experience There are two types of locks one from the Administrator lock and other the System Lock.

going forward again, when a user attempts multiple log on and fails the system locks up the user -this might refer to one of the numbers you are mentioning the other is for example when the user is terminated the admin locks him up this could be the other three digit number.

In your test user id , You having the rights of the id might be locking up the user hence a differnent number.

However, at the end of the day you should be able to unlock the user ! irrespective of the number.

I tried to replicate your concern, sadly I am neither getting a 128 or a 130 !!

Thanks

George

[Former Member]

normal number are 64 and 128 (table usr02)

i have never seen locks with the number 130???

[former_member74904]

these are the possible values for the UFLAG field:

User status

0 User not locked

32 (Hex 20) Locked by CUA central administrator

64 (Hex 40) Locked by administrator

128 (Hex 80) Locked after failed logon

More than one lock can occur at a time. In this case, the field contains the total of the values.

according to this, it's not possible to end up with a value of 130...

Edited by: Dimitri on Jan 4, 2008 10:28 AM

[Former Member]

Hi Nigel,

in the our system there is a self made program „ZLOCK_USER“, which makes it possible to add 2 to the actual USR02-UFLAG. I think this was made to lock users and later to reset the users to the initial status ( For this purpose you better use EWULKUSR ). Maybe there is a ABAP in your system too, who does the adding and subtracting of 2.

You may find this program by SE11, database table USR02, mark line UFLAG and select Where-used List.

[WolfgangJanzen]

Well, hopefully you are aware that such direct updates to system tables are critical (and in some future release might no longer possible, due to the ABAP package concept which has become stricter with NetWeaver 7.10).

Fortunately, the system itself treats USR02-UFLAG as bit field and performs only bit-wise operations. Therefore it does not care about unknown bits.

Cheers, Wolfgang (SDN user # [167|https://forums.sdn.sap.com/profile.jspa?userID=167])

[Former Member]

>

> You may find this program by SE11, database table USR02, mark line UFLAG and select Where-used List.

That was my thought as well.

Though mind you... if the user is infact "password locked" (indicating USR02-UFLAG is '128') and only the change documents are showing this (USH02-UFLAG = '130'), then it would be more difficult to find.

Cheers,

Julius

Edited by: Julius Bussche on Jan 4, 2008 1:08 PM

[Former Member]

>

> ... (and in some future release might no longer possible, due to the ABAP package concept which has become stricter with NetWeaver 7.10).

Thanks Wolfgang!

I have been curious for many months now and have also done some "advertising" with developers. All developers I know agree, but some would like to see it happen first...

We (over lunch etc) were speculating about the call stacks, repid etc and cprog were the main candidates.

Perhaps we were lost in the trees (and tables) and did not see the whole forest...

All people I respect consider this to be a step in the right direction, even if it creates some irritations...

I am sure that SDN can also help to sustainably overcome those irritations.

All the best for 2008 (and release ?) and thanks for all your insights and help to understand the system during 2007!

Kind regards,

Julius

[WolfgangJanzen]

Hi Julius,

some insights on the "new package concept" are published in the [1st hand article by Andreas Blumenthal and Horst Keller|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f2dac69e-0e01-0010-e2b6-81c1e8e5ce50]:

Packages enhance the features of development classes, and allow you to control access to repository objects at design time. SAP plans to enhance the access control into the runtime realm in an upcoming release. Packages can be nested; nesting of packages means layering - an embedded package can't access the contents of its surrounding packages (this limitation will be overcome with the planned new package concept).

This is a declarative approach; the ABAP runtime provides access control support. In previous releases it was required to evaluate the ABAP callstack programmatically (as practised by some kernel routines ...). Also, ABAP OO provides some access control mechanism using the "friend" concept.

Cheers, Wolfgang

Edited by: Wolfgang Janzen on Jan 6, 2008 12:24 PM

[Former Member]

• ANSWER found **

turns out that the Helpdesk did not unlock all users fully/completely using our custom tool, which puts a value of "2" in the UFLAG field. when users accidentally locked themselves out, this added the normal "128" value to the "2" making it "130"

thanks to all who helped on this one!

users are being locked due to incorrect logon attempts, but the usual lock type of 128 for this type of error is not happening.

these users are being locked with 130.

when trying to replicate the problem using a test user on the same system, the account is locked with 128.

any thoughts?

[WolfgangJanzen]

> ... custom tool, which puts a value of "2" in the UFLAG field when users accidentally locked themselves out

Just for curiosity: how to do determine whether a user has "accidentially" locked themselves out - in contrast to "someone has attempted to guess the password but failed" ...?!

[Former Member]

Thank you for posting the solution.greatly appreciate this approach.Infact yesterday I loked closely on the reports saw 0 64 & 128 and thought of this post !!

Thanks again, Simple things but great !!

[Former Member]

>

> any thoughts?

The custom tool was written in the production system (you mentioned "not working" in test system before), or there is a DB trigger on the field?

Edited by: Julius Bussche on Jan 9, 2008 12:02 AM