Question:
Is there a table (or another way) to determine what objects are added to the authorizations when a Tcode is added to the menu in PFCG? Specifically, S_TABU_DIS with a value of “*”.
Table USOBT_C only lists the objects that are set to “C/M” in SU24. But objects listed as “C” are brought into the authorizations too. And I can’t find a table that lists the “C” guys and their values.
We are trying to prevent access to certain tables, but SAP has defaulted so many Tcodes with S_TABU_DIS and activity=03 and “*” to auth grp that it’s a huge project. Especially when there isn’t a useful table.
Any help is appreciated.
Answer:
Only object with C/M are brought into a role if the tcode is added to the menu,, there is a nuance to reeding USOBT_C ( which you should not, you should use SU24 only) as SAP also looks at what type of transaction code it is and will also look at the UNDERLYING tcode and add those objects as well. i.e. Look at F-43 in USOBT_C you may only see one C/M object yet SAP enter up to 8 objects, SU24 will tell you why by looking at the far right of the screen for the underlying tcode...
If you go into PFCG and turn on ALL the technical settings you will get an OVERVIEW Icon next to each Auth Object heading in Authorization adn pressing this icon you will list what tcode brought in the values, If you are getting an '*' with S_TABU_DIS I would check the values for SM30, SM34 and then look at the overview inthe role and ALL data on the screen in SU24.
It Is working as designed...
Answer:
Thanks for your response John. Now I understand.
But this is bad news! (Another example of how frustrating SAP can be.)
I wonder why SAP just didn’t include the required objects - with the correct table authorization group - with each Tcode. Sometimes they do but mostly they don’t.
What I’m going to do is change the S_TABU_DIS = “*” for SM30 and SM31 via SU24 to a range that does not include the tables we don’t want the users to access. Then I’ll still have to change all our existing Roles and update the SU24 objects for each affected Tcode too. Wow!
Thanks for your help – I appreciate it.
Answer:
THe best solution is to make SM30 and SM31 S_TABU_DIS activit 03 and put no value in for the table authorization group or a blank ( represented by a single-quote-space-single-quote) , SM30 is a generic tcode and has no specific auth group and therefore it will signal you there is a problem. You will then need to configure SU24 corectly for each tcode.
Answer:
Thanks for your response John. Now I understand.
But this is bad news! (Another example of how frustrating SAP can be.)
I wonder why SAP just didn’t include the required objects - with the correct table authorization group - with each Tcode. Sometimes they do but mostly they don’t.
If they did then many security admins would be out of a job!
More seriously, in many cases the use of auth objects depends on config and how you are going to use the transactions & processes. It would be a huge task for SAP to change their functionality to reflect this. In the grand scheme of things it's nto something SAP would contemplate looking at for a long, long time (if ever)
Cheers
Al.
Answer:
There are many such things as this that PFCG will do to mess up your authorizations if you do not configure SU24 to meet your needs.
PFCG is just a tool to help you, but you have to know the auth objects well enought to OVERRIDE any suggestion PFCG makes.
For instance there are those transactions that PFCG will use to pull in certain auth objects of modules you may not have even emplemented yet. Do you keep them? Only if you plan to implement it someday. You can turn that off globably. I think Security Administrators are "skaird" to touch SU24 and so they give themselves alot of work.
Look at some of the Spool transactions, If you have not configured PFCG to your own needs, it will pull in Spool Administration objects that you never intended an enduser to have.
So what is the answer. Read. Read. Read. Use SU21 or SU03 and start with the BASIS class objects (BA, BC, BZ) drilldown on each and highlight the objects and choose documentation, Read them over and over until you understand them. This is what a Security Administrator is supposed to do. Then go to SAP Marketplace and search for each object and read every note on each object. Then audit your system and fix all the roles you find that are giving people more Basis access than you ever thought. And even if they are not getting access because the transaction is missing, you know that you are in a risky spot if that is all they are lacking. After you have done this with all the basis authorizations, go to your FI, team and ask them what they are the most concerned about as it relates to their users and SOD. They will be able to tell you from the application and transaction level. Ask them to demo the tasks in the DEV system and record the transactions, and prgrograms that are being used. Learn how to run a transaction, choose system, status, view the program name and start evaluating the authorizations based on the transaction and the authority checks in the programs, Use the authority check program to analyze all the authority checks associated with the program and the sub programs or includes. Then with that sort of information to work with, go back to SU21 and read all the auth object documentation for the FI auths that you have identified in these "High Financial Risk for Your Company" areas your FI people pinpointed.
Now you have to audit all your roles with these transactions and authoriztions and make them what you now know they shoule be.
Of course I need not mention that the mess you may have to clean up will take time and careful planning. Mass Changes in Production are never a good idea and will do more harm than good if business is interupted as a result. Your well meaning plans to secure your companies assets will not seem like a good idea if the Sales Team can't complete an order due to a change in authorizations.
Take it in small bites and work with one user at a time, or a small team, test thoroughly and communicate with team leads so that they know that if their team gets and error you are standing by with the old role to assign back while you troubleshoot the new one, This is of course for your mission critical teams.
The main thing to remember is that PFCG does not enforce authority Checks, the program does. PFCG is only a help tool, and your Superior Mind must override the suggestions PFCG makes. Configure SU24 to meet your needs so that you do not have to do so much extra work.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
Does anyone know how to identify the Tcodes that "pull" objects and values from another Tcode (such as SM30 and SM31)? I know you can look at SU24 for each Tcode but is there a table or report or something user friendly?
Answer:
JohnBoy, You could look at the tables, that feed the configuration screens of SU24 but the table view is much more difficult to read than SU24.
The tables, as mentioned before are USOBX_C and USOBT_C
I don't understand what you are asking. Do you wan to look at one of your roles and know what it why the authorizations were added in a report format? I guess the first thing that comes to mind is to take the list of transactions in the S_TCODE object, of that role, (copy by double clicking on the field where all the transactions are, then ctrl y and select the list from the box that comes up) then go over to SU24 and choose the multiple settings icon at the end of the second field in the transaction code section > paste your list > copy > execute > click on the value list display icon > and Whoa .. what's that.. A nice report.
Answer:
JohnBoy, You could look at the tables, that feed the configuration screens of SU24 but the table view is much more difficult to read than SU24.
The tables, as mentioned before are USOBX_C and USOBT_C
I don't understand what you are asking. Do you want to look at one of your roles and know why the authorizations were added in a report format?
I guess the first thing that comes to mind is to take the list of transactions in the S_TCODE object, of that role, (copy by double clicking on the field where all the transactions are, then ctrl y and select the list from the box that comes up) then go over to SU24 and choose the multiple settings icon at the end of the second field in the transaction code section > paste your list > copy > execute > click on the value list display icon > and Whoa .. what's that.. A nice report.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
Thanks, Gary.
Let me clarify my question. How can I identify the Tcodes in SU24 that “pull” authorization objects from another Tcode? For example, AO41 & AO84 pulls the objects for SM30.
Answer:
You cannot, they are determined at runtime by evaluating the CINFO field in TSTC. It has several values and several meanings (like locked, unlocked, report, dialog, parameter, etc.)
You can look in table TSTCP and get an idea of the tcodes that will pull in values from other tcodes