Programmatically changing passwords

[Former Member]

We have a program written years ago which was designed to assign random passwords to DDIC and other privileged accounts. It uses a fixed seed and function module RSEC_GENERATE_PASSWORD. The problem is, the random password generated is of CHAR format. When I try to put it into USR02-BCODE, it does not convert. I cannot find any kind of conversion function module which will provide the desired results. Like said, this program has been around forever, and "they" claim it worked at one time. Can anyone suggest a way to do this, or better yet, is there a more modern method of randomly generating password programatically.

Thanks,

-d.

[mvoros]

Hi,

wouldn't be better to use standard BAPI to change password instead of direct access to USR02. BAPI BAPI_USER_CHANGE allows to set productive password. It requires that user is logged on via SNC. As a workaround for this you can use FM used inside this BAPI. It has a parameter to disable this check.

Cheers

[Former Member]

RSEC_GENERATE_PASSWORD is obsolete, and USR02-BCODE is obsolete in higher releases without backward compatibility as well.

Use SUSR_GENERATE_PASSWORD and import the password into BAPI_USER_CHANGE to form the required hash in USR02-PASSCODE. Then nothing can go wrong.... (touch wood.)

Cheers,

Julius

[Former Member]

I checked the source code of SUSR_GENERATE_PASSWORD on ECC6 EHP4 : it just calls RSEC_GENERATE_PASSWORD...

Regards,

Olivier

[Former Member]

BAPI_USER_CHANGE is changing the password I enter to Upper Case. Our passwords require a mixture of Upper and Lower Case. How can you prevent this?

[Former Member]

When you single test the FM, then there is a little check box to import parameters case-sensitively.

When calling the FM there is a syntax to set this (make sure you type the field correctly and check the key word CALL FUNCTION in tcode ABAPDOCU! - as I cannot remember exactly what the extention / declaration is).

If you do a where-used-list on SUSR_GENERATE_PASSWORD then you will find where the exported values are imported and what the syntax is.

Cheers,

Julius

[Former Member]

Hi Oliviier,

I see that SAP has now moved the downward compatibility checks to the inside the the RSEC function. In earlier versions it did not respect this. Perhaps they do this at major release changes?

But AFAIK the SUSR one is the stable API --> new features might be introduced before calling the RSEC one, as they have been in the past.

But yes, for the moment you are correct (also on my system).

Cheers,

Julius

[Former Member]

Forgive me for appearing totally clueless, but how do you check the box inside of a program? I do not see that field as an input parameter nor in the code?

Thanks.

[Former Member]

Please post your code for the data declaration of the password to verify that it is not converted there. Is it XUBCODE?

The imported password must be the BAPI structure BAPIPWD, then call the BAPI using this password (whatever it is...)

Cheers,

Julius

[Former Member]

That will not be necessary. I think I have found a workable solution. When I used SUSR_GENERATE_PASSWORD it would not generate a password with mixed case, even if I checked the box. I ended up calling RSEC_GENERATE_PASSWORD directly and giving it a seed with mixed case. This gave me the results I wanted,even though it only returned and upper case for an upper case and a lower for a lower. I can live with that. Thank you for your assistance.

[Former Member]

I would still recommend SUSR_GENERATE_PASSWORD (IF FOUND), particularly if you plan to transport this tool to other systems on different releases, where the RSEC_GENERATE_PASSWORD has different import parameters (or you upgrade your system and then they change!).

What you are looking for to specify the maximum number of password wizard parameters (such that they still comply with the minimum system parameters!) is described in [SAP Note 915488 - Customizing switch for password generation|https://service.sap.com/sap/support/notes/915488].

Cheers,

Julius