SA38 access restriction

[Former Member]

Hello,

I am currently working on trying to restrict access to SA38 for Basis in a Production environment. At the moment they have S_Program with a * for access. I would like to shave that down and remove the HR and FI programs. Is there a simple way to do this that I am not aware of? is there a naming convention for FI and HR Programs that I can key in on to remove them from S_Program?

I understand that in most cases SA38/SE38 should not be allowed in Production. But at the moment we are unable to make that happen so we are trying our best to limit the risk by removing FI and HR programs. Any help would be greatly appreciated.

Regards,

Paul

[Former Member]

Hi Paul,

S_PROGRAM should allow you to restrict access based on the authorisation groups that the programs are assigned to, which you can check in table TRDIR - if the programs you are concered with are assigned to one of these authorisation groups, you can ensure that you do not allocate access to the restricted groups within the object for the role.

Finance programs may have an auth group assigned of F* (following standard naming convention) but many programs do not have an auth group assigned by default.

If the programs are not conveniently grouped, you can assign a program to an authorisation group via program RSCSAUTH amd create custom groups if required.

Hope this helps,

Tom.

[Former Member]

The security on executable programs is on the authorization group maintained for the program. We use a convention where all custom programs use a prgram typical of their funcationa area and subarea. A program looking up payroll data would have authgroup of the form ZHPY????.

All SAP programs/reports do not have auth groups so this is will not work for security SAP delivered reports. However, most programs use a second level of check with through code using the authority-check statement. So S_PROGRAM will only allow you to get to the initial screen of the report but not allow you to return data for it.

[sreekanth_sunkara]

Hi Paul,

Instead of restricting Basis team from FI and HR, identify the programs they are going to use and allow them to only that programs by putting them in a auth group

thanks,

SSS

[Former Member]

First let me say thank you to everyone who has responded. I appreciate your responses and suggestions. Currently our policy here is that we do not use authorization groups. I personally do not feel that to be the best policy but it is what we have to deal with. I believe that we will push back and take SA38 away, allowing them only to run SA38 through a firefighter user.

Once again thanks for all your assistance.

Paul

[Former Member]

With transaction SE38 you can restrict access to a specific report by using authorization S_DEVELOP and authorization field OBJNAME. With a trace (ST01) you can check which DEVCLASS and which OBJTYPE is necessary for this report. ACTVT is restricted on 03, so the report (and only this report filled in OBJNAME!) can be viewed and executed.

Regards,

Julia

[Former Member]

Please note that there is an important difference between executing a report object from the workbench tools (S_DEVELOP) and merely submitting the report name from a reporting tool, menu, jobstep, report transaction or another program (S_PROGRAM).

Cheers,

Julius

[Former Member]

But in both ways the user can only execute this specified report, if ACTVT is restricted to 03.

I don't understand why this way should be not as good as the way with SA38 and authorization groups.

Regards,

Julia

[Former Member]

> But in both ways the user can only execute this specified report, if ACTVT is restricted to 03.

I assume you mean S_DEVELOP actvt 03 -> This is not true.

It means that you can execute it from the workbench test environment (-> F8 on the keyboard) as well. No specific tcode is required for that...

However, you would normally execute reports from a report tree or a report transaction. You should not assign S_DEVELOP to those users... they do not need it.

S_PROGRAM works for both scenarios.

Cheers,

Julius

[Former Member]

Yes, I meant S_DEVELOP actvt 03. I created a role with transaction SE38. In authorizations I disabled (inactivated) all authorization objects, just S_DEVELOP I filled with the required reportames (DEVCLASS, OBJNAME) and ACTVT 03.

The user with this role can only execute the specified report, no other reports.

So what do you mean with "from the workbench test environment"? The report works normally.

Of course, if authorizations are given by SE38 or SA38, no other authorization objects are checked (e.g. no authorization for plant or something like that is checked). I thought, the only difference between SE38 and SA38 is that in SA38 there is a need to group the reports in authorizations groups. With SE38 I don't have to, I just take the report.

Regards,

Julia

[Former Member]

No, the user can bypass this OBJNAME check via the menus. For example Shift + F6 (with variant) or Shift + F7 (via variant list).

Additionally, instead of executing the report (F8 on the keyboard is the single-test button) the user can now also choose F7 (display the source code and attributes). Take a look at all the new menu options which are available now....

Shift + F5 is one of the more popular ones, as is the where-used-list navigation.

It is certainly not a good idea for normal users to be able to "disappear" into the code like this...

I think it would be much easier to create a transaction for it than fish around for report names which are still not a substibute for S_PROGRAM and correct checks in the code.

Cheers,

Julius

[Former Member]

Ok, thank you very much for these informations - I didn't knew this.

I checked with my role - the possibilities with ShiftF6 and ShiftF7 are given, the other possibilities don't work (F7 or Shift+F5).

So, you're right and I have to look for another option - perhaps using SA38 with authorization groups...

Thanks,

Regards,

Julia

[Former Member]

Or a report tree, or report type transaction... This is generally accepted as the easiest way to achieve sufficient security.

Cheers,

Julius

[Former Member]

Hi Paul,

As you are unable to use authorisation groups to secure this access, you may want to consider the creation of custom transactions to secure the access, which you can then secure through S_TCODE. If you ensure that the front screen is bypassed, you should be able to ensure that no other programs are accessed via SA38 and ensure only the ones your teams reaquire are available.

Hope this helps,

Tom.

[Former Member]

> I understand that in most cases SA38/SE38 should not be allowed in Production. But at the moment we are unable to make that happen so we are trying our best to limit the risk by removing FI and HR programs.

I would concentrate efforts on application authorization objects, and not the ability to start the reports.

Reports with authorization groups often perform "blunt" checks for full authority (*) because this is an equally un-granular approach or are used to protect the variants and this should be application support (see transaction VARCH for a better option!).

Unfortunately, some reports make no checks and rely only on the authorization group, but these are less of a risk than those without any authorization group or selection screen in my opinion.

The best place for consistent checks are always in the code which actually does something.... those you can rely on.

Cheers,

Julius

[Former Member]

Hi Paul,

You can lock a transaction so that it cannot be accessed at all in the system. There are various ways to do tha:

- Use R3trans and tp utilities with tp unlock and tp lock at the operating system.

- Use transaction SM01 to find the transaction and lock.

good luck

Rasheed

[Former Member]

Do you think locking SA38 is going to prevent people from submitting reports?

Imagine if that did work...

Cheers,

Julius