Skip to Content
-1

Can a user with access to SE38 & SE80 make changes to programs or objects?

Jan 22 at 10:27 PM

470

avatar image
Former Member

my audit is asking me to remove users (developers in DEV environment) with access to SE38 and SE80. The client is closed (no changes allowed) and they don't have the developer key or DEVACCESS.

Can they create, modify or delete programs, objects etc. using these t-code based on the above scenario?

10 |10000 characters needed characters left characters exceeded

Google "SE38 in production site:sap.com" finds 6600 hits and the top one is almost the same exact question, so why are we having this conversation again? I'm confused...

1
* Please Login or Register to Answer, Follow or Comment.

6 Answers

Best Answer
avatar image
Former Member Jan 26 at 12:14 AM
-1

If you want to change any programs or objects, the below conditions need to met.

1. Users should have access on S_Develop activity 01 and 02 and other fields and field values as per requirement

2. Those users (mainly abap developers) should have developer key

3. The client should be opened for cross client changes as these programs and objects are cross client objects.

Share
10 |10000 characters needed characters left characters exceeded
Matthew Billingham
Jan 23 at 06:17 AM
2

In order to support prod, developers must have these transactions. However, the auditors often feel that it's safe to remove them - a sort of belts and braces approach. They reason that if these tx are removed, then should the system be opened, no-one will be able to make changes directly in prod. What you should do is ensure the support developers' roles do not allow change or create access within S_DEVELOP. Blocking transactions is wrong.

I've seen this before with auditors. They've locked SE80 and SE38. But SE24 is still available, which gives you all the access you need... ;-)

Show 2 Share
10 |10000 characters needed characters left characters exceeded

SE37 is also a nice "gateway". :)

0

Or even getting to the source code via ST22!

1
Jurjen Heeck Jan 23 at 08:49 AM
1

I see several mentions of DEVACCESS and/or developer keys. This isn't required anymore in S/4HANA.

S_DEVELOP authorizations are the only proper way of securing this, as Matthew stated in earlier comment.

Share
10 |10000 characters needed characters left characters exceeded
Joshua Bennett Feb 23 at 04:09 PM
1

Jurjen appears to be correct re: that a developer key is no longer required for maintenance of development objects in S/4HANA, as it is in SAP Business Suite systems like ECC, SRM, CRM, etc. I corroborated this in a Sandbox system, and also found supporting SAP note:

  • SAP Note 2309060 - The SSCR license key procedure is not supported in SAP S/4 HANA

This also appears to similarly apply to object keys in S/4HANA, which are issued for standard SAP developed repository objects delivered in SAP Business Suite systems like ECC as an additional prerequisite that would be required in order to maintain such objects.

Aftab - as a few mentioned above, there are still several conditions which must be simultaneously met in order for changes like those referenced in your original question to be permitted (though there was a few considerations which are not yet mentioned above that I include in the detail below). However, your original question specifically referenced "programs and objects". While we know programs are repository objects and thus cross-client by nature, when discussing the changeability of "objects", it is important to distinguish between client-independent and client-dependent customizing objects:

Changeability Requirements for Client-Independent Customizing and Repository Objects

User-Specific Requirements

  • User is authorized for changes to cross-client customizing or repository objects, depending on the change being made (i.e., authorization requirements will slightly vary depending on how the change is initiated and what exactly is being changed, but generally requires S_TABU_DIS / S_TABU_NAM / S_TABU_CLI authorizations at a minimum for client independent customizing objects, or S_DEVELOP / S_TRANSPRT authorizations at a minimum for repository objects)
  • For certain custom repository object maintenance activities (e.g., creation / change of custom ABAP programs), the User must have a registered developer key issued by SAP for their specific user master record (i.e., table DEVACCESS), as applicable to respective system according to installation number (note: as confirmed above, this requirement only applies to SAP Business Suite systems like ECC, but is not required for S/4HANA)*

Client and System-Specific Requirements

  • Client protection for cross-client customizing objects (i.e., table T000, field CCNOCLIIND) is set to '1' (No changes to cross-client customizing objects, but changes to repository objects allowed), '2' (No changes to repository objects, but changes to cross-client customizing objects allowed), or blank (Changes to both cross-client customizing and repository objects allowed), depending on the change being made
  • System Change Option set through SE03 / SE06 (i.e., table TADIR, field PGMID = HEAD, field OBJECT = SYST) is set to 'Modifiable' (TADIR-EDTFLAG = 'X')**
  • For certain standard repository object maintenance activities (e.g., changes to standard ABAP programs), the object being changed must have a registered object key issued by SAP for the specific repository object (i.e., table ADIRACCESS). (Note: as confirmed above, this requirement only applies to SAP Business Suite systems like ECC, but is not required for S/4HANA)*

