5.3 Firefighter Security Table "New" Comments Field

[Former Member]

Since upgrading from 5.2 to 5.3, I noticed that there are new "comments" and sometimes "decription" fields throughout the different FF tables. I decided to test entering data in these fields. After doing so in the "comments" area of the "Security" section firefighter, I noticed that the encrypted FF password changed to something else (which was also encrypted). I tried to invoke the ID where the password had changed and sure enough I received an error that the passord was incorrect. I changed the password back to what it was supposed to be and it appeared to look just like the other encrypted fields (back to normal). However, now when I use the ID, a message stating that the ID does not exist appears.

Why did entering data in the "comments" field change the password? Why do I now get a message that the ID doesn't exist after setting the correct password back up? Has anyone else seen this and is there a fix?

Greg

After entering this message, IE gave an error message "Mismatched address - The security certificate presented to you by this website was issued for a different websites address. This problem may indicate an attempt to fool you or intercept any data that you send to the server". That's why there are three messages for the same posting.

Edited by: Gregory Cook on Oct 8, 2009 2:58 PM

[Former Member · Accepted solution]

There is a problem with the site at the moment, the other 2 copies are deleted. The system automatically sends a nasty mail, don't take it personally

Back to the real question...

The reason for this is that the approach to managing the password has changed, but it appears that some misleading error messages are still in the coding.

The password is no longer set once and decrypted to modify the RFC connection on the fly, but rather at each successfull request a new password is generated (albeit using a wrong legacy function module) and used "on the fly" via BAPI_USER_CHANGE and the RFC connection as well.

This makes it look as if the "Comments" field which is immediately before this generation is changing the password hash... but it's not.

This prevents the problem of the admin knowing the password - as you have also stated - and the algorithm being reversed (which is generally possible when using two way encryption / decryption functions, as opposed to one-way-hashes on the server side which are more secure).

The catch is that you now need to set the user's password at each request after successfully generating the password. This procedure in BAPI_USER_CHANGE checks activity '05' of object S_USER_GRP for the FF user's group assignment. If you do not have this authorization yourself, the "on the fly" logon presents a new password to the RFC login screen (the check is remotely disabled so nothing can go wrong...) but the SU01 password has not changed.

The "fix" is to assign this S_USER_GRP authority very carefully and ensure that the requesting user preferably does not have direct access to SU01, SU01_NAV and BAPI_USER_CHANGE themselves. Also make sure that they do not have authority for the debugger (object S_DEVELOP, even is display mode).

Cheers,

Julius

[Former Member · Accepted solution]

Thank you for your response...very helpful.

I do have a question and need some clarification revolving around "The catch is that you now need to set the user's password at each request after successfully generating the password". How do I do this?

Thanks,

Greg

[Former Member · Accepted solution]

Hi,

You don't do this yourself. The system does it for you -> regenerate the password when requesting the FF ID.

It changes the password in SU01 using the BAPI and on-the-fly inserts it temporarily into the SM59 stub-connection. It then calls the SYSTEM_REMOTE_LOGIN function via that destination to perform the user switch, and then deletes the logon data from the connection again.

All you need to do is enter a comment, and click "Ok".

Cheers,

Julius