Missing authorization objects for a specific Tcode

[Former Member]

Dear SAP Basis /Security ,

When we assign some users to a specific TCodes , user keep facing issue with missing authorization and we keep do /SU53  till we got all authorization object need.

Is there any way to a void such missing authority by adding all required authorization objects at once ?

Thank you,

Anas Almomani

[Former Member]

HI Anas,

To avoid this kind of problem, i suggest that you have to create a role with the tcodes the users will need and have this tested in you development. During the test, you will know if the user will have missing authorization objects. Add the missing auth objects and re-test until you have an all-green SU53.

Transport this role to the PRD for the users to use.

Regards,

Rod

[Former Member]

Thank you Rodel for your reply .

Your answer  is helpful and i have tried and this what i do to resolve this issue .

but in big origination , we receive many request of this type and we could not perform test scenario for each TCode .

But what am looking for, is there some Table or report in SAP  or any way to find the all required objects needed without doing the test scenario .

[Former Member]

Yes Anas,

Use report RSABAPSC this will let you know all auth objects being cheked for a particular t-code or program.

Regards,

Amit

[Former Member]

Hi Anas,

Also, once the tcode is added in a role in PFCG, go to Authorization tab-> click Edit/Pencil -> Click +New Button (beside +Maintained).

That will expand all the affected authorization objects. You will then edit those authorization objects.

Regards,

Rod

[Former Member]

Dear Anas,

I assume this issue is reported in production environment.

Provide SAP_ALL to user in DEV/QA system and put a trace (transaction ST01) on his user id and then ask him to execute the concerned T-code and perform his activity. Once he is done switch off the trace and read the trace report file which will have all the authorization objects (along with values) being checked when he was doing his activity.

Make sure user is having access to all these auth objects (with same values as captured in trace) in his roles in production. This will solve the issue.

Regards,

Amit

[Former Member]

I really would not advise that.

• First of all there is no earthly reason for anyone testing business roles to need SAP_ALL, even in a Dev / QA environment. Why should a Finance user need Basis authorisations?

• Secondly, if you record an ST01 trace, a properly restricted user may fail multiple authority checks but still be able to complete the business process successfully. In some cases, there will be commonly known false flag authority checks in the trace file. Two common ones are S_CTS_ADMI and S_ADMI_FCD. If you give those objects to a user, you will have given them system administration and transport system management authorisations. You do not necessarily need to give all authorisations encountered by the test user.

• Thirdly, you will pick up mistakes that the user has made in the trace file in executing the business process.

[Former Member]

Hi Will,

• Probably Anas may have tough time to figure out a role which will give the test user full access for the intended activity reason why i suggested to use SAP_ALL as the id will be in supervison and een if a business user has SAP_ALL he will not initiate any Basis actions or any action not relevant to him. This needs to be ensured by the administrator before he assigns SAP_ALL and initiate trace. Assigning SAP_ALL does not intent to provide a user access to ruin system settings even when the id is under supervision.   So yes if you have a role which will provide user the unrestrcited access to execute a particulart task add that role rather than SAP_ALL. SAP_ALL to be used only in case u are not able to figure out a higher auth level role.

• Yes you may see false checks auth objects as well and being a security admin you really understand this. You shouls never add something appearing in trace file which is not relevant. Any way even if you suggest to add such false flag chek auth objects they will be not approved by role owners, only the relevant ones would be approved. Will your statement above makes me feel that you do not beleive in ST01 trace.

• Its the job of security administartor to instruct the test user to perform only the intended steps not even a single click extra to avoid mistakes (as u referred). Best way is to ask test user to do screen sharing so that you can watch while he is performing the task.

[Former Member]

Hi Amit,

• You're putting a lot of faith in controls that rely on other people knowing what they're doing and doing what they say they will. Simply asking someone to promise that they won't execute any basis transactions is no guarantee that they won't do exactly that, whether it be accidentally or deliberately.

• I am very much a fan of ST01. But I see far too many people who see the failed authority checks in ST01 or SU53 and just add the objects without any consideration what they are doing. As Frank coined the phrase, "a fool with a tool is still a fool". I don't know the poster here, so I can't watch someone recommending to add all of the objects in an ST01 trace without clarifying that there will be false flags which need to be avoided.

• The security administrator can instruct the tester to perform only the intended steps, but how does he enforce it? Do you have machine gun turrets to obliterate any tester who deviates from the script? Do you stand behind them with an electrocuted cattle prod, and zap them with it if they make a mistake? If so, can I come and work at your place?

I'm only kidding you, but you get my point, I'm sure?

[Former Member]

You'll be lucky to get it right first time every time - this is where testing is so important.

Some things that you can do to ensure a better chance of getting it right are:

• Make sure your USOB tables are up to date.
• Only ever add tcodes to the role menu so that the default proposals are pulled in from the USOB tables
• When you find a missing auth for a tcode, update SU24 and fix it for all affected roles, not just the one that you find the problem with.

I also like to produce a pivot table before the role is transported to QA, which shows the functional team every object in the role down to field level and the values that the role contains. The functional consultants are much better placed to tell me, for example, what Chart of Accounts I should add to role.

[Former Member]

Thank you All of you info , it is helpful.

I want to ask if we can use Transaction SU24 to find required objects by choosing object checked with yes in SU24.

Thank you,

Anas Almomani

[Former Member]

Hi Anas,

  It is a good question actually and every security administrator at some time faces this issue.

Definitely you can use t-code SU24 to find required objects for that T-code by choosing object checked with yes and maintain the appropriate values for these yes objects in the role at the first time when you are adding the T-code in any of the role. Before maintaining the values for yes auth. objects in the role, please consult with the business user for appropriate field values so that we can restrict the user for required values only.

Thanks,

Varun Jain

[Former Member]

Hi,

I think it´ll be much easier for what you´re trying to achieve if you display the table USOBT_C. It will basically give you the same info as what you can see in SU24 transaction. Keep in mind that whatever you find there is what SAP put there as a reference and "recommendation" (specially the proposed values), which means that you will still always find errors IF during the implementation project phase proper testing wasn´t performed.

As for the long run, the experience says that maintaining this table via mentioned transaction plus proper testing and documentation is the key to have successful role build and thus the maintenance efforts are be minimal

Good luck!

Thanks,