SAP NW ABAP Password Deactivation - via BAPI

[Former Member]

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,

Ralf

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.

[Former Member]

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 .

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

Cheers,

Julius

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... .

[Former Member]

Hi Julius,

thanks for your response ... .

I thought of dynamically creating an RFC destination for the user-id and trying to call RFCPING sufficient number of times with the wrong password - until the user gets locked. But that programmatically not really slick and it should also trigger security incidents (in this partially perfect world we are all aiming at).

The portal is a service portal (ESS), so there are no real logons via the portal. I did not (re-)test this in newer versions of SAP NetWeaver, but according my current view and understanding USR02-TRDAT is not updated when RFC logons happen - only when dialog logons take place.

In the case I am talking about, I can actually "see" in USR02-TRDAT whether proper password logons are being done under the user-id ...

Thanks anyway ...

Ralf

[Former Member]

Hello Ralf,

I just tested BAPI_USER_CHANGE.

It worked fine to deactivate the password... C

You need to activate the structure as well... X

Cheers,

Julius

[Former Member]

Dear Julius,

I knew I overlooked something here ...

When I test-run BAPI_USER_CHANGE on a 6.10 system, I did set USERNAME to"JBROWN" (well - WA1 system), PASSWORD to ' ', PASSWORDX to 'X'.

And I got a result:

E 00 188 The first three characters of a password must all be different

Obviously the password was not deactivated this way.

What exactly did you do ?

Regards and thanks,

Ralf

[Former Member]

Hello Ralf,

I am not to sure about a 6.10 system. Haven't seen one of those for a while now.

On an up-to-date patched system: Set the LOGONDATA-CODVN = 'X' (it will also default bcode to 0000000... not that that means very much though...) and activate the structure(s) as you wish.

Cheers,

Julius

PS: It is in the LOGONDATA structure. Not PASSWORD.

Message was edited by:

Julius Bussche

[Former Member]

Dear Julius,

thanks - this works indeed. Even on 6.10. Authorizations checked are S_USER_GRP / 02 (which is sort of wrong as you can also activate/set the pw with this call ...).

I saw that there are these fields in the LOGONDATA structure, but I did not dare to use the whole structure and I did not see that you could activate parts of it ... Thanks for that hint !

Regards,

Ralf

[Former Member]

Glad to hear that you got the first part working. Now to find the users to do it to...

My opinion: Actvt 02 is not necessarily wrong - classing the password deactivation as being a change to the user record... it's permitted authentication method. After all, you did not change the password (actvt 05).

For your information, in higher releases, BCODE is no longer evaluated as it does not store the password hash there any longer when using higher CODVNs.

For the record: "Hacking" things into USR02 can have horrible consequences. I have heard that if you get things wrong and cause a mess... then SAP can even elect to cancel support of the system. According to <a href="https://service.sap.com/sap/support/notes/7">SAP Note 7</a> it did not take long for the first person to find this out...

Cheers,

Julius

[Former Member]

>> which is sort of wrong as you can also activate/set the pw with this call...

No. The BAPI checks the authority based on which structure you have activated and the data in the structure. It even checks S_USER_GRP, S_USER_AGR etc depending on what you are trying to change.

The definition of a BAPI is that it behaves exactly the same as the transaction code functionality it corresponds to (when exposed to the BAPI interface). So that which it provides which is analogue to SU01, it checked for the same authority.

Cheers,

Julius

[Former Member]

Hi Julius,

well, hmm ... in authorizations it is always difficult to call something "right" or "wrong". Should not have used these terms.

What I meant was:

SU01 with S_USER_AGR / 01 allows you to create a user. Unfortunately you can also set the initial password then.

But after that, SU01 always seems to require S_USER_AGR / 05 for password resets (and user locks / unlocks of course).

SU01 with just S_USER_AGR / 02 still allows to deactivate the PW, but does not allow me to set it ...

Based on that it is possible to create SoD between user creation (01), user change & role/profile assignment (02,22) and user lock / unlock / pw resets (05, helpdesk). The fact that 01 allows to set up an initial password is not helpful here - but we can live with that ...

The BAPI works differently:

- BAPI_USER_CHANGE with just a password reset (PASSWORD / PASSWORDX) seems to require both S_USER_GRP / 02 and 05

