Self-service for resetting password on systems connected to a CUA

[Former Member]

Hello all,

We are currently trying to implement a self-service for users to allow them to reset their password on systems which are connected to a CUA (in case they have forgotten their correct password).

On the backend-side we want to access the CUA-System via RFC and then call the necessary function modules, BAPIs or own programs there.

One attempt was to use BAPI_USER_CHANGE but this FM only changes the password of the user in the CUA-system, not in any of the child systems.

Indeed, executing BAPI_USER_CHANGE in one of the child systems doesn't work either. We get a success message but the password remains unchanged, so another idea, namely to call the FM via RFC on the child system (from the CUA-system) can't work either.

The second attempt was to use SUSR_ZBV_USER_SEND. Here, the problem is that we need the <u>hashed</u> password as input and we don't know how to get this from a given password (we tried the C-function XXPASS but this can't be used except in a restricted number of SAP standard modules, it seems).

Does anyone have ideas on this?

Either ideas on how to resolve the problems I illustrated

or ideas for a different solution?

Cheers,

Kathy

[Former Member · Accepted solution]

Hi Katharina,

The BAPI_USER_CHANGE does work in the the child system, however you will notice that password is changed to capital letters when the FM is executed. Since in the newer versions of SAP, password is case sensitive this is the problem that you would need to resolve.

If you are still experiencing a problem changing the password, please take a look at your settings in transction SCUM on your CUA master client - you may need to allow changes to passwords everywhere.

Hope this helps.

Sujeet

[Former Member · Accepted solution]

Hi Sujeet,

Thanks for your reply. We have solved our problem. We changed the SCUM settings on the CUA master client and allowed passwords to be changed locally as well as globally. We had a small obstacle there because one of the systems needed a patch, but now things work.

We would have preferred to implement a programm that changes the password on the master client directly instead of doing an RFC-call on the child systems, but we didn't find a way to do this.

The potential problem you described with the FM BAPI_USER_CHANGE changing the password to capital letters didn't occur with us.

Thanks again for your reply.

Regards,

Kathy

[Former Member · Accepted solution]

Hi Katherina,

I am doing exactly the same application as you, and came across the same problem.

I really didn't want to set the password in the child systems, however, (I didn't want to rely on child systems having the change BAPI available if they were older versions) so I found a way of generating the hash value (I hesitate to post this in case our SAP friends decide to close this loophole also...) in the CUA master for passing to SUSR_ZBV_USER_SEND.

What I do is call the function SUSR_USER_PASSWORD_PUT as if I am changing the password in the CUA directly, but what this function does is generate the hash value and stores it in the buffer (global memory of the function group). It does not actually change anything in the database (the subsequent function SUSR_USER_BUFFERS_TO_DB is required to write the buffer changes to the database).

We can then call the function SUSR_USER_LOGONDATA_GET to retrieve the user data from the buffer (including the hash value). You can then call the SUSR_ZBV_USER_SEND function to distribute the user password change with the hash value. When the program finishes execution the buffer is cleared, so we achieve exactly what we need.

A sample program I wrote to test this looks like:

REPORT  ZZTEST.

* Testing
  parameters: lv_user type syuname,
              lv_pass type XU400-NEWCODE.


  data: lv_userdata type USLOGOND.

  CALL FUNCTION 'SUSR_USER_PASSWORD_PUT'
    EXPORTING
      USER_NAME                     = lv_user
      PASSWORD                      = lv_pass
    EXCEPTIONS
      USER_NAME_NOT_EXIST           = 1
      PASSWORD_NOT_ALLOWED          = 2
      PASSWORDS_NOT_EQUAL           = 3
      OTHERS                        = 4.

* If function call ok.
  if sy-subrc eq 0.

    CALL FUNCTION 'SUSR_USER_LOGONDATA_GET'
      EXPORTING
        USER_NAME                 = lv_user
      IMPORTING
        USER_LOGONDATA            = lv_userdata
      EXCEPTIONS
        USER_NAME_NOT_EXIST       = 1
        OTHERS                    = 2.

  endif.

I know you have solved this another way but just FYI to yourself and anyone else.

Cheers,

Brad

[Former Member · Accepted solution]

I know this is a couple of years later, but do you know which note you had to install to get this fixed? I have changed my SCUM settings to both global and everywhere and neither change the password in the child systems. The documentation says that this is all I should need. I have tried looking through the available notes and I cant find the right one.

Thanks,

brendan