Question:
Hi,
We are currently unit testing our roles in 4.7 and are encountering authorisation errors (particularly in relation to called transactions).
eg. AW01N is calling the following transaction codes (confirmed by auth errors and auth trace), yet these called transactions are either "not maintained" or not defined at all in the TCDCOUPLES table.
TCode Check Status in TCDCOUPLES table
KS03 Not Maintained
FS00 Not Maintained
CJ13 Not Defined
It just seems that the TCDCOUPLES table is not always reliable in defining the transactions that are being called by programs. We are having to continually run auth traces to get a more accurate picture of what auth checks are being performed by the program, which is time consuming.
Is anyone out there aware of a fix that can be applied to update the TCDCOUPLES table with missing values? Or perhaps there is a method to the madness...
Would love to hear from you.
Thanks,
Dorsal
Answer:
TDCOUPLES is only good if you there is NOT a hard coded S_TCODE checK. TDCOUPLES is for abap command CALL TRANSACTION or LEAVE TO . If SAP hard coded the S_TCODE check there is nothing you can do but search teh code or trace.
Answer:
Thanks for your response John.
It appears that to properly address this issue (i.e. ensure that the necessary authorisations are captured in a role by the Profile Generator - now and in future), the missing S_TCODE and supporting auth objects/values need to be manually added to SU24 for a particular calling transaction.
In my earlier example, this would mean adding KS03, FS00, CJ13 and their supporting auth objects/values against AW01N in SU24.
Note: I found that by changing the check indicator from "Not Maintained" to "Do Not Check" for called transactions KS03 & FS00, I was able to avoid the S_TCODE check. However, I still had to add the supporting auth objects/values for KS03 & FS00 to the role. It makes better sense to just update SU24 with both the called S_TCODE and supporting auth objects/values. This works in better with the PFCG and is more upgrade-friendly.
Do you agree? Still wish there was an easier way to update missing values in the tables of the Profile Generator.
Dorsal
Answer:
Configuring SU24 is the proper way to manage authorizations in a tcode. there is no simple answer to SU24 configurationas it changes based on the user's needs. Just remember... It all pays the same...
Answer:
Do you put that called transaction on the positive unit test script and have the business sign it?
I know the business did not request it, and it's not in the menu, but from an auditing standpoint, it is in S_TCODE in your profile.
Answer:
Do you put that called transaction on the positive unit test script and have the business sign it?
I know the business did not request it, and it's not in the menu, but from an auditing standpoint, it is in S_TCODE in your profile.
Personally I would do it from a completeness point of view.
If the tx is in S_TCODE and the supporting objects are in place then you effectively have access to the transaction. It only takes a user to actually look at an SU53 failure on S_TCODE for them to see thay have access to the transaction.
From an auditing point of view it's best to declare the transaction. Most auditors are unlikely to pick it up but it shows you are doing everything "to the book"
Cheers,
Al.