*For SAP Business Suite systems where SSCR keys are applicable, note that certain repository object maintenance activities such as creation / change of ABAP programs require the user making the change to have a developer key (and potentially an object key, if the program is standard), while other repository object maintenance activities such as data dictionary changes to a table's technical settings (e.g., table logging flag in SE13) do not require a developer / object key.

**Note that the System Change Option also includes modifiability settings by software component and namespace as well. Each of these dimensions as they relate to the object being changed need to be set to 'Modifiable' in order for the "System Change Option" changeability condition to be met (i.e., even if the global System Change Option is set to 'Modifiable', if the Software Component and / or Namespace corresponding to the object being changed is set to 'Not Modifiable', SAP will not allow the change - see the following link for additional detail: https://help.sap.com/viewer/4a368c163b08418890a406d413933ba7/7.5.5/en-US/5738de9b4eb711d182bf0000e829fbfe.html)

Changeability Requirements for Client-Dependent Customizing Objects

User-Specific Requirements

  • User is authorized for changes to client-dependent customizing objects (i.e., authorization requirements will slightly vary depending on how the change is initiated and what exactly is being changed, but generally requires S_TABU_DIS / S_TABU_NAM authorizations at a minimum, and S_TRANSPRT authorizations if a transport request is simultaneously created as a record of the change, which is not necessarily required depending on the corresponding setting in table T000 as noted below)

Client-Specific Requirements

  • Protection for client-dependent customizing objects (i.e., table T000, field CCCORACTIV) is set to '1' (Automatically record changes in transport request), '3' (Allow change, transport request cannot be generated), or blank (Allow change, transport request possible but not required)

*Note that the System Change Option described above does not apply to client-dependent customizing objects. Also, keep in mind that client-dependent customizing objects which belong to "Current Settings" (i.e., table OBJH, field CURSETTING set to 'X') can be changed in clients with the Productive role (i.e., table T000, field CCCATEGORY set to "P") by authorized users, irrespective of the CCCORACTIV protection settings noted above (i.e., can be changed by authorized users even with T000-CCCORACTIVE = '2' for "No changes allowed.").

Hope this helps!

Josh

Share
10 |10000 characters needed characters left characters exceeded
Vinita Kasliwal Jan 23 at 12:19 AM
-1

SE38 and SE80 can have different kind of access View, Run reports and make changes

by default if its not restricted for the users everyone has access to view things in Se38 and Se80 if you have a developer access key assigned to your User Id in the system you can change all objects with Z* and Y*

Let me know if that answers your question.


Regards

Vinita

Show 7 Share
10 |10000 characters needed characters left characters exceeded
Former Member

So can i make changes ANY direct change (ABAP or otherwise) to the system using SE38 and SE80?

Taking into account that the system is set to "no changes allowed" and the developer have DEVACCESS is development (not in production)

0

Hi Aftab

If the system is set to no changes allowed which generally happens in a prod env then you woudl not be able to make any changes anywhere which includes changes in Custom table or config or programs.

This happens via SCC4 to " no changes allowed"

Read more in the link here

https://archive.sap.com/discussions/thread/749821

Let me know if that helps
Regards

Vinita

1
Former Member

So why would auditors want developers access to se38 and se80 removed or call it finding. (These developer do not have DEVACCESS in PROD and the client set to "no changes allowed". Whats the point ?

0

Hi Aftab

Most of the times the reason why auditors would want to Remove access to SE80 and SE38 as well as using SE37 is because they are capable of updating the tables in the system by running the reports .

even if the user does not have the actual access to the Transaction there are standard SAP reports which can modify the entries in the table from backend. So this should NOT be provided to all

Ideally if you still need to run a report in production it should be assigned to a Tcode which should then be run

let me know if that answers you question

Regards

vinita

0

You can remove execution access via ACTVT. There's no need to remove access to viewing source code.

0
Former Member
Vinita Kasliwal

Hi Aftab,

Basically it's a process to check the database consistency I was part of EWM project where they use to take audit process for the warehouse and checks all the details from the materials present in the warehouse to how much are in replenishment area and how much has been processed.

Lets say while checking the database someone creates an outbound delivery so the entire data for the material will be revised which will be far different from what auditors are expecting.

So that's why we try to remove all developer access authorizations during audit process and as Vinita said we follow the same process which she mentioned above.

Thanks,

Madhur.

0
Former Member

Hi Matthew,

Could you please elaborate your answer actually I will be performing this activity so if you could provide some more knowledge on the same.

Thanks,

Madhur.

0
Gerrit Beukema Jan 22 at 10:39 PM
0

they don't have the developer key

Then they will not be able to create/edit/delete development objects like programs etc.

Share
10 |10000 characters needed characters left characters exceeded