DDIC and changing ownership of Jobs

[Former Member]

Goodmorning experts,

I have a question about DDIC user . We use the Security audit log for the DDIC user in our R/3 Productive systems and the logs are very long because the all the filters are enabled . They are required by the auditors so we cant deactivate them.

To make the generated reports smaller , we thought of changing owner in some jobs where the DDIC is the default user . The list of the jobs is :

RDDDIC3L

RDDDIS0L

RDDEXECL

RDDFDBCK

RDDIMPDP

RDDMASGL

RDDMNTAB

RDDVERSL

SAP_APPLICATION_STAT_COLLECTOR

SAP_CCMS_MONI_BATCH_DP

SAP_REORG_PRIPARAMS

SAP_REORG_XMILOG

SDB_MONITORING_DATA_AUTO_ACTIONS

I will not touch the jobs in the 000 clients , i am talking only in the productive systems.

Is there any other solution about making the audit logs smaller ? Or should i proceed with changing some jobs on a user with the same authorizations like the DDIC , although it is not recommended ?

[Former Member]

Very good idea.

Create a SYSTEM type user with specific authority for those "basis jobs" only (so that they are not worth logging for all events) and schedule them under that user ID.

You can do the same in client 000 as well, and then trim DDIC's authority and secure it in a user group until the next upgrade (which is what DDIC was intended for - but then some bright spark hardcoded the ID into a few other programs... but those have all been removed now, to my knowledge).

Cheers,

Julius

[Former Member]

Hi Julius ,

so not just copy the authorizations from DDIC to a system user, but exactly the right roles for running the "basis" jobs ? If the new system user has SAP_ALL i dont think (from the auditors side) that it needs to be logged.

The DDIC user i dont want to change or to "trim" , it is used in system emergency cases and i dont think my team will agree to that option. In this cases we document the actions with the DDIC user .

Regards,

David

[Former Member]

> so not just copy the authorizations from DDIC to a system user, but exactly the right roles for running the "basis" jobs ?

This is always the better, even if more tedious, option => minimum rights principle.

> If the new system user has SAP_ALL i dont think (from the auditors side) that it needs to be logged.

Oh.... if that is the case, then which users with more than SAP_ALL would be worth logging?

> The DDIC user i dont want to change or to "trim" , it is used in system emergency cases and i dont think my team will agree to that option. In this cases we document the actions with the DDIC user .

Having such an "emergency user" is very popular and usefull to be able to trim the authorizations of users but keep the support flexible for when real surprise events happen.

But you don't have to use DDIC for that. It is not to my knowledge what DDIC was intended for.

Cheers,

Julius

[Former Member]

Hello Julius ,

i ment that system users wouldnt be needed to be logged from auditors side , even if they have SAP_ALL.

But maybe i am wrong.

And i am not sure how to give only the needed roles to the system user which will run the basis Jobs.

Thank you anyway for your tips i will implement my changes soon

[Former Member]

Julius

are you certain that DDIC should not be needed anymore? as far as i have experienced DDIC is still the owner of the data dictionairy and is needed for imports!

[Former Member]

Hi Auke,

There are a couple of places where DDIC is prevented from being included in certain things by checking sy-uname NE 'DDIC'.

I believe (was told by a member off the DDIC team in Walldorf) that programs other than those required for upgrades of SAP owned objects are the only ones (now) which still include these DDIC checks (which is the documented purpose of DDIC, so they are okay).

If I remember correctly, the name of the program which causes this confusion is RDDIMPDP. There are DDIC sy-uname checks in it for determining whether an object owned by SAP can be imported. This leads to the urban legend that only DDIC can run it, and the job needs to be scheduled under user DDIC.

This is however to my knowlegde not true. You need DDIC as a dialog user for upgrades only.

Other problems are "setup wizards" which automatically create jobs or define other things using sy-uname (or parts of it). If these tasks are performed using DDIC, it leads to the impression that the system "needs" DDIC for it, or only DDIC can do it... => also not true.

Cheers,

Julius

[Former Member]

> i ment that system users wouldnt be needed to be logged from auditors side , even if they have SAP_ALL.

I would say that system users who only have authority to perform (many, boring) background tasks which are parts of processing which require user interaction to be completed, would not need to logged for many events. Perhaps failed logon and failed RFC call only.

If your system user is saved in an RFC connection and has SAP_ALL, then that is a different story...

> And i am not sure how to give only the needed roles to the system user which will run the basis Jobs.

Tough question... you could trace DDIC and check that it was only used for exactly those jobs, and then build a manual role from there for the new user. It would be a start.

Cheers,

Julius

[Former Member]

Sorry for not answering earlier. After testing i came to the following conclusion .

The Job that is producing the big audit logs is the SAP COLLECTORFOR_PERFMONITOR.

I changed the user from DDIC to a different system user and the job run with no problems . But SAP says ([http://help.sap.com/saphelp_45b/helpdata/EN/c4/3a7ede505211d189550000e829fbbd/content.htm|http://help.sap.com/saphelp_45b/helpdata/EN/c4/3a7ede505211d189550000e829fbbd/content.htm])

that this job should run under DDIC . So my question has been answered

[Former Member]

That documentation is from release 4.5B... (see my comments above about "higher releases").

Now, let me take a look at what it says...

[Former Member]

> So my question has been answered

Yep, times (and programs) change...