Changing Password of a User

[Former Member]

Hi! I'm Xavi from Barcelona. My problem is:

I do a transaction associated to a report for change the password of a user. The pasword change but when i do the first login , sap opens a prompt to change the password ,and i would like to change the password and when i do the fisrt login the prompt not open.

[nablan_umar]

Hi Xavi,

Your question is not clear. Let me re-phrase it and let me know whether it wrong

1. You have created a transaction that call a report program that can change a user password.

2. The password is changed when you ran that transaction in SAP

3. When you login to SAP for the first time, it prompted you to change the password.

4. After you done number 2, logout, then login back, it does not prompt you to change password.

The question you have is why SAP does not prompted you for changing password when you login, after you have executed your program like in item 2.

The answer is when you change you password using SU01, you are reseting the password as initial, hence when you login, it will prompt you for a new password. Your program probably did not set a field in one of the user table to indicate that it is an initial password.

Message was edited by: Nablan Umar

[VXLozano]

Hey Nablan,

I think his question is "how to force SAP to NOT show the change password prompt after change it with the transaction"

Our english is too bad 😛

I think the answer will be found locating that field who marks the pwd as initial and un-marking it.

[nablan_umar]

Now I understand completely your question. The answer is you need to set field LTIME in table USR02 to non '000000'. This is because when you reset the password using SU01, this field will be set to initial. Then when you login, the login program will prompt for changing the password if this field is '000000'. Just set is to any time except '000000'.

[Former Member]

I realize this is an old topic, but I have a program that sets the LTIME field of User LOGONDATA in order to remove the need for Users to change the passwords set by my program. My program has worked on all SAP systems since 4.6C. The program works with the changes specified in SAP Notes 750390 and 780485 as well.

I now have a customer for which this does not work. Analysis indicates that the LTIME field is not being set (yes, the LOGONDATAX:LTIME field is set to 'X' as well) despite the fact that the return code is Success. The SAP GUI still changes LTIME successfully if the password is changed by the user. The customer believes that the program failure is due to the fact that they have NetWeaver installed and it is disabling the functionality of BAPI_USER_CHANGE. I have found no documents, notes, discussions, etc. around this theory. So my question is: Does/can NetWeaver prevent an administrative user from setting LTIME on a User? If so, how can I get around this restriction?

[Former Member]

Hi Mark,

As response to your question "The customer believes that the program failure is due to the fact that they have NetWeaver installed and it is disabling the functionality of BAPI_USER_CHANGE": the user management is changed from R/3 and NW04 systems, and the function module is reviewed in NW04 to be able to protect user password and to force using Portal/SSO in the standard way, and this is done using different algorithm, so, we can't only update LTIME to <> value than '000000' because the procedure generate a check, and at the end the system identify that the user is loggin for first time, and many BC consultants are waiting for a solution to bypass this issue...good luck...

[WolfgangJanzen]

The password is supposed to be a private information ("secret") known only to the user. The user is not supposed to share this secret with other users - and the system is supposed to handle this data with care as well.

For this reason the system prompts the user to change his password when the password was set by another person (e.g. the user administrator).

