SU24 – Maintain Check Indicators
The SU24 transaction is one of the most important transactions in security. Its used to maintain all the objects that are checked for the execution of a particular transaction. The check indicators as maintained in SU24 are stored in two customer specific tables USOBT_C and USOBX_C. The customer specific tables ensure that the values modified by a customer are not over-written by the SAP proposed values during a future upgrade. We can have a look at the SAP proposed values through the transaction SU22.
Each object can have three different status as given in the screenshot below
- Do not check – These objects are not checked during transaction execution. Authorization objects belong to Basis and HR components can not be marked as Do not checked.
- Check , Yes (Check/Maintain in previous releases) – These objects are checked during transaction execution and also pulled into a role when the transaction is added to a role. We also have an option of maintaining default values of the authorization fields for these objects. For example, in the last post regarding role maintenance, we saw a number of authorizations which were pulled into the role with default values. These authorizations appear with status standard or maintained in role maintenance.
- Check, No (Check in previous releases) – These objects are checked during transaction execution but are not pulled into the role even if the transaction is added to the menu.
Its important to note that the primary check for an authorization object during program execution happens at the code level. So adding a check in Su24 will have no impact to security unless the code is modified as well to include a check for the authorization object. We talk about the mechanism of the authorization check at program level in our next article.
In the last two section, we have looked at both SU22 (SAP delivered check indicators) and SU24 (customer maintenance of check indicators). We have also talked about how SU22 presents data from USOBT and USOBX tables, SU24 present data from the customer tables USOBT_C and USOBX_C tables. The natural question that arises, “if SAP only writes to former set of tables and we only modify the customer tables, how are the customer tables initially filled with data?” Actually, SAP provides a standard transaction SU25 for initially copying over SAP proposed values to the customer tables. We discuss this transaction in our next section.
Stumbled upon the site accidentally but stayed on this site for more than 3 hours.
Amazing work. Amazing information….thanks a lot….
Thanks!
thanks Aninda,i tried in many sites but i did get what i need.
you are doing good work….thanking you.
really great work:):)
Thanks:-)
Hi Aninda,
Got to know about this site through my colleague. Really amazing and nicely done. Very easy to understand and those screenshots are really helpful. Thank you for keeping such a wonderful information.
Regards,
R.K
Hi Aninda,
Need clarification in the above article.
can u explain these statement in brief
So adding a check in Su24 will have no impact to security unless the code is modified as well to include a check for the authorization object.
I will try to explain with an example. Suppose, you create your own ABAP report ZREPORT_TEST to display FI data and create a tcode ZREP to call the program. You get a requirement that only people with activity of 03 (display) for the authorization object F_BKPF_BUK can run the report for the company code values maintained in the role. To achieve this it won’t be enough to add F_BKPF_BUK in the SU24 entry for ZREP. You would also need to add an authority-check statement in the code to actually check for the object. Hope this makes sense!
This looks to be a perfect example and gives an indept understanding of custom tcode and su24 relation
Very good explaination for the query…
SU24 – check Indicators:
U – Unmaintained
N – No check
C – Check
CM – Check/Maintain
Hi Aninda,
Very nice material, really good work…keep it up… 🙂
I have one question :
How SAP system treats check indicator “C” maintained in SU24 while working with actual functionality through transaction(Example : SU01 here)?
Supportive conditions:
(C : Will not be available in PFCG for maintenance)
(CM : Will be available in PFCG for maintenance)
(Authority Checks are coded in program as per SAP standard (We will consider standard transaction SU01 for this discussion))
Scenario :
User : ZUSER
Role Assigned to user
with values inside : Z_ABC
TCODE : SU01
Objects : S_USER*
Transaction : SU01 has many objects linked with “CM” (Example : S_USER*) and many with “C” (Example : S_DEVELOP)
So could you please explain when exactly system checks S_DEVELOP for user ZUSER when this user will be working with SU01? and if it does somewhere and it passes the user with functionality (without stoping user to go ahead)with even failure as user does not have S_DEVELOP, what is the difference in maintaining them with “check” or “No check” in SU24 (Is it not more convenient to simply having objects which are with “CM”/maintainable in pfcg in SU24)?
BR,
Mangesh
Hi Mangesh,
A few things to keep in mind for all SAP default check entries as seen in Su24.
The check entry defaults are certainly not set in stone. SAP can and often does make mistakes in their default values which users are suppossed to catch and modify according to their needs.
The check indicators are meant for ease of maintenance when adding the tcodes to the roles. Unless a underlying check for the corresponding authorization object is present in the ABAP code for the tcode, no amount of fiddling with the check indicators is going to help. The only exception to the above rul is to mark an object as do not check. An object marked as do not check will not be needed by the user even if there is an “authority-check” for it in the program.
Finally the difference between check (C) and check/maintain (C/M). SAP sets an object as C/M if these objects are checked in the code and hence needed by the user while executing the basic functionality of the tcode, for example the S_USER* objects present for SU01. The objects marked as checked (C) are ones which might be checked while executing some of the more uncommon menu paths for the tcode. For example, SU01 has a check for PLOG. However, this object will only be checked if you are trying to use PFCG for indirect role assignment through Org Management.
Hopefully I have been successful in clearing your doubts. Personally, I consider SU24 to one of the bed rocks on which the subsequent administration of security is based. So its very very important that everyone of us, security consultants have a solid understanding of each of the different settings in it.
Regards,
Aninda
Hi Mangesh,
A few things to keep in mind for all SAP default check entries as seen in Su24.
The check entry defaults are certainly not set in stone. SAP can and often does make mistakes in their default values which users are suppossed to catch and modify according to their needs.
The check indicators are meant for ease of maintenance when adding the tcodes to the roles. Unless a underlying check for the corresponding authorization object is present in the ABAP code for the tcode, no amount of fiddling with the check indicators is going to help. The only exception to the above rul is to mark an object as do not check. An object marked as do not check will not be needed by the user even if there is an “authority-check” for it in the program.
Finally the difference between check (C) and check/maintain (C/M). SAP sets an object as C/M if these objects are checked in the code and hence needed by the user while executing the basic functionality of the tcode, for example the S_USER* objects present for SU01. The objects marked as checked (C) are ones which might be checked while executing some of the more uncommon menu paths for the tcode. For example, SU01 has a check for PLOG. However, this object will only be checked if you are trying to use PFCG for indirect role assignment through Org Management.
Hopefully I have been successful in clearing your doubts. Personally, I consider SU24 to one of the bed rocks on which the subsequent administration of security is based. So its very very important that everyone of us, security consultants have a solid understanding of each of the different settings in it.
Regards,
Aninda
Hi Aninda,
I am new in this field. For gaining knowledge I have been referring your site.
I still need some more explanation for Indicator Check (C).
Hi Surbhi,
This post on SU24 talks a lot about check indicators. Look at the attached screenshots as well. Why not read through and then see if there are still questions on it.
Regards,
Aninda
Hi,
Thank you for the great articles but I have a quick question.
If I understand the check indicator and SU24 concept correctly, it seems that if we decide to check/maintain an authorization object, we also need to include the ‘authority check’ in the code. My question is, what’s the process when we decide to not check/maintain for an existing authorization object? Does someone have to go back to the code and remove the authority check statements? Or does it not matter for deactivation?
Let me know if my phrasing is confusing. I’m still learning securities. Thanks!
Hi JK,
Since we are talking mostly about standard tcodes and standard objects, there is really not an option of removing authority-checks at the code level without a core mod. However, you can selectively switch of the checks for non Basis and HR objects. To switch off the authority checks, you need to set the check indicator value for the object to Do not check.
Regards,
Aninda
Hi Aninda,
I got reference to this website through your facebook page. Its really amazing to see answer to our queries in such a simple language. Thanks for the website.
I had a question when I started reading this post. My question (or in fact doubt) was what happens when we put status of an authorization object as No Check, but in program it is checked through Authority_Check statement. I got the answer while going through the comments 🙂
This post and subsequent comments/replies, also confirmed my understanding about the significance of the “Check” status of the auth objects. 🙂
Hi Nitesh,
When an auth objects is marked as Do not Check in SU24, this will actually over-ride the authority-check statement. The authority-check statement is still executed like any other statement but the sy-subrc value is returned as 0 (zero) even if user deosn’t have the object in the user buffer.
Please note that you can not set HR and Basis objects to Do not check.
Regards,
Aninda
Hi Aninda,
How does the program reference the su24 check indicators while in execution ??? Is there any internal call to reference su24 value after each authority statements or does it reference the tables ??
Regards,
Pranay
Hi Aninda,
I have a question in su24 T-code. For example if a user is having a access of su53 tcode (access of authorization objects like S_DEVLOP, S_USER_GRP, S_USER_AGR & S_USER_AUTus for). So I have changed the check status to NO for authorization object S_DEVLOP. So after changing the status also user is having access of S_DEVLOP.. what could be the reason ?. why user is getting access. what are the steps we need to do after changing the check status for objects.
Thanks& regards
Kp
Hi KP,
Maintaining SU24 and maintaining authorization values in roles are two very different things. Don’t confuse the two together.
Thanks,
Aninda
Hi Aninda,
I am a SAP developer. We have a scenario in which we need to restrict the data for F4 help based on the user who is logging in. We are implementing it using seach help exit.
For transaction MCLH authority object L_LGNUM has status “Do not check”.
It is returning SY-SUBRC for all the warehouse numbers. When i checked SU24, the authorization object L_LGNUM had a status “Do not check”.
What is the reason SAP has this status for some of the authorization objects?
Could you please suggest a solution on how we can restrict the values for the warehouse field.
If the code is checking for a particular object, in most cases security consultants won’t be able to help. See if its feasible to override the check in your exit in any way. Thanks…
what is the maintenance status of auth objects(maintained,not maintained,maintained with warning and donot check)?
could you please explain this
Sorry, I would have to use google for most of these. Do not check means that the security checks are ignored at the code level for these objects.
Dear Aninda,
Nice site!
I have the following question about the USOBX_C table:
If a custom transaction ZNEW is created and the developer includes an authority check on lets say F_BKPF_BUK, what happens if you do not make a new entry in the USOBX_C table with SU24? When the program checks the USOBX_C table and finds nothing, does it check on the built in auth object by default?
If so, that would mean that you could decide to not transport the SU24 changes to production if you never change anything in the check indicators but only add custom transactions with their objects for role building purposes (and role maintenance is only done on development). Correct?
The check indicators in SU24 (USOB tables) are only meant to help with role maintenance. If there is an authority check at the program level, the object would need to be present in the user buffer for a successful execution of the program. The only exception to this rule is when you add an object as do not check in SU24. In such a case, the SU24 entry will override the authority check at code level.
Hi Aninda,
The site is very useful for freshers like me. Appreciate….Thanks a lot… 🙂
Good Information to Learn.
Hi Aninda,
Very useful site its very helpfull to freshers, thank you aninda
Regards
Sashi
Hi Aninda,
I have a small doubt.
Is it possible to use custom tcodes with out maintaining them in su24.
Is it mandatory to maintain custom tcodes in su24?
If YES—-ok
If NO—–where can we see the authorization objects associated with those custom tcodes
” other than se93″
Thnaks in advance
You only should think of updating SU24 for custom tcodes when the underlying program checks for the objects. Otherwise updating Su24 wouldn’t make sense. Thanks.
in what case tcode su24 is used..?
Read the post
hello Aninda
Very useful info. I have 1 question.
Maintaining Authorization Default Values Using Trace Evaluation in Transaction SU22 or SU24
Maintaining Authorization Default Values Using PFCG in Transaction SU22 or SU24
Why it is used & please can you explain me the use of those Trace & Merge mode for PFCG in SU2/SU22 tcodes.