SU24 related OSS notes with SAP Support
Last change 02/02/2016.
Note for the readers: I am updating the list of SU24 related OSS notes at the end of this blog. If you know about notes relevant to the subject, please let me know/ comment on the article.
I have opened several OSS notes with SAP Support about missing SU24 proposals recently. I would like to share my experience. It is overall positive, so this blog should server multiple purposes:
- it should appreciate the SAP Global support ladies and gentlemen`s effort,
- it should inform the SAP Community members about what I am doing, why and how,
- it should inform the Community members about the notes and improvements that already exist or are being created in this field ,
- it should also motivate other Community members to push their SU24 entries we miss in the standard at the moment into standard SU22 data,
- …and last but not least the blog should serve as a positive example for future messages I am going to open with SAP support so I don`t have to explain the whole story again. It will hopefully also give enough clues to any Community member who opens SU24 proposals related message to justify the request.
Side-note: the purpose of SU24 and SU22 data:
I am building menu based roles in PFCG. I create a role and first create a menu structure and populate this menu with transactions (and other possible menu objects) I want to authorize the user for. Then when you go to authorization tab and click on “Expert Mode for Profile Generation”, SU24 proposals are pulled from SU24.
Example: I put PFCG into the role menu…
…and authorizations tab of the role gets populated for me:
That works because there are authorization proposals for transaction PFCG maintained in SU24 (where they loaded/ copied from SU22 data delivered by SAP). Go to transaction SU24 and put transaction PFCG. You will get a similar picture to the following.
Side-note: when you install a new system. SU24 transaction is empty (the table USOBT_C behind the transaction is empty). You first need to copy SU22 data delivered by SAP to the customer data and that is then maintained in SU24. This thing you do in transaction SU25. Do it only once! Do it after the system installation. Do not do it again! Otherwise you delete everything you`ve ever maintained in SU24 customer data and replace it with SAP standard proposals. If you want to disable step 1 completely so you AND NOBODY else can start that step (via the button which is too obvious, you can still do it via the menu, but then there is an extra warning), you can apply OSS note 1691993.
You must also be careful with the upload function in SU24. If you pick the wrong upload option… BOOM! But that is another story (per default there is a button called “Replace Instead of Insert/ Modify” checked. If your selection in the upload is the *, then it drops all the content for every object that fits into the selection. BOOM! For star it drops everything).
Motivation behind reporting missing proposals to SAP
So now we should all be on the same code-page, right? (Security ninjas and old wolves forgive, we need to be all on the same code-page here and pointing to the documentations does not always work).
So you can now answer some easy questions for me, right?
- Q: What differs from the description above if the proposal is not in SU24? A: the authorization does not go into the role automatically. But you can still go to the role and put it there manually. [time estimate: 1 minute]
- Q: What happens if you have a dozen roles, all have a transaction in the menu and this transaction has incomplete proposals? A: You have to put the value into dozen roles` authorizations manually one by one OR you can put the value into SU24 and select “Read old status and merge with new data” (third option in Expert mode dialog). [time estimate: 5-10 minutes]
- Q: What happens if you have a million customers, every customer has 5 systems and in every system there are 5 roles with this transaction in the role menu? A: You have to do the above in 5 million systems (ten minutes each).
That`s for the motivation.
Warning! Not everything that glitters belongs to SU24!
I said this should be a positive case that should motivate the Community members to report the missing proposals (Ideally with the values that should be maintained so the criticism is constructive. Being constructive is a very important point!). To make the whole thing easier for you and the SAP support I must warn you that not everything you see in the trace belongs to SU24.
I will make it short here just to give you the idea: (sorry for black & white simplification here, but it`s faster and shorter this way). Some AUTHORITY CHECKs always happen. You cannot perform the activity you want without having that authorization (example: S_PROGRAM to start a program: you need to be authorized for the authorization group the program belongs to and authorized for the necessary activity, like SUBMIT). In that case it is this one exact authorization. It`s something like “always true” or “always there”. Without it the program cannot be started.
Some authority checks differ in different situations. You want to create a business partner. The authorization is different from the one when you want to delete an existing business partner. Let`s say the transaction you`re using for it (I believe there are multiple options) is capable of doing both. Then you don`t put all available options into SU24 (and then either leave the list which is effectively same as * = all access OR change it in the role = then the authorization has status “Changed” = ugly!! Don`t try at home kids). You need to authorize different roles for different activities in the transaction, so you defer the decision about the activity to the role. Maintaining SU24 for activity makes sense for reporting programs for example. The report is functionally capable of reading and displaying data (ACTVT = 03) and that cannot change, the report is not CAPABLE of doing anything else. Then you can put the value into SU24.
Conclusion: SAP must quality check the proposals before putting them in despite the reporters conscience is clear and OSS message is opened with good intentions. Same applies on me. If you ever catch me reporting a missing proposal which is debatable and I cannot justify it, reject me!
Same applies for the reports: be disciplined, report always true (when you find it missing) or report debatable (typically too excessive proposals which are “checked” at runtime, but not needed by the tool to functionally work).
Example: you can often see checks that functionally don`t change anything in the transaction. The user does not have to be authorized for the object and value combination to be able to use the tool. For example S_DOKU_AUT check in SU21. Same case for S_CTS_ADMI and other well-known folks.
How to check what I am reporting
I am often asked how to check what I am reporting in the system. Here come the clues:
When I report something as missing, it means that the combination does not exist in SU24 (SU22 in SAP system data). Go to SU24, provide the transaction name and check the proposals. Let me reuse the SU24 screenshot from above here to explain that the fact that you can see the object in the list does not mean everything is ok. You need to see “YES” value in the “Proposal” column and when you double-click the line, you should see proposals (those that will be pulled into PFCG). See screenshot below: proposed values for object PLOG in PFCG proposals.
Summary for SAP (Frequently asked, answered once and for all)
- SAP: Why do you report this as a product error? Answer: (example only!) I have recently reported several missing S_PROGRAM checks. I recommend you read a documentation on every object you`re reported about. Briefly: S_PROGRAM check happens when one starts a report and checks if the user is authorized to work with programs belonging to an authorization group and which operations is he/she allowed to perform. When I report something, I report SAP standard report, SAP standard S_PROGRAM object, SAP standard (missing) SU22 data and SAP standard authorization group the program belongs to. Everything is standard and it is always like this. In every system. It is “always true”. So the link between the “components” is standard, but it`s data representation is missing. Hence it is a “product error”. Please don`t be mistaken, this is not a development request in any way! In fact it is developer`s duty to provide the values for SU24 and the fact a value is missing means that a developer didn`t do the job.
- SAP: What problem you are facing, if the field is empty? Answer: The transaction does not work until I maintain the value in SU24 (and then pull it into a role) or don`t give the value manually in the role in PFCG.
- SAP: What benefits you will have, if we change the proposal as per your suggestion? Answer: It`s very small benefit for me. I know what to do, where to do it and how to do it. That`s my job. The real benefit is for all the customers. See the three easy questions at the beginning. Can you see the benefit there? Plus customers who don`t actively maintain their SU24 will benefit from it too.
- SAP: It would be very nice if you can provide us a scenario, where you are facing this problem, so that we can reproduce it and check the issue in detail. Answer: turn on the ST01 trace for you user (or without the filter). Make sure the first checkbox “Authorization check” is set to true and preferable select “All” from the radio group below. If you have a user which is NOT authorized for what I am reporting, start the transaction (for which the proposals are incomplete) and wait for the “You`re not authorized” (message texts can differ of course) error to come. If you have a use which IS authorized (like SAP_ALL), check the trace that the authority check happened as reported and values were checked as reported.
- SAP: Why don`t you open the connection to your system? Answer: The same problem exists all around the world and the root cause of the issue is a record missing in your system. That is nothing specific to my system. If you want to prove me wrong, please send a screenshot showing that such a record exists in your system. Then it means my SU22/24 proposals are not up to date. Then I will thank you, apologize for the time waste and wish you a nice day.
Funny tricks and misunderstandings
Saying that complaining about SU24 data makes no sense, since SU24 data are customer data and SAP has nothing to do with it is not an “answer” to my request. My SU24 data are based on SU22 data delivered by SAP, it is up to date (SU25 upgrade steps) and if I want to remove something, I am not reporting it to be missing afterwards.
Generally it is better to add to SU24 than to remove from it. That also reminds us again about self-discipline of the reporters and quality check need before SAP maintains the values in SU22 data.
Please also don`t try funny tricks like customer could maybe even want to put the reports (for S_PROGRAM for example) in their own groups. Then we – SAP – cannot maintain the S_PROGRAM otherwise customer cannot do this anymore (or customer is limited in doing it or anything similar). THAT IS NOT TRUE!! I want you to maintain standard value for standard transaction which needs that value in SU24 to work in the default configuration. If customer wants it differently, ok, fine. The customer must be ready for overhead in maintenance and must know what to change and where to make it work in the new configuration. But that DOES NOT MEAN YOU DON`T MAKE IT WORK IN THE STANDARD CONFIGURATION. Data from SU22 you COPY to SU24 (post installation and during upgrades). If a customer wants to try something special here, he will not accept SAP proposal during the upgrade.
Generally this idea sound like because there could be a customer that wants it A way, we cannot maintain it in the B way for all the others (to make it work for them by default) so we don`t close the door for A. This is not how it works. Thank you.
Last but not least: When you check the proposals in the system, please don`t try to convince me that if the “Proposal” (!!!) column says “NO”, it means that the check is not performed. That is defined in the column one the left. As mentioned above: if the “Proposal” is set to “NO”, nothing is pulled into the role because no values are maintained here that could be pulled in.
Be nice although you feel the person on the other side does not understand you. Be nice regardless of a training difference. First level support must be able to juggle zillions of different topics (I believe) and SU24 could be like 0,00001% of their daily business. So they don`t have to be on the same code page from the beginning. When you`re nice, SAP support people are also very nice.
I`ve been pointed to two existing OSS notes about the topic: missing SU24 proposals. As an example I can mention them here: (my proposals are supposed to be integrated into these notes).
Note 1496056 – Revised authorization objects for transactions
Note 1730692 – Workflow Reporttransaktion Berechtigungsvorschlag S_PROGRAM
Note 1050458 – Missing authorization default values (added 26.6.2012)
Note 1733734 – Berechtigungsvorschlagswerte für Auswertungen (component: EHS/ Abfallmanagement) (added 24.7.2012)
Note 1050458 – Missing authorization default values (added 13.08.2012)
Important to read: the FAQ OSS notes about SU24 related problems/ questions: (added 28.6.2012, credits: Dieter Goedel)
Note 1539556 – FAQ | Administration of authorization default values
Note 727536 – FAQ | Using customer-specific organizational levels in PFCG
Note 1434284 – FAQ | Authorization concept for generic table access
Also check notes: (about S_PROGRAM) (added 28.6.2012)
Note 338177 – Authorization check when executing programs
Note 7642 – Authorization protection of ABAP/4 programs
Authorizations upgrade/ SU25 (added 4.11.2013)
440231 – FAQ|SU25 – Upgrade postprocessing for profile generator
In case you use SE97 (TCDCOUPLES), please also check notes:
1870622 – SE97|Optimizing maintenance environment
1901606 – SE97|Navigation error in dialog
1680501 – SMT1 SMT2 : No authorization for object S_ADMI_FCD (added 01.04.2014, Gretchen Lindquist)
2274754 – SU22, SU24: Berechtigungsvorschlagswerte inkorrekt für Transaktion EEDMIDE_GRID03 (added 02.02.2016) – I assume the note only exists in German so far (fresh out of oven), so please excuse the title
Tips for the reporters
Open the OSS note in the component the transaction you`re reporting belongs to. Every component (or organizational block similar to the component) has its own team. SU24 proposals are not maintained centrally.
Be nice. They are also nice.
IMPORTANT!! Things take time. Even if get a correction note, you`ve not won yet. Well, you could get proposals (and proposals reported by others too) immediately into your system. But consider you will be upgrading the system sooner or later. If you upload a text file (SU24 upload feature imports text files with special format) into your SU24, it is a change in customer data. With the next upgrade you will get the same data into your SU22 and you will have to click through it again (I assume you perform SU25 and authorization/ roles upgrades carefully and think about what you`re clicking away).
It's a bit like the SCN community, isn't it ?
It may be several years before I benefit from improvements to the SU24 proposals (because it may be that long before my systems get upgraded), but someone will get the benefit of my suggested changes well before that.
Hi Martin, thanks for the comment. That`s exactly what it is - no matter who contributes, everybody will benefit in the long run. There are too many missing proposals, too extensive proposals or even wrong proposals, that SAP cannot fix it themselves even if they hire a whole bunch of Security Experts that start running around fixing the proposals. So we need to crowdsource that for the benefit of all 🙂
Great blog, Otto!
That's exactly the spirit - help us make SU24 better by contributing. We've all been there and made changes without telling anyone, and eventually the next guy will have to go through the same issue. If we take the two minutes to report the finding this may help a lot of people.
it's a good idea to collect the knowlegde also here. I'll have a look to your blog from time to time. Additionaly it would great if you could also check and refer to my FAQ-notes 1539556, 727536 and 1434284. Would be great if we could provide nearly the same latest information for that topic.
By the way, one special tipp for good SU24 defaults for the table authorization concept, is to use the report SU2X_UPDATE_S_TABU_NAM (like note 1500054). Here you have a mass function to maintain the table authorization related defaults.
(or should I say Mr. Legendary? I have heard very nice stories about you!!).
I am very happy that you like the idea. As Frank said it`s just few minutes for a man, but a huge jump forward for the humanity (assuming that the customer would have to trace each value himself multiplied by the number of customers 😛 ).
I will add your notes add the report to the blog too. Very useful. I know about it, but I haven`t seen any customer really considering moving from S_TABU_DIS to NAM (although I try to help them started by maintaining the first few S_TABU_NAMs in the system.
Let`s see how far I can get with my OSS notes. I am hoping for some comments like "I have just reported the missing SU24 I needed and the values to the Support" so I don`t feel alone here, let`s see if other people join us 🙂 .
Anyway thanks for your valuable work and the comment and I am looking forward to a day when I can shake your hand maybe.
Have a nice day,
Another cool feature and trick in SU24 you can use with S_TABU_NAM is to maintain S_TABU_DIS with '03' and '02' activities for the group and S_TABU_NAM with '03' only for the table name.
This way you can close all fields and in the role you can decide to have display only access by simply setting S_TABU_DIS to inactive for that group when it is first merged into the role.
No more "changed" authorizations when you want to have the table view access as display only... 😉
But that only works if you know the rule. If one starts doing so and then leaves the company or the project, others will happily surf on _DIS 02, isn`t it so 😀 So it can be even dangerous 😏
I was told that they have special tricks like this in different modules. In one of the modules where I reported the missing SU24 I was told I am supposed to put one of their "main reports/ transactions" and that will "pull enough so I don`t complain". Is that a best practise? Cutting edge idea by SAP or just an invention by few?
Yes, of course it should not get so "clever" that a mortal cannot keep to the rules any more.
It would make sense anyway to have a naming convention for roles which can identify those which permit display only for tables, then run SUIM reports (there are a few of them) against the roles to see if any have been "fat thumbed". That risk is always there.
It's aweasome 🙂
Thanks 😆 What`s the best part? Otto
As you know I raised a message with SAP some time ago regarding SAP supplied default values for some standard transactions, proposing S_TABU_DIS, with &NC& for the DICBERCLS field. Frank picked this message up initially, and then passed it to Dieter, who replied this morning:
So it looks as though we have a positive update to come. Thanks to you for starting the topic rolling, and thanks also to Frank and Dieter for their work looking into this 🙂
thanks for the update. also thanks Dieter Goedel for help, updates, support and everything. last time i checked my su24 and there were not that many &NC&, so we have a smart and measurable target that can be accomplished in some months. i suggest we look for other problems and/or areas that can be clearly defined and progress measured:-) if we manage ro find internal friends/ partners, it can be a real fun too:-)
when you opened the message, will, did you send them the values that we suggest to maintain there? that should make the task easier and solution faster for them.
anyway thanks for being with us, we can change something here for everybody.
see you soon, otto
No I did not send SAP any suggested values to maintain instead of the &NC& - in my case none of the affected transactions are in use at my current client, and so there was no direct impact on us, and I was unable to spend much time on it.
However, I did run the excellent little program that you sent me in order to determine which table each transaction reads or writes to, so I do have some useful suggestions.
I know Deiter and Frank will read this, so guys if you are interested, let me know and I will send you what I have.
wow, good read and great idea. working on an upgrade project so it all makes perfect sense now. 🙂
if you are currently in an upgrade project take notice from my note 440231 BEFORE runing SU25 or better before the technical upgrade start. (Sorry Juluis and Otto I forgot to post it here).
It's really important to have the latest note corrections in your system, before the PFCG upgrade.
Sorry I'm currently working on some other topics. As far as I can I'll search for an solution regarding the Table group assignments vs. SAP authorization defaults.
Dieter (SAP AG).
PS.: May be the notes 1870622+ 1901606 should be checked if the SE97 (TCDCOUPLES) is used by the customer.
thank you for thinking about us and the community, much appreciated!
I am updating the blog accordingly for those who don't read the discussions 🙂
You may want to add this Correction to the list; it was the result of one of my own SU24 incident reports.
1680501 - SMT1 SMT2 : No authorization for object S_ADMI_FCD