This is a key security function (which is also present in most other vendors' products); it intentionally cannot be deactivated.

The only valid scenario where productive passwords are set is the "self-registration" scenario. In this case the user is triggering the creation of a new account providing the password of his choice (assuming that the system does not reject the choosen userID and/or password). Such scenarios are also supported (see SAP note 830493 for an enabling patch) - but only those.

I can only strongly recommend NOT to manipulate any system table records directly. Those data structure are subject of change (without prior notification) - even by applying corrections. Furthermore it is important to notice that normally change records are created (for auditing purposes); direct table updates will cause problems regarding the auditibility.

I'm aware that a lot of guys are implementing their own "password synchronization solution" - because SAP does not offer any support for that (see SAP note 376856 providing some reasons why such an approach is considered harmful). Most people still conclude that "logon = password logon" implies "single sign-on requires password synchronization". Well, does anyone ever have thought of replicating local Windows user accounts to hundreds of PCs ...?! No, of course not. So please, don't stick to close to passwords - for SSO other mechanisms should be used (which are not based on password authentication).

Regards, Wolfgang

[Former Member]

Hi Wolfgang,

Thank you for the detailed response. In our product the password is not shared with other Users, it is simply provisioned with the creation of the User account and password management policies create the passwords and ensure the passwords meet corporate policies. But regardless of the password value being set, my issue here is related to the ability to set the LOGONDATA:LTIME field using BAPI_USER_CHANGE. This is functionality that has been available for several years and our product was Validated by SAP labs with this capability. This functionality works with the standard R/3 and Enterprise R/3 platforms. If this functionality does not work with NetWeaver, then it has been changed without any apparent developer notification. This places a great burden on developer partners such as my company. Also, this is not a question of changing system table records directly. We are using SAP's certified interfaces.

I also appreciate that customers may not always be wise to choose certain password synchronization methods instead of using SSO technology, but I am in no position to dictate the requirements and desires of my customers.

So the question remains: Has SAP intentionally altered NetWeaver security to prevent the ability to set a persistent, administrator-set password via the BAPI_USER_CHANGE LOGONDATA:LTIME field? Does NetWeaver effectively override the security features of the R/3 platform?

[WolfgangJanzen]

Hi Mark,

sorry but I think that you are not right stating that using BAPI_USER_CHANGE with setting LOGONDATA-LTIME was considered a "legal feature" (as part of a validation).

If you take a close look on the function module documentation (in SE37) you'll see that LOGONDATA-LTIME is marked as "For internal use only" (same as LOGONDATA-BCODE and LOGONDATA-CODVN).

The system enforces now what has been specified in the interface documentation: it checks if invalid input value combinations are used.

Please notice: the BAPI itself was not changed and no certified interfaces have been invalidated. Because the BAPI interface covers only those features that are not marked as "For internal use only".

The discontinuity of "bug features" (i.e. features that did work but are not intended to work) always causes complaints. But in this case the enforcement of assured security features (i.e. that an administrator cannot set a non-initial password for a normal user) had a higher priority which did justify that painful cut.

"Does NetWeaver effectively override the security features of the R/3 platform?"

Definetly no - take a kind look into SAP note 2467 (which is pretty old) to see that this security feature was present since decades.

Of course there is also some progress in the security functions. So, not surprisingly NetWeaver offers enhanced security features in comparison with the R/3 platform.

To a certain degree downwards-compatibility has to be abandoned for the sake of progression. For example: with the next NetWeaver version (NetWeaver 2004 S, based on WebAS 7.00) the ABAP stack made some significant progress regarding password policies. However it was necessary to modify some internal data structures in order to accomplish this task. For those that have implemented own coding operating directly on those data structures (which anyway is not recommended) this will have some negative consequences (old coding will fail to work). However those that only use the APIs are not effected.

Regarding password synchronization:

it's not a matter of implementation - the entire approach is subject to failure (by nature). Knowing that, it is our duty to prevent anyone from falling into the trap - e.g. by documenting the constraints (=> SAP note 376856) and by actively preventing unintended usage of provided APIs.

Preventing customers from falling into traps has nothing to do with dictating requirements / desires. I hope you can agree with me.

Wolfgang

[Former Member]

Hi Wolfgang,

Thank you again for your detailed and prompt response. I am afraid I must differ with your conclusions about preventing customers from falling into traps. Although I personally agree with your views on SSO and personal password maintenance, we have found that many customers prefer a centralized password management and synchronization even if it carries many liabilities. They are willing to accept a security risk if it solves their more immediate and costly problems. I will pass on the valuable information you have provided and hopefully the customer will come to see SAP's point of view regarding the prevention from "falling into traps"!

Best regards,

Mark

[WolfgangJanzen]

Hi Mark,

then maybe let me add the following remark:

the main counter-argument against password synchronization is not security risk (i.e. having the same password in all systems) but robustness and correctness.

It can simply happen that it is impossible to set the same password in all systems (because the password might violate a local password policy of some of the systems, or because some systems are temporarily not able to process the password change request, or ...).

And guess what happens, then?

They will report a support case which will first be send to SAP where it will be analysed (notice: such problems are not reproducable in most cases => problem analysis might take time) and finally delegated to the partner. In the end someone will have to tell the truth to the customer: "sorry, but this is an intrinsic problem; it cannot be resolved (in general)." And SAP will add: this is known since a long time, before (pointing to note 376856).

SAP considers itself as "Trusted Advisor".

I strongly believe that "educational work" is part of it.

Best regards,

Wolfgang

[Former Member]

Hi Wolfgang,

My company's password synchronization product is designed to handle and report password policy violations, allow system specific policy, handle non-availability of the target SAP system, etc. so most of those concerns are addressed for our customers as long as they are not trying to use CUA to sync passwords between systems (We see that as a pure SAP concern.)

We have customers who use automated "background" authentication (SSO) technology. In these environments, a certificate/smartcard authentication is utilized to authenticate to an authorization store (LDAP). The password for the SAP accounts are auto-generated and the User never even knows what it is. If we can't allow an administrator account to set this automated, reusable password their security model is violated.

Our software informs the central authorities of password setting issues (policy violations, system non-availability, etc.) so the customer is always aware of what can happen. I do realize that there are alternative SSO options for SAP authentication, but it is difficult to tell customers how to run their business, as I am sure you know.

However, I will certainly pass on your advice and warnings related to SAP's concerns. They are certainly serious issues to consider. At this point I am obviously blocked from delivering a solution using the password synchronization on the customer system. If I might ask for some final clarification, I have an additional question:

Our product works for all versions of SAP from 4.6A up to WAS 6.40 (SAP Basis version 620). Our methodology has been to set the password, then read BCODE and CODVN, and then re-write BCODE, CODVN, and a generated LTIME value. This is done according to direction from SAP Notes 750390 and 780485. I ask this question because I would like to clarify for our customer exactly why the sync does not work on only their NetWeaver host system. So the question is:

I would like to know definitively if it is a NetWeaver-related patch or a general OS patch that is causing the failure of password synchronization. If you have specific information, it would be very greatly appreciated!

Thank you and best regards,

Mark

[Former Member]

Hi Janzen,

I agree about all the point discussed there concerning user/password security, but, just to ask you about your point of you for this solution published inside this site to prevent user to introduce his initial password:

Follow the below steps in order:

1. Make a RFC call to BAPI_USER_CHANGE

- input values: Username [USERNAME], New Password [PASSWORD-BAPIPWD] and update flag for password [PASSWORDX-BAPIPWD]

- [USERNAME] must hold the name of the user whose password needs to be reset.

- Set the update flag to 'X'

- New password MUST be specified in UPPERCASE letters

2. Again make a RFC call to BAPI_USER_CHANGE

- this time you must change the last logon time to current time by setting the structure field [LOGONDATA-LTIME]

- set [LOGONDATAX-LTIME] to 'X' (update flag for logondata's LTIME value)

- this is to prevent the 'change password' dialog to appear when you logon next time.

3. Again make a RFC call to BAPI_USER_UNLOCK

- this time you must unlock the user account

- in case the user account had been locked already for some reason this will unlock that.

[WolfgangJanzen]

Hi Mark,

sorry but I doubt that any product (including "DirXML") is able to resolve all intrincic problems mentioned above; especially the fact that each system holds (and controls) its local password history will cause problems when the password once has run out of sync. Only by dirty DB table syncs you would be able to "resolve" the problem (=> resynchronization). But that only works when the data structure remains unchanged - which is not the case (USR02 was changed in 6.20 and another time in 7.00).

Regarding your comment that "the password for the SAP accounts are auto-generated and the User never even knows what it is". That does not make the slightest sense: what are the passwords for, then? That only imposes a security risk (since passwords can be guessed). If the user does not know the password he will not be able to use it. In such a case it is strongly recommended not to assign a password at all (notice: as of 4.6x it is possible to "deactivate" a user's password, see note 780485).

Regarding your last question:

yes, this is a general patch - not only effecting SAP NetWeaver but all ABAP systems (down to 4.6x). That is explained in note 750390; it states that it used(!) to be possible to call BAPI_USER_CREATE/CREATE1/CHANGE in a way which was not intended (to be possible). The note contains a correction that will prevent this (unintended mis-)usage.

Regards,

Wolfgang

[WolfgangJanzen]

Hi Aziz,

I have not verified whether the procedure you've described works but please keep in mind: every usage that is not intended might be considered a malfunction which might be discontinued by some future correction.

So kindly stay on the safe side and only use the API functions in a way that is <u>documented</u>. As you see (e.g. in note 780485) we enhance the documentation, if required, when an intended ("legal") API function usage was not covered by the documentation.

<b>Please resist from using undocumented features</b>.

If you believe that a feature is missing contact us to clarify the issue. Maybe the feature is either already existing but not documented (in that case the documentation should be updated) or not implemented but considered useful (in that case it might be implemented in a future release and, if possible, downported to previous releases; see note 830493 for example).

Regards,

Wolfgang

PS: for those who might not know, yet:

The SAP Security Product Management team will

respond to mails send to <b>security@sap.com</b>.

You can use that mail address to submit general

questions but please do not misuse that mailbox

to submit problem messages.

[Former Member]

Hi Aziz,

What you propose is exactly what my product was doing to make a password persistent. This was changed later due to an SAP patch to set BCODE, CODVN, and LTIME together. My product sets a PASSWORD with BAPI_USER_CREATE1 or BAPI_USER_CHANGE (no need to uppercase, the API handles that), reads the LOGONDATA and then resets everything with the current LTIME value. This worked for all releases until very recently, so it is a fairly current patch that changes this functionality. As you have seen on this thread, Wolfgang has stated that it is this procedure that is not considered "legal" behavior. The LTIME, CODVN, and BCODE fields are flagged for "INTERNAL USE ONLY" and can no longer be dependably used.

[Former Member]

Hi Wolfgang,

DirXML? Did I say DirXML?

I realize this forum is not the place to discuss the functionality of non-SAP products and is certainly not the place to discuss the way those products are used by customers and if they make sense or not. It is enough for me to know the new restrictions of the SAP interfaces I am using. I appreciate your time in sharing this information.

If it is not too much trouble, do you know if there are any similar restrictions on the use of SUSR_USER_CHANGE_PASSWORD_RFC? I saw that it was recommended to developers of web sign-on products on another thread. I saw no "Internal Use Only" flags or other warnings about it's use, but there is not much documentation available for it in English. I may be able to solve many of my product issues with this function, but my customer would like to know if SAP will support it's current functionality going forward or if it too will be restricted in the future.

Thanks and best regards,

Mark

[WolfgangJanzen]

Hi Mark,

I've used Google to determine which company you are working for ... (search for "Mark Worwetz").

(PS: sorry to disagree - but if those non-SAP products state to be "SAP certified" and if arising problems will be reported to SAP this is a topic for SDN; I strongly believe in preventive actions - warning on known issues is one of it).

Regarding SUSR_USER_CHANGE_PASSWORD_RFC:

notice the function documentation - it clearly states that this function is intended to be used (only) when a user changes his own password. In contrast to BAPI_USER_CHANGE (respectively SU01) this function will not require user administration authorizations and will also not result in an initial password (that will need to be changed by the user) - but it will prevent passwords to be set that have been chosen previouly by the user (password history). And, SUSR_USER_CHANGE_PASSWORD_RFC will also check that the old and new passwords are different (as of 6.20 a "minimal password distance" can be customized).

I've heard of some "smart guys" that combined RSEC_GENERATE_PASSWORD, BAPI_USER_CHANGE and SUSR_USER_CHANGE_PASSWORD_RFC in a way that a random (intermediate) password is set by BAPI_USER_CHANGE that will be changed immediately afterwards using SUSR_USER_CHANGE_PASSWORD_RFC. The problem is that those password rules mentioned above (password history, password distance) might prevent the password change. And in future we might implement additional password rules ... (on customer request).

<b>Please notice that the mixed usage of function modules that are intended for administrative usage and user usage is also a kind of "API misuse".</b>

Officially SUSR_USER_CHANGE_PASSWORD_RFC is not a BAPI (but just an ordinary function module). That's why the documentation of that function module is very weak. One weak point of that function module is that it does not return very detailed error information (e.g. on the reason why a new password is rejected = which password rule was violated).

Regards, Wolfgang

[Former Member]

Hello Aziz, I tried using your technique but unfortunately using BAPI_USER_CHANGE returns with sy-subrc = 0 and return structure message as success but does not really make the change. Permission and security settings seems to be okay for the RFC destination. I tried my as well as another valid user id and valid new password. Any ideas, help...

[WolfgangJanzen]

Hi Satyajit,

please have a kind look on the conversation Mark and me had previously. That should provide some insights into this topic (motivation, background information).

Regards, Wolfgang

[Former Member]

Hello Wolfgang,

Read through this topics conversation and I agree with you and that is why I would like to have a "legally valid", "sap approved" and "business okayed" solution. In our case the business does require this password change (to be done only on non production systems) by the tool/ program. Our firewall and BSP will make sure only valid users get to this tool and also the user will see only his approved non production systems and clients. We have CUA method here. So what is the sap approved solution?

[WolfgangJanzen]

The only "legal" / "approved" / "supported" method to set a non-initial password for an existing user is to let the user change his/her password (providing the old and new password). The RFC-enabled function module SUSR_USER_CHANGE_PASSWORD_RFC can be used for that.

The only "legal" / "approved" / "supported" scenario where a non-initial password is set for a non-existing user is a self-registration scenario. BAPI_USER_CREATE(1) has an (optional) parameter (SELF_REGISTER) to request that feature (see also SAP note 830493).

Once again: any password synchronization "solution" is not supported (see also SAP note 376856).

Please notice: instead of using passwords (=> requirement to synchronize them if using multiple systems) it is possible (and recommended) to use Single SignOn (SSO) solutions. Most SSO solutions are also available for other products. This allows to use one single SSO mechanism for SAP and non-SAP products.

Regards, Wolfgang

[Former Member]

Wolfgang,

Thanks for your suggestions / thoughts. Function SUSR_USER_CHANGE_PASSWORD_RFC does not work for our requirement as the user does not remember the current password (that is why the user wants to reset it).

The user already exists so BAPI_USER_CREATE also does not work for us.

However trying BAPI_USER_CHANGE does not work where I pass Username, password, passwordx and ADDRFC tables / parameters. Am I missing out on something or some wrong parameter or value? The BAPI comes back with status okay and changed message in return table but does not really change it.

[WolfgangJanzen]

BAPI_USER_CHANGE is intended to be used by user administrators (=> requires proper authorizations).

How should a system make sure that only the effected user and not another person (which could also be an attacker) is requesting to reset the user's password?

We recommend that any service which offers such a "forgotten password" self-service first prompts the user for some data (of course not the password) which is supposed to be known only by the user (e.g. birthday). That will prevent at least some unauthorized password reset attempts.

In addition, the system should not allow the (unauthenticated) user to set a new password. Instead the system should generate a random password and send it to the mail address retrieved from the user record. Only the user which has access to the mailbox will be able to read the generated password (plus those guys that know how to capture mail traffic). You might also use other message transmission mechanisms (such as SMS / pager / ...).

When the user logs onto the system using the obtained generated password he will be asked to change the password (since we assume that noone can remember such a generated random password) to a password chosen by him.

Kind regards,

Wolfgang

[ashok_baskaradu]

Hi Satyajit

I am looking for simillar solution, Can you share your java code working one.

Thanks

Ashok

[adrian_fischer]

during my tests I am happy with that code, everything works (productiv passwd, ltime, etc.)

the methodes for snc deliver snc-pname und snc-guiflag, sncx X for both parameters

IF cb_pwprd EQ 'X'. "Checkbox from Selectscreen
lv_pwprd = 'X'. " X=Set productiv Password
ELSE.
lv_pwprd = ` `. "` ` = Standard User has to change first time
ENDIF.

CALL FUNCTION 'BAPI_USER_CHANGE'
EXPORTING
username = plv_user
snc = zisbzcl_tools=>build_snc_name( iv_user = plv_user iv_guiflag = 'X' )
sncx = zisbzcl_tools=>build_sncx( )
password = gv_passwd
passwordx = 'X'
productive_pwd = lv_pwprd
* GENERATE_PWD = ' '
* IMPORTING
* GENERATED_PASSWORD =
TABLES
* PARAMETER =
return = lt_return.
LOOP AT lt_return ASSIGNING FIELD-SYMBOL(<ls_return>).
IF <ls_return>-type CA 'EA'.
FORMAT COLOR COL_NEGATIVE.
WRITE: / 'Allgemeiner Fehler bei Passwort setzen im System ', sy-sysid, '-', ' für User: ', plv_user, ` `, <ls_return>-message. "#EC NOTEXT
FORMAT COLOR OFF.
ENDIF.
ENDLOOP.