Question:
Hi
Is there any way we can synch our passwords across clients. Our users Login via Portal EP6.0 and manage their password there. At the moment the portal only synchronises with R/3 which means that users logging into BW and EBP via the GUI need to maintain a separate password.
Is there anyway that when the R/3 password is changed via the portal then BW and EBP passwords are changed to match.
Any help gratefully received.
Diane
Answer:
The correct solution is to use a single sign on methodology or a cookie or ticket methodology. It is possible (but not correct) to copy the user master record (table USR02) from one client to another as a password synching mechanism. It isn't trivial as you must be able to synch a password change made in any client back to any other client. That means you have to trap for and test a password change at login and you have to do it in the user exit. If I recall the login user exit is only available for SAPgui logins so RFC logins/password changes may be a challenge.
Do it the SAP way.
Answer:
You will have to use SAP's User Update BAPI, Your own code ( RFC enables Function module) or SAPs function modules to accomplish this. The code has to be written such that it cannot be user outside the program running it and has authorization checks if SY-Uname is not the ID running the request
Answer:
What SAP function module allows a password to be copied from one system to another Professor Jarboe?
Answer:
Don't get your hopes up too high: It's the one with which you would need to know the old password before you can put the new one...
Answer:
What SAP function module allows a password to be copied from one system to another...? Hmmm... Let see
DB_UPDATE_TABLE wrapped in an RFC
RFC_ABAP_INSTALL_AND_RUN ( ease of use depends on the version of SAP)
SUSR_USER_CHANGE_PASSWORD_RFC with login/pw_sync = 1 and TWPURLSVR populated correctly
BAPI_USER_CLONE
And the list goes on...
I reccommend you write your own....
Answer:
What SAP function module allows a password to be copied from one system to another...? Hmmm... Let see
DB_UPDATE_TABLE wrapped in an RFC
RFC_ABAP_INSTALL_AND_RUN ( ease of use depends on the version of SAP)
SUSR_USER_CHANGE_PASSWORD_RFC with login/pw_sync = 1 and TWPURLSVR populated correctly
BAPI_USER_CLONE
And the list goes on...
I reccommend you write your own....
Note to the unwary. These are egregious hacks. Be very careful.
Answer:
What may be "egregious hacks" to one is a technical solution to others, the question was not "SHOULD I?" but "Could I". It is not up to use to pass judgement in our ivory towers secluded from other's eyes as to what one is doing but share the possibilities so one can, based on their company's risk tolleence and bussines need use SAP.
It is the sharing of ideas and possibilities that further this site not "proprietary methodologies" so secret that they may be questionable.
SAP provides functionality and surely they do not see using their code as egregious hacks.
Answer:
Of course you can. You can do many things but should you. I knew a programmer who used kernel calls for password changes in his program. SAP pulled that capability, he was gone and the program was stranded. The client had to rework business processes. It doesn't matter that the programmer brags that he can still access the kernel calls. He isn't serving that client anymore. The programmer should have notified SAP of the "backdoor" to the program so it could be closed not exploited.
Answer:
used kernel calls for password changes in his program. SAP pulled that capability, They did not pull it, they changed it as they are known to do. You can still perform the same functionality, you just have to know how. Your example only shows that SAP is constantly changing and "serving the Client" can only be guarnteed to last until the next release, upgrade or hotpack, a "Feature" in SAP that all License holders realize. If it lasts longer consider it Serendipitous.
If the justification and aproval is granted from the Client then the providing the functionality serves the client. The responsibility of the developer is to reinforce the potential for SAP to change functionality and provide well documented secure code, not tell the customer "wait for SAP to provide it, because they might change something in the futre".
The programmer should have notified SAP of the "backdoor" to the program so it could be closed not exploited. Nice notion but SAP does not care unless a large enough group insists, a single programmer is a cry in the dark and responded to by SAP as "its a Feature". There are many holes STILL in SAP, of which they have been informeed on and yet they are still there...[/quote]
Answer:
SAP does care. They frequently change programs to close backdoors based on a single user complaint. I have had atleast three direct and quick responses from SAP acknowledging and remedying a security deficiency that allowed inappropriate access.
I have also been involved in numerous notes where SAP acknowledged a problem but deferred resolution the next release.
Answer:
Just incase anyone else needs to look it up too, Serendipitous = The faculty of making fortunate discoveries by accident.
Answer:
Chaps
Thanks for the most enlightening debate Not being a true techy I'm not sure if my original question has been answered. I guess the general consensus is that SSO via the portal is not possible but there are get arounds using ABAP.
Now to persuade a developer to give me a ABAP programme to do the job.
Diane
Answer:
did u get any program made?