- BAPI_USER_CHANGE with LOGONDATA / LOGONDATAX requires S_USER_GRP / 02 ...

My point is: The BAPI doesn't provide the same split between helpdesk functions (05) and the other functions (01, 02/22).

I should not have called it "wrong" for another reason: Documentation of S_USER_GRP does not talk about password resets at all - so there can't be anyting wrong about this anyway ))

I guess in any case we are touching an area that is a bit sophistic ...

Best regards,

Ralf

[Former Member]

Hi Ralf,

This might be a support pack problem, but then you are on an ancient SP level... (see SAP note 191752). Besides, that was changed before 6.10.

>> SU01 with S_USER_AGR / 01 allows you to create a user.

No. S_USER_GRP

>> SU01 with just S_USER_AGR / 02 still allows to deactivate the PW,

>> but does not allow me to set it ...

I would see that as correct behaviour, except it is S_USER_GRP.

>> BAPI_USER_CHANGE with just a password reset (PASSWORD / PASSWORDX)

>> seems to require both S_USER_GRP / 02 and 05

My guess is that you have another "change related" (02) structure activated (for example you are not <b>re</b>-testing the FM with only the password change).

I still think it's an interface problem (between the chair and the keyboard ))

Cheers,

Julius

[Former Member]

Hi Julius,

I will retest to exclude "interface" problems.

And sorry - S_USER_AGR is a typo. Should have been S_USER_GRP all the time.

Regards,

Ralf

[Former Member]

PS: Wolfgang's <b>programmatic</b> suggestion can also answer the <i>"Now to find the users to do it to..."</i> question, in that they can do it to themselves.

Kind regards,

Julius

[WolfgangJanzen]

<u>Notice</u>: function module SUSR_DELETE_OWN_PASSWORD can only be called if the (RFC) connection was established using a non-password based authentication mechanism (e.g. SNC).

If you are able to identify the users which do not require passwords for authentication, then the best approach is to deactivate their passwords (by one of the declarative approaches). NWAS ABAP 7.0 also allows you to define a maximum lifetime of idle (i.e. unused) passwords - for <i>initial</i> as well as for <i>productive</i> passwords. That's maybe the best approach.

PS: BAPI_USER_CHANGE (as well as the other BAPI_USER_... function modules) is intended to be used only by user administrators - but not by end-users. That's why those S_USR_... authorizations are checked.

[Former Member]

One could even go a step further to say that function modules should only be used by programs, which are then run by user administrators when they start the corresponding transactions.

At least... that is the way we do it.

Cheers,

Julius

[WolfgangJanzen]

No, that's too strict.

Each function module has a (hopefully well-documented) interface (-> syntax) and scope (-> semantic). There are function modules that are intended to be used only by persons with special authorizations and others which are less restrictive.

A good example (unfortenately also one which is often found) for misunderstanding that concept is the mixed usage of functions which are intended to be used only by user administrators (such as BAPI_USER_CHANGE) and those that are intended to be used by end-users (such as SUSR_USER_CHANGE_PASSWORD_RFC). Whilst each of those two function modules works properly on its own, the combined usage of both might not - at least not in a reliable way (because of the password history check which will be performed - and whose result cannot be "predicted").

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

It's like with mathematical statements - most of them do have a precondition clause which you better not ignore ... (<a href="http://en.wikipedia.org/wiki/Ex_falso_quodlibet">"ex falso quodlibet"</a>).

[Former Member]

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)... (<a href="http://en.wikipedia.org/wiki/De_Morgan%27s_laws">de morgan duality</a>).

[WolfgangJanzen]

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

There are two ways to achieve this:

(a) <b>declarative</b>: see <a href="https://service.sap.com/sap/support/notes/441452">SAP Note 441452</a> (login/password_change_for_SSO = 3), <a href="https://service.sap.com/sap/support/notes/862989">SAP Note 862989</a> (login/password_max_idle_initial

, login/password_max_idle_productive) and <a href="https://service.sap.com/sap/support/notes/379081">SAP Note 379081</a> (login/disable_password_logon)

(b) <b>programmatic</b>: see <a href="https://service.sap.com/sap/support/notes/869218">SAP Note 869218</a> : 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.