Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Mutiple logon in PRD from same ID from Different Machines

former_member319296
Participant
0 Kudos

Here is your organization we are using same user ID ( during go live phase) for uploading master data etc from different machines.

My question is

1. Are we violating the license agreement as when we logon in PRD system we gets the following message.

"multiple logins to the production system using the same user ID are not part of the SAP licence agreement."

2. We so can we restrict the one user ID to allow login using same machine ?

Please advice as i found few threads in SDN discussing the same issue ,which says it should be blocked.

Please advice.

regards

1 ACCEPTED SOLUTION

Former Member
0 Kudos

1. The message is valid...answer is yes unless you have a specific dispensation in your licence agreement.

2. You should restrict the users to a single dialog logon. That means that only one ID can log in regardless of what the machine is.

2 REPLIES 2

Former Member
0 Kudos

1. The message is valid...answer is yes unless you have a specific dispensation in your licence agreement.

2. You should restrict the users to a single dialog logon. That means that only one ID can log in regardless of what the machine is.

Former Member
0 Kudos

Apart from the licensing issue you might want to know who did what in the migration and would not want them all changing PID and variants etc at the same time.

IMO migrations can be considered a "service" or "system" event so you could consider changing the user type, but if you have may folks performing migrations at the same time and doing other work with the IDs then obviously there is a problem.

For performance reasons you should consider transfering the migration into the background and only use the SAPGUI to administrate and monitor it by Dialog (human) users.

Please also consider the security aspects of migration programs AFTER the migration. All too often, these programs are very generic and are left lying around in the system without sufficiently protection from being subsequently executed from the frontend(s).

Adding a password to the selection screen at least forces the user to look into the code.

Adding a sy-datum restriction is even better.

In your scenario, adding a sy-uname check would be futile....

I typically add an authority-check agaist S_ADMI_FCD action RSET (reset data) and implement a blacklist allergy against it in the building of roles.

Cheers,

Julius