Purpose of having Tcode: START_REPORT

[Former Member]

What exactly is the purpose of having Tcode: START_REPORT? How is it different from having SA38. It seems that programs by passes the auth. check of S_PROGRAM, when using START_REPORT. The Tcode is assigned in our common role, and the internal audit is now asking us to remove it. And we would like to know what the impact would be. Thanks.

[Former Member]

Hi Kevin,

S_TCODE is the only object which will be cheked when you run transaction <b>start_report</b>. With this transaction a user will be able to run a <u>report which is not assigned to a Authorization Group</u>.

For Ex: Rports like RSPARAM, RSTBHIST

This means that a user with Acess to START_REPORT will be able to run some reports without actually having access to SA38 which is a security risk. This could be the reason why your IA Team is asking you to remove the transaction.

Hope it helps.

PLease award points if it is useful.

Thanks & Regards,

Santosh

[Former Member]

Dear Kevin,

I run into that, but never had a closer look. Because of your questionI did a short analysis:

I checked the authorization trace: START_REPORT checks object S_PROGRAM - so this is not the point here.

If you want to learn something about START_REPORT, you need to look into table TSTCP (holding the key configuration for those "parameter transactions").

Most of the transactions that just start a report, use the "/START_REPORT..." setup (~6400, compare that to the mere 3 transaction I found using "/SA38...").

The reason seams to be obvious for me: START_REPORT can also start queries (AQ), report writer reports (RW ?) and some other stuff I don't know in detail ...

I guess that's why it is included in your profiles - although I can't believe that START_REPORT was designed to be used outside of parameter transactions Look at this ugly screen you get !

I did not test this, but I think for your auditor this means:

- Somebody how has START_REPORT can also start queries (and thus doesn't need SQ03 anymore). And he can start all these nice Report Writer stuff (e.q. in FI and CO).

- or, to turn it around in a different way:

In terms of transactions, a user that has START_REPORT is more powerful than a user who has the 6400 T-CODEs that make use of START_REPORT in TSTCP

Hoping this clarifies the subject

Ralf Nellessen

[Damean]

In my observation when creating a new Tcodes via SE93 & using the "Transaction with parameters" option; I could use either SA38 or START_REPORT. START_REPORT basically provides me with a much wider selection of options on how the program to be run.

If I pick SA38, the primary option I could specify is "RS38M-programm" i.e. the Program name.

via

START_REPORT, other than the actual program name; I have a little bit more additional option such as whether to specify program variant, skip selection screen, background only etc.

HTH...

[dan_reeves]

START_REPORT is the best way to create a parameter transaction for ad-hoc or sq01 queries.

When you move these queries up your development infrastructure the physical program name changes and this transaction lets you run the reports by Infoset and Usergroup.

[Former Member]

Queries are a bit of a pest in themselves and if available it is always best to defer it to Info System reports in the transactional systems and AA auths in the OLAP systems.

Technically, I need to avoid the authority for the core "start" transaction (START_REPORT, SUB%, SA38, etc...) and rely of the passed parameters to them from the calling tcode.

If you believe the ST01 trace too liberally without a context sensitive "blacklist" on it, then adventurous users will find it.

If you correctly restrict these types of objects, then SU53 will be infested by false-positives.

For the same reason ST01 / SU53 has been enhanced about 2 years ago to show "reason codes" for the result of the check.

There are some recent discussions about it as well if you use the search, but it has actually been available for a while already.

Cheers,

Julius