Unauthorized access to transaction MSC2N

[Former Member]

Gurus,

We have an issue where a user has restricted batches, using MSC2N, even though the user does not have access to the transaction code.

This is on a ECC6 ERP system.

So far I have:

Listed all transactions executable by the user - MSC2N is not there. MSC3N is, though.

Checked AGR_1251 to make sure that S_TCODE = MSC2N is not present in the account.

Checked the STAD file (with CSI-Tool) and the log shows that the user has used the transaction about 5 times in the last month.

Checked all the objects/field values related to MSC2N in SU24 and the account has all of the required ones except for M_MATE_CHP, that is not in the account.

The batch logs shows the user's account and MSC2N as the transaction used to change it.

I have to find the whole so I can make sure that this and other users cannot use it.

I appriciate any insight you may have in this issue.

Thanks

Juan

[Former Member]

Just ask the user...

[Former Member]

Did that, no luck ;-(.

Actually I think the user is not aware of restricting the batch. As I said, the user does not have access to the tcode and is not familiar with the screen.

J.

[Former Member]

> Actually I think the user is not aware of restricting the batch. As I said, the user does not have access to the tcode and is not familiar with the screen.

Off the cuff, I am not either.

A thought: Take a look at the documents, if there are any. Is there a difference between the "Created by" and "Posted by" user ID's?

My thinking is that they just created the batch data, and someone else (or a job) posted it.

Cheers,

Julius

[Former Member]

Did you compared the users in SUIM with their profile and their acccess/authorizations.

Try there and check all other excess authorizations that they have.

Hope this would help you.

[Former Member]

Did that too. I checked all the user's authorizations and compared them to the information available for MSC2N in SU24. No only is the trasaction code not part of the users' authorizations, there is M_MATE_CHP, also required to run MSC2N, not present in the buffer.

J.

[jurjen_heeck]

Just one more wild guess, is there a reference user linked to this user in SU01?

[Former Member]

Good guess, but unfortunatelly no, ther is no reference user attached to the user's account.

J.

[Former Member]

Start report RS_ABAP_SOURCE_SCAN in transaction SA38 etc and in the pattern field enter:

CALL TRANSACTION 'MSC2N'

Does anything turn up?

It might also be a generic include, So also just scan for:

MSC2N

Cheers,

Julius

[Frank_Buchholz]

Hi all,

if CALL TRANSACTION is used, then

- an S_TCODE check for the called transactions is usually not executed (except if a check if defined using transaction SE97)

- an entry in table TCDCOUPLES usually can be found

However, I do not find MSC2N entries in table TCDCOUPLES which indicate serious problems. Especially, I do not find an entry like "MSC3N calls MSC2N with OKFLAG = SPACE"). Therefore, I cannot tell you yet, what happens in this system.

Kind regards

Frank

[Former Member]

I cehecked SE97 and MSC2N is in there, as well as in table TCDCOUPLES. If I got your explanation correctly this means that the S_TCODE is checked when jumping from MSC3N to MSC2N, correct?

Thanks

J.

[Frank_Buchholz]

>

> I cehecked SE97 and MSC2N is in there, as well as in table TCDCOUPLES. If I got your explanation correctly this means that the S_TCODE is checked when jumping from MSC3N to MSC2N, correct?
> Thanks
> J.

Yes, S_TCODE is checked during an CALL TRANSACTION call if the corresponding entry in TCDCOUPLES shaows OKFLAG=X

Kind regards

Frank Buchholz

[Former Member]

> Yes, S_TCODE is checked during an CALL TRANSACTION call if the corresponding entry in TCDCOUPLES shaows OKFLAG=X
> 

and

> Especially, I do not find an entry like "MSC3N calls MSC2N with OKFLAG = SPACE"). 
> 

This would indicate that SAP´s authorization trace to populate the SU22 data with SAP data did not pick up a call transaction either for an ´X´ flag to be set for.

Therefore, I cannot tell you yet, what happens in this system.

My last guess would be a variant transaction which is using MSC2N to start the program via a different screen. In this case sy-tcode is set to the value of the core transaction when the screen is called - this would appear in the log.

Check in table TSTCP (I think) in the field PARAMS (I think) for the value MSC2N anywhere.

Cheers,

Julius

• = not logged on and cannot remember exactly.

[Former Member]

check all the roles which gives access to the transaction MSC2N and see if any of these are assigned to the user. There might be some role which gives access to this transaction and is asssigned to the user.