SM20 DDIC terminal issue

[Former Member]

I am running a DDIC audit report in 3 different production systems using SM20. I'm having an issue with pulling up the terminal in which the DDIC was (supposedly) opened. Sometimes the terminal is located where no one would be using DDIC logon. I've ran into this issue several times when running the audits. Has anyone seen this issue before? Could it be my settings in SM20? I've tried several things and it's coming up with the same bogus data.

Any help would be greatly appreciated!!

Doug

[Former Member]

Hi Doug,

Note 539404 - FAQ: Answers to questions about the Security Audit Log should answer your question. Refer the question # 10 in the note, which answers the Question: Why is the terminal name missing in some messages?

You may also refer Note 1497445, and Note 971846 that speaks more about the similar issues.

Regards,

Raghu

[Former Member]

Hi Raghu,

I don't think that answer's my question. I'm not missing the terminal name. I'm getting the terminal name. When I go into the EXTRAS tab in SM20 and put the terminal name in, it comes back with a terminal that would not be using DDIC.

Basically what I'm doing in SM20 is:

Running a check on DDIC and if any transactions were used while logged in as DDIC.

I capture the terminal name and run it through the EXTRAS tab in SM20 to see who's terminal it was accessed on.

What I'm getting back is a terminal that DDIC was not logged onto and no reason to run any transactions using the DDIC id.

I'm thinking it's a bogus logon and that no one really logged into DDIC and ran the transaction on that terminal. For audit purposes I have to explain why this is happening.

I'm hoping (if it's a bogus logon) to have a way of running the report and not have this issue.

Again, I appreciate any help with this issue.

Doug

[Former Member]

Hi, Doug,

What kind of login is it recording or are you only seeing transaction executions?

[Former Member]

Also, what is the actual last login date for DDIC?

Methinks that maybe some process is using DDIC, not that someone is actually using it.

[Former Member]

Melissa is on the right track.

A programmatic logon from a runtime environment on an application server (or server running and RFCSDK) will show the server name as terminal.That is because it IS the client terminal.

You should ideally not use DDIC for application level RFC and not use it in jobs which start external programs or registered external programs.

You can use transaction SMGW (talk to your basis folks) to monitor the "external security" functions to see where the calls are coming from.

In the case of the SM20(N) entries you will have to go accross to the application client and see who (or which job?) triggered the DDIC context login in your system (as target).

It sounds to me as if DDIC's authorizations and authentication credentials have been "doing the rounds"...

Cheers,

Julius

[Former Member]

Hi Melissa and Julius,

I'm only looking at terminals that ran a transaction using DDIC.

The interesting thing is, for that transaction, I'm only seeing one use of the DDIC. Where the terminal is located (warehouse), multiple users are using the same terminal and transaction. Wouldn't I see multiple DDIC logins on that terminal or am I misunderstanding your reasoning?

[Former Member]

Hello,

Could you please check with basis guys, if for any connection they maintained DDIC user .

DDIC may be called internally not for logon for updating some table...

perhaps as Julius said please check with your basis team..

Thanks,

Prasant

[Former Member]

Actually it was brought up a couple months ago with the Basis team and they couldn't find anything on their end that would of caused the report to show that anything was done or updated with DDIC tables. I just found this out talking to the person who did this before me.

[Former Member]

Could you provide bit more details?

Thakns,

Prasant K Paichha

[Former Member]

You will need to go and take a closer look at the terminal as it appears to be a client server and not just an end user PC...

Perhaps someone installed a terminal service on it? Or DDIC is saved in a script on the machine? (you can ask basis to change DDIC password anyway to find out if the logins fail).

Which logon type is it? If it is a dialog logon via SAPGui you can activate the login user exit to call FM rfc_system_info via destination SAPGUI to write some system info back from the client to a z-table.

It could even be a redundant application server on the terminal?

Cheers,

Julius

ps: wear a helmet in the warehouse incase there are falling pot plants

[Former Member]

Prasant,

Basically what I'm doing in SM20 is:

Running a check on DDIC and if any transactions were used while logged in as DDIC.

I capture the terminal name and run it through the EXTRAS tab in SM20 to see who's terminal it was accessed on.

What I'm getting back is a terminal that DDIC was not logged onto and no reason to run any transactions using the DDIC id.

