Question:
In most of production systems, I saw ALEREMOTE with SAP_ALL & SAP_NEW. It should be solution of easyness, not to find the good authorizations for this kind of user who should be in Communication status (I saw sometimes in dialog or system) but Audit program always make a concern on this point.
Do you know which are the complete role or profile for this kind of user?
Systems are on 4.6C
Thanks.
Pierre.
Answer:
It is better to use dedicated RFC users which are named such that you can easily identify and control WHERE they can be called from. Where is your ALEREMOTE called from? Are you sure? How old is the password?
Some of which you say also contradicts that which (some) SAP documentation recommends. ABAP which runs via destinations, is running in the name of the user entered in the destination. Anyone who can get to display the destination in the foreign system, can use the authorizations of the user account entered in it with those access rights in your system. For ALEREMOTE it is presumably an external system. For internal it is often a logical type destination. There are also special internal ones for which you can use destination NONE, not only for testing. There is also a security disaster called workflow.
Re auths: Some S_RFC (increase the authority check before you start reducing or tracing it with SM20) and only those authorizations for the applications which they NEED. No Tcodes and no Sdevelop. You should know and have documented what the user is used for, and grant only that.
There is also some config which you can do in Se11 and RZ10 (change the crappy default settings).
Tarr
Answer:
Tarr,
In that case, ALEREMOTE must be used for BW extractions.
Answer:
Mods: Is swearing allowed here?
Answer:
Tarr,
Is it of the humor of your part?
In our case, ALEREMOTE is the user who must be used for the extractions BW.
Sorry, if my english is poor or bad.
Answer:
Hi Narbo,
A little bit of humour, but your R/3 systems are supporting your core business processes, so it is actually sad and not funny and your auditors are right. The BW extraction (as it is propagated by SAP) is not a work of security art either...
Depending on how you are using the extraction, there is a apparently even a special case where the user type needs to be dialog, as a dialog login is required to complete a screen. Typically, the access required is too much anyway for extraction FROM bw.
Switch your user type to System and you may discover this.
Complaining is worthless and valueless if there isn't a risk. Could your auditors explain / test the risk? Understanding the problem is a large part of recognizing the solution, and not just diatribing audit principles - even if they are correct?
Again, use S_RFC to restrict the point of entry and calls within the system. Extend the RFC check (param auth/rfc_authority_check and some other settings - depending on your requirements) so that RFC logins cannot call critical functions outside of the permitted function groups, if SAP standard and your own programs chose to use the check.
Also monitor the access - because once the program is authenticated and running and you are a reference for the server to accept, there are few hurdles and they are not limited to ALEREMOTE's access rights.
Ask your developers, and tell them that it is nothing special to know and negligence to keep for convenience.
Tarr
Answer:
ALEREMOTE is a common CPIC ( or should be CPIC ID) used for ALE ( Application Link Enabeling) and used for HR, BW, FI, Etc. The ALEREMOTE Id should have a specific role for what it does in your situation NOT SAP_ALL and SAP_NEW.
You can build a role from a ST01 authorization trace of the ID and track exactly what it is used for and weed out any potential mis-use. In some cases the ALE function proposed uses call transacton so ST03 and ST03N may be of use in defining the role but ST01 authorization trace will capture all that it encountes. DO note the trace must be done in the target system.