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: 

Lock and Unlock user for a period of time

Former Member
0 Kudos

I need to lock a specific su01 user for a specific period of time each day. Does anyone have any idea how to accomplish this task?

13 REPLIES 13

Former Member
0 Kudos

Hi,

I think Basis guys are the best people to help you to accomplish this task.Please talk to them.

Check Tcodes: EWZ5 or SU10.

This may help.

Please reward if useful.

Thanks,

Srinivasa

0 Kudos

The problem would be, that if the user is already logged on, then just locking it will not make them log off (to be able to prevent them from logging on, again).

Abruptly killing their session is not very nice either (they might not have saved their work yet).

An option to consider, would be to remove their access between those times. They could logon or be logged on, but not do anything, or only do something which you can control (via the access).

Another consideration is that the user ID might have periodic or event dependent background jobs running under their ID. If you change something (user lock or access) those jobs might fail.

What is your release level?

Cheers,

Julius

PS: I have requested a move of this thread.

Former Member
0 Kudos

Hi,

Am not very sure if this will work but it came to my mind and pl try it.

When a user is locked the UFLAG field in table USR02 of the user is set to 128.

So in oracle db in os level if we execute the following statement

UPDATE SAP<SID>.USR02

SET UFLAG = '128'

WHERE BNAME = 'XXUSER' ;

COMMIT;

It locks user XXUSER.

Similarly, if we execute the following statement

UPDATE SAP<SID>.USR02

SET UFLAG = '0'

WHERE BNAME = 'XXUSER' ;

COMMIT;

This unlocks the said user.

If these two statements can be scheduled to run as two background jobs as External program at two diff times then it might so happen tht the user gets locked when the background job with the first sql gets executed and the user gets unlocked when the second bkground job (ie with the second sql )runs .

Look for how to run external commands as bkground jobs via sm36.

Regards

0 Kudos

Hi Manas,

I am also not very sure whether or not the person who caused <a href="https://service.sap.com/sap/support/notes/7">SAP Note 7</a> was doing just that... however, I am sure that it will not work on its own.

What might help, is to check whether the user is currently logged on;

if yes: Decide what to do about it... and how...

if no: call function module BAPI_USER_LOCK to lock the user / BAPI_USER_UNLOCK to unlock the user, if authorized.

It would be nice if Elvira could explain what she is wanting this for (where it fits into a process, or processing of something). For all we know, a simple WAIT UP TO 10 SECONDS could solve the problem??

I fear that it will be a while yet for us to find out though... because if you look at Elvira's business card, then you will see that she has <b>never</b> logged on to SDN before (or someone deleted her TRDAT entry...

Cheers,

Julius

0 Kudos

Hi

Am not very much acquainted with the ABAP part so what i suggested is a very raw one. An ABAP developer can refine tht. The point is trhu a scheduled bkrnd job the the BFLAG field of usr02 has to be populated with 128 value to lock the user and again with value 0 to unlock the user.

Regards

0 Kudos

Hi Manas,

From what I know about the ABAP part, setting the UFLAG to '128' will not work for at least 2 reasons (the one mentioned above, and see for the 2nd reason).

There are at least 20+ programs which use the field and interpret it's value as meaning different conditions, which other system programs then also react differently to (depending on the value).

Setting the UFLAG automatically to '0' each time using a raw method (irrespective of what it was before being set to '128') would interfere with the logic of those programs, for example, by undoing the password lock.

Cheers,

Julius

Former Member
0 Kudos

I have tried the T-codes su10 and ewz5, the problem is how to get these jobs to run in the background everyday at a point in time.

I'm running Release 4.6C.

Manually locking and unlocking a user is easy. I'm looking for a way to schedule a job in the background that will lock a user everyday for a specific period of time and then automatically unlock the user at a specific period of time.

Manas suggestion sounds like it would work. Does anyone know how to schedule such job to to change the BFLAG field for usr02 to 128 and then back to 0?

Julius you are correct this is my first time logging into this forum. Hopping to get some help and continuing on using the forum in the future.

Still need some more help and Thanks to everyone.

0 Kudos

You might use this quick-and-dirty report to create jobs for locking and unlocking:


REPORT lock_or_unlock.
TABLES usr02.
DATA: it_usr02 TYPE TABLE OF usr02.
DATA: it_bapiret2 TYPE TABLE OF bapiret2.
FIELD-SYMBOLS: <usr02> TYPE usr02.
SELECT-OPTIONS: s_bname FOR usr02-bname.
PARAMETERS:
p_lock DEFAULT 'X' RADIOBUTTON GROUP lg,
p_free             RADIOBUTTON GROUP lg.

START-OF-SELECTION.
  SELECT * FROM usr02
    INTO TABLE it_usr02
    WHERE bname IN s_bname.

  CHECK sy-subrc = 0.
  LOOP AT it_usr02 ASSIGNING <usr02>.
    IF NOT p_lock IS INITIAL.
      CALL FUNCTION 'BAPI_USER_LOCK'
        EXPORTING
          username = <usr02>-bname
        TABLES
          return   = it_bapiret2.
    ELSE.
      CALL FUNCTION 'BAPI_USER_UNLOCK'
        EXPORTING
          username = <usr02>-bname
        TABLES
          return   = it_bapiret2.
    ENDIF.
  ENDLOOP.

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

Please elaborate what you refer to by "lock ... for a specific period of time each day".

Do you intend to restrict users to certain "working hours" (e.g. from 9:00am - 11:30am and 2:00pm to 4:00pm)?

Do you intend to restrict only the ability to logon (interactively)?

What shall happen if the user continues using the system beyond the time interval? Do you intend to "kick him out" (with or without prior warning)? Is it tolerable that this might result in data loss (due to unsaved data)?!

Please specify the intended system behaviour.

Regards, Wolfgang

Former Member
0 Kudos

Mr. Deser

You little program works like a charm.

Many thanks,

Elvira

p.s. Does anyone know how to reward someone points?

0 Kudos

Hi Elvira,

If resolved, pl award and close the thread.

Regards

Former Member
0 Kudos

Just want to point one thing out, if you mass lock/unlock users his way. Users that are locked by Admin will be unlocked too.

EWZ5 will be a better option.

Thanks,

Lye

Message was edited by:

Tse-Hun Lye

0 Kudos

Hi Lye and Elvira,

I am not logged on, but fairly certain that calling FM BAPI_USER_GET_DETAIL will also deliver the lock status / reason and user existence check etc, which means that the program can react appropriately to the UFLAG lock and the reason for it (if coded to do so). It would also spare the select on USR02 which might change or even be blocked.

A bigger problem I see with preventing a user from doing something from a certain point in time onwards using this lock-approach, is that the user might already be logged on!

@ Elvira Knight and ELVIRA KNIGHT regarding points: You have 2 SDN ID's now. You need to logon as the ID which created the thread (Elvira Knight originally asked the question) either by using the P- or S-number from the registration or the email address (you might need to temporarily change ELVIRA KNIGHT's email address to do that). Then you will be able to assign points for the thread which you started as Elvira Knight.

Theoretically I could add the points for you, but I prefer not to interfer in the decisions and points of SDN members (it is a free world - unless there is points collaboration...). The future of the points-system is indeed also hanging in a bit of a balance because of that reason. You can email me via the address in my business card if you need some help.

Cheers,

Julius