I'm thinking it's a bogus logon and that no one really logged into DDIC and ran the transaction on that terminal. For audit purposes I have to explain why this is happening.

I'm hoping (if it's a bogus logon) to have a way of running the report and not have this show up on my report.

ALSO see my response to Julius. I responded to him also, it may give a little more insite to what's going on.

[Former Member]

Julius,

This can show up on any terminal anywhere in the US. The terminal it showed up on this past month was the warehouse. But, it could have been in anyone of the multitudes of buldings around the world. It doesn't seem to show up in the same place, it's a sporadic occurance through the company. I've been doing this for about a year and it's happened maybe six times since I started doing this. I was hoping this was a simple fix, but, it looks more complicated than I thought.

[Former Member]

Then change the password and audit the history of changes.

But you still need to tell us which authentication type was used to login?

Cheers,

Julius

[Former Member]

Hi

Which transaction is it starting and is it showing rapid events too fast to be human?

Regards

David

Edit - is the occurance at random times? Are the terminals always in a "warehouse"?

Edited by: David Berry on Sep 7, 2011 6:11 PM

[Former Member]

It's random terminals and random transactions.

[Former Member]

Hi Doug

Then I would probably follow Julius' recommendation and wait for the emails to arrive...just curious as to why you were asked to check this too. Edit - note to self - remember to remember to read the previous posts. Ignore the 'why' bit Edit

Any pattern to the transactions? MM/FI etc

Regards

David

Edited by: David Berry on Sep 7, 2011 6:34 PM

[Former Member]

Do you mean user type? That's "Dialog".

[Former Member]

Dave,

There is no pattern to the transaction(s).

I did check last login and it was in July. The DDIC report out of SM20 says 8/16. I'm guessing what Julius said is what's happening. My fix will be to check last logon and document that and say it's just bogus and no one logged in using DDIC.

Thanks to everyone for there help and PATIENCE. Being a novice at this, I appreciate everyones help.

Doug

[Former Member]

No, I mean the login type.

Type A = SAPgui

Type B = Background

Type R = remote RFC

Type F = internal RFC

Etc...

It could be possible that some one is debugging a job which has DDIC as step user?

Cheers,

Julius

[Former Member]

It looks like it's B=background.

In SM20 it says "Work Process Type"

[Former Member]

Ahhh... now we are homing in on it...

How many users in your system have authority for object S_ADMI_FCD with value PADM and S_DEVELOP object type DEBUG / activity 03?

If you are fast enough, check the central SM21 system log as well.

Cheers,

Julius

[Former Member]

S_ADMI_FCD with value PADM = 85 users

S_DEVELOP object type DEBUG / activity 03 = 77 users

I'm not familiar with sm21. Not sure how to fill it out.

[Former Member]

You will most likely find 1 of the 77 users logging into the terminal shortly before the DDIC session is being debugged into the foreground.

Check the SM21 central log for messages relating to that user. You might find some entries in ST22 which relate to it as well. Keep an eye out for dynpro_send_in_background dumps and let us know what you find?

You should hopefully also find some "incident ticket" relating to it in your "support system" if you have one.

They are debugging background work processes in SM50 or SM37 and the jobs are running under DDIC...

You should ideally remove DDIC from jobs and restrict the system type users's authorizations as well.

Most likely you will need to restrict S_BTCH_NAM as well as the debugging and process administration authorizations to contain it a bit (77 is rather high...) and make sure these cases are documented.

Sometimes they are also a symptom of low quality programming (if you want to go as far as root cause analysis) but that is much more difficult to fix than restricting authorizations...

Looks like you just opened a can of audit worms

Good luck,

Julius

[Former Member]

I should of said, of the 77 users, 33 of them are OSS IDs for SAP that aren't being used. So there are really only 44 users with that type of access. With a company with over 7000 employees 44 isn't that many. All 44 are Basis or Systems people.

Again, thanks for all your help. It gave me a better understanding of what was going on. I talked to a basis person earlier and he pretty much said the same thing you said.

[Former Member]

If the users are fine then you can audit against the tickets.

Restricting DDIC only to upgrades and batch "system" users to only that which they need also helps.

It is not that hard, but unfortunately easy to make mistakes...

Cheers,

Julius