Authorizations for user DDIC?

[Frank_Buchholz]

There exist some confusion about the required authorizations of user DDIC. Therefore, I like to gather some feedback about real usage for this user.

1. In which clients do you have an active user DDIC (000, 001, production client, others, 066)?

2. Do you use DDIC to logon in dialog or is it only used for background jobs?

3. Which user type has user DDIC (dialog or system)?

4. Which authorizations are assigned to user DDIC?

5. How did you have analyzed which authorizations are required?

Kind regards

Frank Buchholz

SAP AGS Security Services

[Former Member]

Frank,

Here is my feedback from what I have seen so far;

1. Active DDIC in clients 000, prod & 066.

2. DDIC used for logon in dialog (but in very few cases for jobs as well !!)

3. Its Dialog

4. SAP_ALL, SAP_NEW - but its usage is do mointor & noted by reports for audit

5. Thats a tough part

Cheers,

Daya

[former_member182034]

hi Frank,

you can find the answer of your queries.

1. In which clients do you have an active user DDIC (000, 001, production client, others, 066)?
Clients 000, 001 and 066 should be administered by basis folks. Security should only work on working clients. Ask security to get out of client 000. DDIC user should never be removed from these SAP clients.

2. Do you use DDIC to logon in dialog or is it only used for background jobs?

DDIC should be Dialog user,

3. Which user type has user DDIC (dialog or system)?

As the Usage type for the "SYSTEM" is for internal use in system like background jobs. I feel that you will not have any problems in changing the user type from Dialog to System.

But if you were to LOCK SAP* and DDIC account, then problems arise when the BG Jobs running with its access might raise issues.

4. Which authorizations are assigned to user DDIC?

User DDIC needs extensive authorization. As a result, the profile SAP_ALL is allocated to it. The users, SAP* and DDIC, should be assigned to user group SUPER to prevent unauthorized users from changing or deleting their user master record.

Securing User DDIC Against Misuse

5. How did you have analyzed which authorizations are required?

User DDIC therefore does not automatically have administration rights. You therefore need to enter the administration authorizations in user DDIC’s user master record so that the transport programs (RDDIMPDP) scheduled under his name can run without any errors.

Function and Role of User Types and DDIC User

hopefully, you got answer of your questions.

Regards,

majamil

[Frank_Buchholz]

Well, the current answers show how to operate a system in general with least effort but don't point out how to operate systems securely (which costs more effort). Trying to find recommendations for stronger security I like to postulate some rules:

1. System administrators always should work with their own userid, but not with shared users like DDIC, SAP*, etc.

2. If possible system administrators should use a technical client like 000 instead of the productive client for their daily work.

3. Technical users like DDIC should only be used for technical work (backgroung  jobs, RFC calls). These technical users should have user type "system" (*).
User DDIC should be used for background jobs like RDDIMPDP in client 000.
This user should not exist in other clients, especially not in client 001 (demo client from SAP / productive client) or client 066.

4. No user requires authorization profile SAP_ALL. There exist always an alternative which grants better security, however, it might be difficult to find the list of least-required authorizations.

5. No userid needs SAP_NEW (especially not if you already have SAP_ALL;-).
SAP_NEW might be useful for a short time after an release upgrade, however, even in this case you usually have added new authorizations from release specific SAP_NEW profiles to your roleas before going live.

6. System administrators should only have authorizations suitable for their daily work. Therefore you can omit most business authorizations. If more authorizations are required, e.g. in a support or emergency case, that special emergency users (aka. FireFighter) should be used.

7. When it comes to strict security, don't trust the documentation which often describes how to operate a system but not how to enable strict security. (*)
 
(*) There exist some confusion about user types especially for RFC scenarios. Old and current documentation talks about user type "communication" but the truth is describes in note 327917: Forget user type "communication" but use user type "system" for all backgroung usage and RFC usage of techical users.

--
Frank Buchholz
Active Global Support - Security Services     

[Former Member]

Hi Frank,

I have found some "official" SAP documentation on DDIC at http://help.sap.com/saphelp_nw73ehp1/helpdata/en/4f/3eaa7349aa2eb5e10000000a42189c/frameset.htm

In summary,

1.Secure DDIC against misuse by changing the default password in all clients.

2.Lock DDIC and unlock it only when necessary.

I suppose the implication of the above recommendation is that all the Transport System related batch jobs must be changed to used a separate batch user-id. However, in your message above you state "User DDIC should be used for background jobs like RDDIMPDP in client 000."

Is there any reason why you must use DDIC for the transport system background jobs in client 000?

I'm just trying to reconcile you recommendation and the official SAP recommendation.

Regards,
Richard.

[Former Member]

Until 7.01 there was some hardcoding of DDIC in the RDD* programs or you should at least know DDIC's password. This was removed / corrected so you can run RDDIMPDP under a different ID - but it will still make noise, particularly in BW systems.

What you can do it give the user only S_tcode = SU53 and s_RFC only SYST. Then you can relax a bit on the application auths it needs necause it cannot start them remotely or via SAPgui. It is just a slave of thf TP program and there you should have change controls anyway.

Cheers,

