The standard SAP_ALL and SAP_NEW profiles allow you to assign a user full authorizations for all transactions and functions in the SAP system. It is well known that the profiles represent an enormous security risk. Nevertheless, they are often required for scenarios such as the use of emergency users or for technical users. Find out how to use SAP_ALL and SAP_NEW correctly here.
It’s tempting when it feels like it takes forever to set up correct authorizations: Assign SAP_ALL and the user is immediately ready to work. No discussions, no analysis ping-pong, no constant error messages. But it’s only that simple until the next audit. With the standard profiles SAP_ALL and SAP_NEW you assign full authorizations. And that should be the exception – especially in the production system – and not the rule.
SAP_ALL and SAP_NEW – what is the difference?
SAP_ALL contains authorizations for all transactions and objects in the current SAP system.
SAP_NEW is usually assigned together with SAP_ALL. However, it is necessary especially if your system receives an update or upgrade. SAP_NEW guarantees that all users can work with SAP_ALL even if the update or upgrade brings new objects and transactions into the system or changes old default values. In addition, SAP_NEW contains the authorization object S_RFCACL, which authorizes trusted RFC connections and is not included in SAP_ALL.
Important: SAP_ALL and SAP_NEW are profiles, not roles. You can build roles based on both profiles, or you can store the profiles directly in the user master via transaction SU01.
Who is allowed to get SAP_ALL?
This is a sensitive question. Basically, both profiles are intended by SAP for short-term use only – especially when it comes to production systems. With SAP_ALL and SAP_NEW a user, if he knows what he is doing, can paralyze your entire system. Therefore, normal dialog users should never get SAP_ALL or SAP_NEW.
Nevertheless, there are scenarios where SAP_ALL and SAP_NEW are often assigned. For example, for firefighters – users who may only be used in an emergency and whose actions are logged. Technical users are also frequently assigned SAP_ALL and SAP_NEW to prevent important background jobs from running, for example. But especially with technical users, authorizations can be implemented more cleanly!
Authorization errors despite SAP_ALL: What is the reason?
Basically, a user with SAP_ALL and SAP_NEW has quasi full authorization. Nevertheless, it can happen that a user has these profiles and authorization errors still occur, so that he cannot continue working.
User wants to use Trusted RFC connection
If the user tries to access another system via a Trusted RFC connection, he or she needs corresponding specifications in the authorization object S_RFCACL, both in the target system and in the source system. Because this object can lead to major security gaps if used incorrectly, it is not included in the SAP_ALL profile.
If the user only has SAP_ALL and S_RFCACL is not contained in any role assigned to him in the appropriate specification, he cannot access the target system.
By additionally assigning SAP_NEW you can avoid the problem, because S_RFCACL is contained here. But as I said, you are opening up a potential security risk.
Alternatively, you can set the ADD_S_RFCACL switch to “Yes” in the PRGN_CUST table. This table contains values for authorization customizing. The above switch is set to “no” by default. If you set it to “Yes”, S_RFCACL is also contained in SAP_ALL.
SAP_ALL is not (re)generated
For SAP_ALL to work, it must be generated. Normally, this is not your problem as an authorizer, because if you can assign the profile to a user, it is also active in the system (i.e. generated). However, SAP_ALL must be regenerated after each change so that it includes the new system status. So when new transactions or authorization objects come into the system, SAP_ALL must be regenerated to include them.
The generation is done either manually using transaction SU21. In this case, you generate SAP_ALL in each client of each system individually. Or you can use the report AGR_REGENERATE_SAP_ALL, which allows you to generate SAP_ALL for multiple clients at the same time. Another alternative is the switch SAP_ALL_GENERATION in the table PRGN_CUST. With SAP_ALL_GENERATION: ON you tell the system to automatically generate SAP_ALL whenever new objects are imported.
System receives an update/upgrade
Technical users that are used during a system update or upgrade absolutely need SAP_NEW in addition to SAP_ALL. If you forget this and new functions, transactions, programs or objects come into the system that are relevant during the update or upgrade, the user will run into errors. However, SAP recommends that SAP_NEW be revoked as soon as the updates are complete and SAP_ALL is regenerated.
User wants to use Z objects or transactions
SAP_ALL and SAP_NEW are standard profiles of SAP and therefore only include standard functions and transactions by default. Therefore it can happen that users with SAP_ALL and SAP_NEW have no authorizations for customer specific transactions and objects.
Also this error is usually repaired by a generation of SAP_ALL, because the profile includes with the generation always ALL functions, which are available in the system at the moment – thus also Z-transactions and -objects. Alternatively, you can also help here with a switch in the PRGN_CUST table: If you set ADD_ALL_CUST_OBJECTS to “Yes”, all customer-owned objects are automatically included in SAP_ALL. But be careful: this only applies as long as the objects and transactions follow the naming conventions, according to which customer developments start with Z_ or Y_!
Good to know: In newer releases, you no longer have to worry about this authorization error. Here, the customer-specific objects are contained in SAP_ALL by default.
Restrict SAP_ALL: Is that possible?
SAP_ALL and SAP_NEW are a security risk and become a problem during an audit at the latest (by the way, even if you copy the profiles and just give them a different name – auditors are smarter!) But without full authorizations, technical and emergency users will cause errors in case of doubt, which can cost a lot of time and money.
This problem can only be solved cleanly with a comprehensive authorization concept, in which you record, analyze and authorize exactly what is really needed. But this is time-consuming and if something is missing, you sometimes notice only too late.
As a (short-term) compromise solution, you can create a separate role that is based on SAP_ALL, but does not allow particularly critical functions. These include, for example, deleting change documents, system authorizations or change authorization in debug mode. To do this, create a role in the PFCG whose authorizations you draw from SAP_ALL. Then manually restrict the critical authorization objects.
One thought on “Using SAP_ALL and SAP_NEW correctly”