SE16 parameter Tcode checks on SE16 itself

[marcel_janssen]

In ECC 6 I found a SE16-parameter transaction (eg SE16_BSEG) will also check on S_TCODE = SE16 after the check on SE16_BSEG. Is this new functionality of is this an error?

To me this makes no sence, since it would mean to grant SE16 on a single table, I would excplicitely give access to all tables within the same authorization group.

Kr Marcel

[manohar_kappala2]

Hi,

Did u check the skip intial screen check box in SE93 while creating the parameter transaction. That seems to be the problem.

[Former Member]

Also in lesser versions it has always been recommended to use SM30 for parameter transactions because you were able to back out of the parameter transaction created with SE16, right back in the SE16 transaction. This is not the case with SM30 but you do need to make sure the skip this screen is checked for both.

Thanks,

Mary

[marcel_janssen]

Yes, initial screen is skipped (standard SAP tcode SE16_BSEG).

I do not understand the logic behind this. Could anyone else checkon ECC6 system? I tried on ECC5 and there it only parameter tcode is checked.

[marcel_janssen]

Mary, I was aware of this problem. A few years ago I managed SAP to get a fix on this, which was included in a support package.

My customers requirement is for a parameter-tcode on SE16 (though I advised negative on that). The question is, why suddenly do I get a check on SE16 itself?

Kr Marcel

[Former Member]

Hi Marcel,

Check in SE97 whether the new system has a default check indicator which is active for SE16 when called from SE16_BSEG. SAP may have thought of a reason for thinking that if the user can SE16_BSEG to the BSEG, then they should (at least) also be able to SE16 to any other table they have S_TABU_DIS access to.

If you want to turn the check off, try to either delete the entry or replace it with a specific "Do not check" flag.

Cheers,

Julius

[marcel_janssen]

Hi Julius,

TCDCOUPLES to my believe only triggers the "Call Transaction" functionality. To my knowledge a parameter transaction is not executed by "Call Transaction".

I have tried this by creating a ZE16_BSEG (own created SE16_BSEG), but still the authority check on SE16 occurs.

Your opinion SAP may have added the SE16-check to able all other tables within the same authorization groups does not feel right. It would be contradictonary with the efforts SAP is making in security.

Kr Marcel

[Former Member]

Hi Marcel,

Try to run a trace on it, and then display the coding at the point where the authority-check is on SE16. Can you display it?

Often the developers add comments with reasons for checks, often also references to SAp notes.

Does that help?

Julius

[marcel_janssen]

I'm not a developer, but I'm gonna try it Julius.

Also, next time I'm at the customer, I'm going to create a customer message for this. See what SAP itself comes up with

Kr Marcel

[manohar_kappala2]

Hi Marcel,

USe the SE17 Tcode to create the Parameter transaction.

This will work.

Infact it doesnt even bring u to Se16 as well.

Hope this helps

Manohar

[Former Member]

Hi Marcel,

Keep in mind that the authorization check S_TCODE only provides a very general level of protection. This check alone is no reason to suppress an authorization check.

When you go reading through the trace, keep an eye out for:

* Jau, suppi

I place my bets on what you are looking for being located just above it...

Regarding SE97: the function module AUTHORITY_CHECK_TCODE, which reads TCDCOUPLES for permitted pairs of transactions, can be used ahead of several different ABAP operations (not only CALL TRANSACTION). In this case I believe it is GENERATE REPORT or something similar.

Cheers and lets see what SAP says,

Julius

Message was edited by:

Julius Bussche

[marcel_janssen]

Julius

The solution is in OSS-note: 947557.

so, indeed it was a program error

Kr Marcel

[Former Member]

Hi Marcel,

That also explains why I could see the call to AUTHORITY_CHECK_TCODE, but you could not.

Have a nice weekend,

Julius