Vendor info change (XK02/MK02) investigation

[Former Member]

Hi! Security Experts, We have an issue where vendor information was changed by multiple user-ids, and the corresponding actual users are saying they have not changed. The user-ids used to change the info don't have access to MK02/XK02 at S_TCODE level but looks like they have access to rest of the authorizations with activity 02. Need help investigating how the changes occured and who made them?

I have asked my functional experts to research if there is a way to get to vendor-info change screen via a different t-code other than MK02/XK02, because the user-ids have every other authorization then S_TCODE. Ran ST03N on the user-ids based on the timestamp to narrow down the t-code list through which the vendor-change screen might have been launched. No luck yet and if you have any ideas on further investigation please share.

Thank You,

Rama.

[Former Member]

Copy the user to a test user (in QAS) and display a G/L document in FB03 where the posting key entry is for a vendor account.

Double-click the vendor account....

Same goes for a whole range of other transactions.

> The user-ids used to change the info don't have access to MK02/XK02 at S_TCODE level but looks like they have access to rest of the authorizations with activity 02.

That is what you gave them. That is what you get.

S_TCODE is only a very general "start" level authority to functionality. It does not necessarily prevent the user from using it.

Most likely the error is in your role design...

Cheers,

Julius

[Former Member]

Hi Julius, Thank you for the info. I agree that S_Tcode is just a maindoor and we need to secure by activity/org.levels/other-critical authorizations and will be fixing it.

However coming back to investigation - (ST03N) below are the transactions executed on the day of changes occured, under the user-id tied to vendor changes. Trying to know if there is way to change the vendor info by navigating through any of the transactions used.

ME21N

VL02N

ME2L

SESSION_MANAGER

ME23N

ME2O

MMBE

ME2M

MD04

LS26

MK03

<AD_RESET_USR02>

RFC

MM02

<AD_DISPLACE>

MM03

Thank you,

Rama.

[Former Member]

Looks like you found it with MK03.

Go into the transaction, select a vendor and hit F5. This will allow you to change the master data assuming the user has the underlying authorizations.

Matthias

[Former Member]

> The user-ids used to change the info don't have access to MK02/XK02 at S_TCODE level but looks like they have access to rest of the authorizations with activity 02.

Just double click the vendor (and see Matthias's comments about exception handling in SE97).

The problem is most likely in your role design. Why do they have the authority to change vendor master data and where are they getting it from.

Most likely this question will remain unanswered... (usually they do). That problem is on your side.

Cheers,

Julius

Edited by: Julius Bussche on Jul 31, 2009 1:34 AM

[Former Member]

> Looks like you found it with MK03.

I don't think it is only limited to MK03, but we seem to have located the problem. It is not the tcode...

Cheers,

Julius

[Former Member]

Hi Julias, I clearly understand the issue and am sure can fix the role/authorizations to prevent this happening in future.

The system records a (changes made by) user-id and the user denied it saying he did not update the vendor info. Business wants to know who did it? and how it happened?

The user is denying it based on the fact that he cannot run MK02/XK02, and now the need is to find out how the update was done (considering the fact all authorizations for change exist except S-TCode)?

Mk03 - vendor - F5 - looks for S_TCODE MK02 (says no authroization for MK02)

I appreciate you and Matthias taking time to respond and sharing your ideas.

Thank you!

[Former Member]

> The user is denying it based on the fact that he cannot run MK02/XK02, and now the need is to find out how the update was done (considering the fact all authorizations for change exist except S-TCode)?

You cannot really blame the user. After all they probably just clicked around a bit and hit the "Save" function...

They were authorized to do so (i.e. use the function) based on another transaction entry point.

Check the change documents to see what they changed anything - you can most likely find the reports for this in the Information System.

If you want to dig deeper than this, then you can forget about S_TCODE for a start.

Cheers,

Julius

[Former Member]

Julis,

There is no intention to blame the user - the issue is described so to make/present the scenerio. Infact, the changes occured multiple times by using multiple user-ids and hence insisting on know-exactly what has happened

Rama.

[Former Member]

Hi,

You also may want to check tcode couples. Go to transaction SE97 and enter XK02 or MK02. This returns a list of call transactions that the users might be authorized for. Remove all tcode ranges from your role profiles, otherwise you will always get into situations like this.

Regards, Matthias Hessler

[Former Member]

Sorry, but that is not good advise.

SE97 only really kicks in when the code checks the couples (not all do).

Removing the tcode's from roles which are coupled as callers with ok-flags will 9 times out of 10 prevent the user from doing their jobs which they are authorized to do - from specific calling transaction contexts.

This is a rather complicated and not the most secure area in SAP. Tcodes are only an upfront level security layer. The authority to complete the transaction flow and the congiguration of the transaction is of much more importance.

Cheers,

Julius

[Former Member]

I didn't say that you were wrong, I am just saying that SE97 gives you the couples that are in the system. If you remove the S_TCODE ranges from all role profiles you close that gap. I would still do what you recommended.

Cheers, Matthias

[Former Member]

Sorry, I was about to change my post comment to disclaim "not necessarily good advise".

For a moment I thought you wanted to deactivate all the couples... so yes, you could be correct.

Ranges should not be the problem (though they generally are a problem themselves) as the value should be picked up by the User Information System (SUIM) as lying within the range.

I think we are both on the right track here

Sorry for the snappy response.

Julius

[Former Member]

Not a problem.

Cheers, Matthias

[Former Member]

Cool. Lets wait for OSSABAP to see the light as well