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: 

Is SU24 only for removing security checks?

0 Kudos

We have R3 4.7 - I have been doing security for a number of years but just recently went to the ADM950 class, there the teacher said you could change the check indicators to do MORE checking than what the SAP delivered standard provides and those checks will be done in SAP programs. Sounded pretty far out to me but if it can do this please tell me how to change a check indicator from check to check-maintain. Thanks Alot.

Jim Wells

1 ACCEPTED SOLUTION

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

No, you cannot add another authorization check simply by adding some entries in SU24. The checks still need to be coded (=> AUTHORITY-CHECK statement), with SU24 you can only take influence on existing checks (or: check points):

(1) you can specify proposed authorization values for individual authorization objects (listed for a given transaction); this information will be used by the profile generator if the checkbox "Authorization Proposal" is set to "yes"

(2) you can specify that certain AUTHORITY-CHECK statements should be ignored in a given transaction context (e.g. you might want to suppress the checks on FI authorization objects for a MM transaction; otherwise you'd have to assign FI authorizations to MM users which would potentially enable them to perform FI transactions as well)

SAP delivers a set of "authorization proposals" and "case-specific suppression of authorization checks" (see transaction SU22) which can be modified by the customer (using transaction SU24).

Regards, Wolfgang

19 REPLIES 19

Former Member
0 Kudos

Jim,

you can change the check indicators by goung to transaction SU24 , select 'maintain Check indicators for transaction code and put the transaction you wanted to modify and execute. on the next screen click on check indicator. on the popup box for workbech request, create a request and it will take you to the change check indicators for 'xxxx' screen.

On this screen you will see all the authorization objects currently checkd and their status. You can change the status by clicking under the status for the object to change the place of the check mark and save. You can add additional authorization objects if you want to check using insert auth obj tab. If you add the object here when you add the transaction in a role in PFCG the new authorization objects will appear in the role maintenace screen.

Regards,

TK

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

No, you cannot add another authorization check simply by adding some entries in SU24. The checks still need to be coded (=> AUTHORITY-CHECK statement), with SU24 you can only take influence on existing checks (or: check points):

(1) you can specify proposed authorization values for individual authorization objects (listed for a given transaction); this information will be used by the profile generator if the checkbox "Authorization Proposal" is set to "yes"

(2) you can specify that certain AUTHORITY-CHECK statements should be ignored in a given transaction context (e.g. you might want to suppress the checks on FI authorization objects for a MM transaction; otherwise you'd have to assign FI authorizations to MM users which would potentially enable them to perform FI transactions as well)

SAP delivers a set of "authorization proposals" and "case-specific suppression of authorization checks" (see transaction SU22) which can be modified by the customer (using transaction SU24).

Regards, Wolfgang

0 Kudos

So then you are saying if I change a "Check" for authorization M_BEST_EKO to "Check Maintain" basically nothing will happen? Thanks Jim Wells

0 Kudos

Changing the setting from "Check" to "Check Maintain" will trigger the Profile Generator to include the proposed authorization values (for the authorization object M_BEST_EKO) when generating profiles for a given role which has been assigned to the transaction for which you've changed the SU24 settings.

0 Kudos

CM = Check performed AND object added in PFCG when tcode added to the role.

C = Check performed BUT object not added in PFCG when tcode added to the role.

N = No check OR check will return sy-subrc = 0 even if the user does not have the authorization.

U = Unknown. A check will may be hardcoded in the program, or maybe not.

0 Kudos

CM = Authorization checks are performed (if coded in the program) AND the authorization object is added in PFCG when the tcode is added to the role menu.

C = Authorization checks are performed (if coded in the program) but the authorization object is NOT added in PFCG when the tcode is added to the role menu.

N = Authorization checks (if coded in the program) will return sy-subrc = 0 even if the user does not have the authorization.

U = In customer systems: same as "C"

0 Kudos

The best reason for setting up your own su24 (see steps in su25) is that it encourages customers to do a code review of the SAP transaction and understand how it works, what it realy checks and what it does with sy-subrc if it is <> 0... You can then remove some of SAP's generocity and you only need to do it once, as opposed to every time you (or su24 on your behalf...) add the transaction to a role.

0 Kudos

Hi All,

After reading all your replies, it is clear that just by changing the status to CM / NC in SU24 will not activate / deactivate the authorization check in the program. The Authorization-check function should also be written in the program for the same.

Even I faced same kind of situation where I changed the status of an object from NC to CM, but I had to explicilty add the authorization-check function in that program for actual restriction.

Here my question is "Why then CM and C status are required at all in SU24." It should be just used for Maintain/Not Maintain of authorization object during profile generation. Because actual restriction happens only when code is written in the program.

Please clear my doubts. Thanks in advance.

Regards,

Mohit

0 Kudos

Hi Mohit,

The AUTHORITY CHECK statement in any ABAP program is to validate the authorization of an user to execute the problem. However, these authorization objects needs to be CM values, since the authorization check is mandatory. If you made them as NC, there will not be authorization check done.

Hope this clarifies.

Rgds,

Raghu

0 Kudos

Hi Raghu,

Sorry, but I am still confused.

Then why we have to add authorization-check function explicitly if we want to add restriction on object which is in NC status earlier. Authorization check should get activated once status is changed to CM.

Regards,

Mohit

0 Kudos

Not exactly correct.

The authority-check is still performed, but for those special cases where a "No check" is set, the system will context specifically set the return code to 0 regardless of the users authorizations.

In customer type systems the indicator "Check" is of little meaning other than documentation of the transaction's capabilities.

"Check & maintain" (now known as proposal) is an indicator of the transaction's recurring intention or authorizations without which it makes no sense.

Cheers,

Julius

0 Kudos

Hi Julius,

I fully agree with you in case of "Do Not Check" indicator is set for an object.

Can you please confirm my following comment,

"Just by changing the status from "Do Not Check" to "Check" in SU24 will not activate the authorization check in the program. The Authorization-check function should also be written in the program for the same."

Please correct me if I am wrong.

Thanks,

Mohit

0 Kudos

Correct - though a "No check" makes little sense if the check wasn't in the code in the first place...

Cheers,

Julius

0 Kudos

Thanks Julius

Regards,

Mohit

Former Member
0 Kudos

I guess it will help you, if you see some scenarios..

every transaction holds check-maintain for some objects and some with check and some with u or n .

the objects which hold CM are the only objects dragged other than S_TCODE.

and at many situations you will be reviewing a security ticket saying 'you are not authorized' at some part of the transaction. then immideately you will check the role and you see that that object which is causing the problem doesn't exist in the role and you try to manually add that object.

so in this scenario instead of adding it manually if you make that object as CM (obviously should be in the code)

that resolves the issue and will be dragged from next time whenver you create role.

and in some situations an object which belongs to a module which you din't implemented at your corp gets inluded. then instead tring to inactive it just change its status in SU24. it will help further.

like this depending on the scenario you will find why peoplecall SU24 as core of security.

nandan

0 Kudos

The question I have been wondering about is, "Why is there an option 'Check' at all?" It seems if an authorization is checked, then it should also be maintained. However, we have created roles for individual transactions and tested them. They work even though the objects called "check" are not in them. So maybe there is same portion of the code that checks the object which is not exercised by the test. If that is the case, how are we to know? The next person to use the transaction may go to a different place and get an error? Does anyone know that the rationale is/was for setting objects a Check only? Thanks

0 Kudos

Check-Maintain: Theses authorizations are checked in the main part of the transaction. Therefore, if you give somebody access to a transaction, he or she requires these authorizations to be able to do anything.

Check: There are several reasons for setting the check option, however, the main reason is navigation: Theses authorizations are checked in some minor parts of the transaction, e.g. only if you navigate to special functions for which you could call another transaction, too. Therefore, if you give somebody access to a transaction, he or she does not require these authorizations to be able to do the main part of the transaction. And if you give him or her access to the other transaction mentioned above, he or she gets the neccessary authorizations from this transaction.

Kind regards

Frank

0 Kudos

It also means that you can create a common role for all users and pull in common authorizations into it and / or decrease the size of the user buffer by not pulling in authorizations which are already there from a core transaction belonging to the role.

When SAP loads the authorizations, it does not look for duplicates, but rather loads everything.

You can contain this using SU24 check indicator -> C.

Former Member
0 Kudos

Hi,

The check indicators in the SU24 actually give the inputs necessary for the SAP system to interpret the AUTHORITY-CHECK.

Check-Maintain: This means that the Auth Obj will be checked, thia implies if in ur activity u need to come to a situation where you need to rely on this Auth Obj then ur access is dependent on the Authorizations in ur user buffer and also whenever you add the TCODE in the menu of a role this object is brougt in directly.

Check: Check only tells the System to check for its value but will not propose this Auth Obj when TCODE is added to a Role menu. It means same as Check Maintain except the fact that the Obj is not brought in with the TCODE where it is in check mode.

Donot Check:

So if you come to an Auth Obj in a TCODE where it is Not Check NC then here it bypasses the Authority check for the values and allows you too proceed.

But as somebody rightly pointed out that even if an auth obj is made as check n maintain in a tcode this will be of not much use until its hard coded in the program with AUTHORITY CHECK with the field values mentioned.Unless there is authority check how stringent restriction u put in the role will have no significance.

Hope this helps.