Contents

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.

SU24 - Initial Screen

SU24 - Initial Screen

Each object can have three different status as given in the screenshot below

SU24 - check indicators

SU24 - check indicators

  • 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.

32 comments to SU24 – Maintain Check Indicators

  • Rakesh

    Stumbled upon the site accidentally but stayed on this site for more than 3 hours.

    Amazing work. Amazing information….thanks a lot….

  • Raj

    thanks Aninda,i tried in many sites but i did get what i need.

    you are doing good work….thanking you.

  • gopinath

    really great work:):)

  • Radha Krishna (RK)

    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

  • vasanthi

    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.

    • Aninda

      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!

  • Indu

    Very good explaination for the query…

  • Gabriela

    SU24 – check Indicators:

    U – Unmaintained
    N – No check
    C – Check
    CM – Check/Maintain

  • Mangesh

    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

    • 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

    • 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).

    • Aninda

      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

  • JK

    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!

    • Aninda

      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

  • Nitesh Gupta

    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. :)

    • Aninda

      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

  • Kp

    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

    • Aninda

      Hi KP,

      Maintaining SU24 and maintaining authorization values in roles are two very different things. Don’t confuse the two together.

      Thanks,
      Aninda

  • Mercy

    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.

    • Aninda

      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…

  • rekha

    what is the maintenance status of auth objects(maintained,not maintained,maintained with warning and donot check)?
    could you please explain this

    • Aninda

      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.

  • Loesje

    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?

    • Aninda

      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.

  • HariKrishna

    Hi Aninda,

    The site is very useful for freshers like me. Appreciate….Thanks a lot… :-)

  • Sridhar

    Good Information to Learn.

  • SASHI

    Hi Aninda,

    Very useful site its very helpfull to freshers, thank you aninda

    Regards
    Sashi

  • santosh

    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

    • Aninda

      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.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>