The other day I was in a meeting with a supplier. We were discussing responsibilities of joint systems among other things.
It turned out that we both thought the other side held the usernames and passwords to the technical SAP clients. And much to my surprise, what was thought of as a problem, was not that noone were responsible, but that noone knew how to gain access to the clients without restarting the systems, which was problematic, as the manufacturing systems needs to be running 24/7.
Well, technically, noone in that room knew, besides me. Because I have in the past used a small oracle script to gain access to clients where the passwords to users had been lost.
The cause of the problem is that the SAP function of the no_automatic_user_sapstar parameter requires that we activate that parameter, in order to be able to login with the default user. and that means restarting the system. And once access was gained, another restart would be required to set the parameter back. This functionality is onnly meant to be used for creating a new client, so ofcourse it is not very conveniently built.
So to circumvent the issue of the restarts, I shared with our supplier, this little Oracle script they could run to gain access into client 001, without restarting the SAP system. We have Admin access to the Oracle, so ofcourse we can simply manipulate the data in the database:
rem This part will reset the lock incase you accidentally locked the user trying to get in
UPDATE sapsr3.usr02
SET uflag = 0
WHERE mandt='001' AND bname='SAP*';
rem This part will take the password from client 000s sapstar user and give it to the same user in 001
UPDATE sapsr3.usr02
SET bcode = ( SELECT bcode FROM sapsr3.usr02 WHERE bname ='SAP*' AND MANDT='000' )
WHERE mandt='001' AND bname='SAP*';
COMMIT
;
Now the only real downside to this approach is that we have now only changed the data on the database. Not in active memory. Well, depending on the release version of SAP and whatever parameters you have set, it may be loaded into memory when you access it.
I would recommend trying to logon with the client 000 password, if you have tried this and you fail, likely it is because the data hasn't migrated into memory yet. We can fix that by simply calling the transaction /$sync as any user and in any client you have access to.
But try to run this transaction at low usage periods. It can kill a lot of cache.
Enjoy carefree access to your technical clients.
