SE38 and SE16N issue

[Former Member]

When we are running the fire fighter report in production , the report gives

log with user having access to SE38 and SE16N though the firefighter service user and dialogue user do not have any direct or indirect access to SE38 and SE16N

Does any one have answers to this kind of an issue.

I am just working with SUIM in production to analyze this:

I observed that there was manually added profile from GRC which was deleted from the production system manually on 1/04/2010. I suspect it could be the problem monger but unable to get details of this profile number(tcode/objects)

Edited by: Franklin Jayasim on Sep 2, 2010 7:21 PM

[Former Member]

Just a guess ..

If the logs are showing SE38 and SE16N at the time when that profile existed then it could be that profile else you can also look for other entry places like SE93, SE37 with the usual culprit S_DEVELOP authorization object.

[Former Member]

Hi Nishanth,

Yesterday evening I took all the roles of firefighter user and the dialogue user combined all the roles , created a test user in DEV and tried to execute SE93 and SE38 it said no authorization.

But the firefighter Log says the user executed SE38, I am really shocked! never faced a situation like this.

[Former Member]

The "log" you are using does not give a reason code nor return code, so it does not tell you what really happened.

It only records GUI events regardless of whether the tcode actually ran or not.

Yes, you can follow what the user attempted to do, but not what they actually did necessarily.

It is just a UI to standard functionality, which mixes auditing, performance stats and logging into a chronological output with lots of "false-positives".

Having said that, the user might indeed have successfully started these transactions and not just attempted to in the dialog events. What happened immediately prior to these tcode calls?

The best option is always to automate the events and filter on criticallity. That way you can do your forensics soon after the event (or even auto-react to it). So you need monitoring for this.

The attempt to start SE38 and SE16 compared to program code display and table contents via the workbench is basically SAP standard. There is nothing critical about it unless your auth concept is defunct to permit it...

Forget about tcodes when talking about critical access!

Cheers,

Julius

[arpan_paik]

You might like to look into change history for profile to see the object details. It will be wise to see the change history in dev system

[Former Member]

Based on the change history I posted this question , a profile was deleted manually in production during january 2010

The fire fighter shows log report that the user had executed transaction SE38 and Se16N , my suspicion is if the log was before January 2010 then it would have been that profile which gave this access.

If not it has to be S_develop , S_program

I remember long back in another that the tcode in virsa itself had a * authroization for object S_tcode, if that was the case the test user should be able to execute in the DEV box.

In any case the client party have opened a ticket , I will post the result once SAP comes with the appropriate answer.

[Former Member]

Please check in rsusr100n whether there are change docs for the user, including profiles and reference users.

If not then the log might show a very fast response time because the tcode didn't start.

Anyway, these are both report type transactions and can be started in many ways without the ST03 data being able to pick up a critical transaction name tied to it.

Let us know what happens to the ticket.

Cheers,

Julius