Skip to Content
author's profile photo Former Member
Former Member

SAP NW ABAP Password Deactivation - via BAPI

Dear colleagues,

I need to deactivate passwords of user-ids that don't use password logon regularily. The more simple locking of the User-ID (BAPI_USER_LOCK) is not a feasable option as those user-ids need to stay unlocked for Logon-Ticket based access from the portal.

Password deactivation has to be done in a batch job: The job will "observe" that password based logon has not been used for a while (based on USR02-TRDAT as the portal logons are RFCs) and then deactivate passwords.

There is no problem to do this via SU01. Authorizations required are S_USER_GRP / 05 / ... . Just "Deactivate" in the password pop-up. Fine.

But as we need to do this via a background job, I tried to find a more slick way than Batch Input Sessions: An official BAPI or at least a handy (and sufficiently stable) function module to deactivate the password. But I failed ... . I seriously wonder whether I just overlooked it ...

I found what SU01 does - it finally calls SUSR_USER_PASSWORD_PUT, but there are too many things left and right to re-implement before and after it does that ... . SUSR_USER_CHANGE is not a help as well. And I don't what to mimik the effect of SUSR_USER_PASSWORD_PUT by "hacking" 0s into BCODE and 'X' into CODVN 😊

So: If anybody knows a handy way to deactivate the password of an individual user from within an ABAP, let me know. Your help is greatly appreciated.

Best regards,


p.s.: A BAPI that would set the lock for "too many invalid password attempts" (hex 80 in USR02-UFLAG) would also do the job ... - but I couldn't find this one as well.

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

2 Answers

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on Dec 02, 2007 at 08:18 PM

    Hello Ralf!

    Initially I thought you were trying to "discriminate" between different types of "idle users" based on some criteria (user group or a role); but reading it twice - I think that is not the case, right? Is it a "service portal" or a "logon portal"?

    Instead of USR02... you might want to try user-locked-but-su01-showing-it's-not-locked.

    I am not logged on, but if you do a where-used-list search on it then you might find something usefull.



    PS: Locking a user's password does not in my opinion require a specific BAPI. Just logon N times with the password 'banana12' => locked (unless the password happens to be correct... 😊.

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Wolfgang Janzen

      Hello Wolfgang,

      We worked hard at it and have reached a status in (production and related systems which require the same status) systems where only an emergency user can execute a function module outside of a CALL FUNCTION program context (i.e. they cannot directly maintain the interface of any function module, and, single-test it - that is what I was refering to). The remote invocations of the CALL FUNCTION was and is trickier, but I beleive that we continue to head in the right direction (including the authentication mechanism).

      The idea behind an emergency user for such activities is not to be too strict... but rather to make exceptions (to the coded program context) transparent and auditable.

      There are the odd functional consultants who required it (developers were not a problem at all because they understood why we did these "strict" changes), but these can be isolated into their program contexts as well (typically Z) and often highlighted programming / requirement / testing deficiencies (which can generally be solved, sooner or later).

      >> Well, you always have to pay intention to the "usage constraints".

      Yes, I agree. We restricted the S_DEVELOP program names (see above - for example) they are authorized for, but strive to eliminate them all (bar logged exceptions)... (de" target="_blank">">de morgan duality).

  • Posted on Dec 03, 2007 at 04:38 PM

    > I need to deactivate passwords of user-ids that don't use password logon regularily

    There are two ways to achieve this:

    (a) declarative: see SAP" target="_blank">">SAP Note 441452 (login/password_change_for_SSO = 3), SAP" target="_blank">">SAP Note 862989 (login/password_max_idle_initial

    , login/password_max_idle_productive) and SAP" target="_blank">">SAP Note 379081 (login/disable_password_logon)

    (b) programmatic: see SAP" target="_blank">">SAP Note 869218 : SUSR_DELETE_OWN_PASSWORD

    Regards, Wolfgang

    PS: <i>"[...] Documentation of S_USER_GRP does not talk about password resets at all - so there can't be anyting wrong about this anyway 😊)) [...]"</i>

    Wrong conclusion - anything which is not clearly documented might not work; good advice: do not use undocumented features - they might vanish / change at any point of time.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.