Julius

[Former Member]

Thanks Julius,

It seems to me this is getting slightly complicated and I like simple solutions. Using the SAP documentation I referred to above, I'd like to do the following:

1. Secure DDIC against misuse by changing the default password in all clients.

2. Lock DDIC and unlock it only when necessary (e.g. for the Basis Team during upgrades).

3. Change all DDIC batch jobs to run as a generic "basis" batch system user-id (e.g. the transport system batch jobs).

I'd prefer to avoid creating new roles in client 000 in every system (and client 000 is not usually on any transport path so it will need to be done in each system).

Is anything going to break using this approach? By the way, our ABAP systems are v7.31

Regards,
Richard.

[Former Member]

Unfortunately there is a special case where the jobstep user is not enough: when the step itself reschedules the job to execute an external program -> in this case the scheduler (which will remain as DDIC from the installation tasks) will again be requested for authorization to see whether the step user can do this.

To avoid such scenarios from XPRA events and adjustments to the RDD* programs, I would recommend not locking the user and leaving it as dialog (so that misuse between release upgrades will trigger a password change - which gives you an additional audit trail...).

Create a global role for DDIC and possibly a BW variant of it and upload it into '000'. Make sure that it does not have any entry points (S_TCODE, S_RFC, S_SERVICE, S_START) so that any interactive attempt with the user (basis will have to be weened of the convenience) forces people to stop using DDIC or defaultng to DDIC if other things dont work.

So you must talk to basis! (as they will "own" DDIC anyway). Particularly in older systems with older habits you cannot just switch it and walk away. If you stick around the helpdesk you might also get to meet some of the management...  🙂

Cheers,

Julius

[Former Member]

Hi Julius,

Thanks. So, it seems locking DDIC may not be so easy to do in practice (despite the "official" SAP recommendation). Instead, I plan to make DDIC a system user. It is a simple change and any attempt to misuse between upgrades will require it to be changed to a dialog user (which will have an audit trail).

Are you aware of any reason why DDIC must remain a Dialog user (between upgrades)?

Regards

Richard.

[Former Member]

What I have done before (without getting into trouble) is to delete DDIC from all clients except '000'.  (Generally I also recommend deleting client '066' completely).

In '000' change the user type to SYSTEM, remove SAP_ALL and deactivate the password...  but do not lock the user! The transport system will execute some programs in the name of DDIC when workbench type transports containing DDIC objects are released or imported.

So it will need a role containing basic minimum authorizations in client '000' of all systems:

S_BTCH_ADM --> Not needed but will appear in the trace.

S_CTS_ADMI = TABL --> Not needed but will appear in the trace.

S_BTCH_JOB -->  action = RELE  & * for group (needed to submit the programs)

S_DATASET with read and write activity to the transport directory from program SAPLSLOG.

S_TRANSPRT actvt 03 for DUMMY object type.

DDIC should also be removed from other periodic jobs such as the stat collectors and certainly from any visible RFC connections. If any of the transport programs RDD* are assigned to an S_PROGRAM authorization group (default not) then you will needto add those as well.

If you activate param auth/rfc_authority_check to value '9' or higher then you will also need to assign authorization for function groups SDMP and STUN.

For SP upgrades we have given it SAP_ALL and SAP_NEW during the maintenance window. Report RDDENQAC also causes some confusion, but does not require additional access. You only need to know the password of DDIC, you don't have to be logged on as DDIC.

The trick is to stop using DDIC first. This is important as DDIC is typically the first user which is attacked when escalation of priviledges is misused.

Cheers,

Julius

[Former Member]

Thanks Julius for the great information sharing.

[Former Member]

Thanks Julius. This is great piece of consulting! and I hope all projects implements these policies from its inception before it's too late 🙂

[Former Member]

Thanks for the information.

We have a lot of discussions on the use of DDIC within the organization especially with the people doing Basis support. Until now we have been able to limit the use of DDIC to specific situations only: maintenance to the transport management system and SP/release upgrades.

It's good to know that during SP/release updates only the password of DDIC is needed, which means we can leave DDIC a SYSTEM user as it is now.

What about maintenance to the transport management system (TMS): is it really necessary to do this with DDIC?

Kind regards

Maaike Duchateau

[Former Member]

Yep, transporting has a lot of organizational aspects to it...  🙂

You do not need DDIC to admin the STMS. Only if the import steps run under DDIC then it will need access to display S_TRANSPRT (check in some FM which reads the headers of the TP), write logs and release the jobs on the event of the transport.

The main bugger are the other jobs running as DDIC and the "external program events" triggered after import. Those can contain application objects and will be dependent on the application being imported...

Keeping DDIC there means you can keep an eye on these events... (a different user ID with SAP_ALL is not a good solution either IMO), but you can remove all TCODES, RFCs, Services and WYDAs from the role for DDIC, then it does have any entry points to the system and the "convenience" use will stop for those who know it's password.

You should do this in all clients of all systems. Upgrading the system should happen by requesting access for DDIC to be able to do it as a part of the procedure. During the upgrade timeframe you will not be able to realistically avoid SAP_ALL.

Cheers,

Julius