PFCG authorization objects vs SU53 checks

[Former Member]

Hi all,

I was thinking I have understood for a long time authorization checks. But no.

So Here's my question.

When I ahd a transaction in PFCG menu, PFCG gets the authorization objects to maintain automatically (from SU24 checks). OK.

When testing the role in ECC : : error. SU53 qays that authorization objects are missing. How the tests are working regarding SU53 and PFCG ?

i.e tcode_de = MDBT in PFCG, PFCG gets M_MTDI_ORG object to maintain => OK

When testing my role, SU53 says that other objects is missing, i.e S_ADMI_FCD. I don't understand because this object is checked with 'NO' in ECC.

Thx.

Laurent

[Former Member]

Hi Laurent

I know how you feel

Don't rely too heavily on an SU53 (especially an S_* object/FDKUSER/others I can't remember - it only shows the last failure and may not be relevant to the tcode you are working on, try also running ST01 just in case/if you don't trust the SU53.

Cheers

David

[Former Member]

Hi

> When testing the role in ECC : : error. SU53 qays that authorization objects are missing. How the tests are working regarding SU53 and PFCG ?

The auth checks performed are dependent on lots of things: system config, functional config, master data setup, use of the transaction.

The config in SU24 can't cater for all of those options so SAP gives us the ability to make them more accurate for our particular situations.

> i.e tcode_de = MDBT in PFCG, PFCG gets M_MTDI_ORG object to maintain => OK
> 
> When testing my role, SU53 says that other objects is missing, i.e S_ADMI_FCD. I don't understand because this object is checked with 'NO' in ECC.

You can't deactivate a check on an S_ or P_ auth object. These auths are fundamental methods of protecting the SAP application (S_) and personal data (P_)

As David says, the SU53 only shows the last auth failure and there is often lots of spurious stuff reported that isn't required to allow the transaction to process. In this respect ST01 is more useful as it (usually) shows you all the auth checks being evaluated so you can more easily focus on the important ones.

[Former Member]

in most of Functional tcode, authority check is done with values in some master tables....

so such failures show STRANGE check failure in SU53.......

the object may be in no way related to your tcode and adding that object, will also not resolve the issue.....

what i do in such cased is debug......... Breakpoint at...... 'Message'

regards,

Surpreet

[Former Member]

In such cases, and especially if you are finding it a hard time to go through the program itself and looking for "Authority check" statements, its easier to perform ST01 auth traces against the test user, as pointed out in an earlier reply, and rely on the findings of missing auths on the report produced.

If the issue is with an Z-transaction, would advise updating the SU24 entry for that code to reflect the missing auths found.