Autho. on program and tables

[Former Member]

Hi All,

I have 2 question

1. Is there any way to stop user from direct processing of programs.eg. There are many users who do not have access to SE38 to run any program, but they found a wayaround. They logon to R/3> System> Status> Double click on Programs> it takes you to the source code of the program--> Other Object and then can run any program --> And then Direct Processing....

Is there any way to stop this and how. Please give me the steps and I am new to Autho.

2. I have to give access to some users for some tables in transaction SM31. But only few tables?? ( might be Z tables also). Is there any way to give on access to sm31 and only mentioned table?

Your reply is appreciated.

Thanks

Prash

[Former Member]

For the programs, remove object S_DEVELOP, activity 03 (this is what is neded to perform the "workaround" you mention). Assign all programs to t-codes, give the users access to execute those transactions, and take away S_DEVELOP altogether. Should work.

As for tables, these should always be assigned to authorization groups (from the table maintenance, go to Utilities->Table maintenance generator). Assign an auth group and limit this in S_TABU_DIS.

Regards,

Trond

Message was edited by:

Trond Stroemme

[Former Member]

For nr 1 please check if there are roles with TRX SE38 and or SA38 assigned to users. Take that access away! And as already mentioned do not allow users to have access to S_DEVELOP and S_PROGRAM with value * in any field. In any role were you find these pls check which TRX brings this in and with what values, never assign more than SU24 describes.

For Nr 2 NEVER allow access to SM30/31 to end users in a production environment, Consult your functional experts, as there will always be a “NORMAL” Transaction that allows the data to be updated. When changing data with Sm30/31 all consistency checks are bypassed. Which will lead to corrupted data in your system!

[Former Member]

one additional remark, for the TRX access also check for roles were S_TCODE Is set to * this also should be strictly forbidden and the other option that is mostly overlooked when in the object S_TCODE access is given to a range that is to wide or wrongly filled in thus allowing wide access.

[Former Member]

Hello Prasanth,

for point1 - to Stop:

R/3> System> Status> Double click on Programs> it takes you to the source code of the program--> Other Object and then can run any program --> And then Direct Processing....

from happening...

You have to: see that the following is resticted in your developer roles.

Object - S_DEVELOP

activity 03

DEVCLASS- SESS

OBJNAME - SMTR_NAVIGATION

OBJTYPE - FUGR

for the second... i'll let u know ASAP.

points are welcomed.

Regards,

Srihari

[Former Member]

Hi Sir,

There are end users too, who can do that( pt 1). How do I block them. Can I create a role which denies the permission and assign to all the users? I dont know that.....

Please suggest how to go abt it, Also pls tell me the steps to follow. What you have given is very good, but I could not understand much out of it.

Prash

[Former Member]

Hi Prash,

For a quick-win on the first question, you can apply SAP note 1085326.

The advise from Trond above is still the best answer though.

Cheers,

Julius

[Former Member]

Hi Srihari,

Thanks for the first answer, it got resolved. But the SM31 and giving access to few of the table still remains.

Regards

Prashant

[Former Member]

Hey Prashant,

See my post on - Nov 15, 2007.

you need to create a role and restict the object S_TABU_DIS to display.

1. Goto SE54, create an Authorization group and include all your tables(Ztables).

2. create a new role with trx's... (SM30,SM31 etc)

3. the object S_TABU_DIS, should have ACTVT 03, DICBERCLS - your new authorization group as created via SE54.

4. Save the role and generate and assign it to the users.

Note: it is always preferred not to give SM30/SM31 access to end users in prod system. also make sure that the object S_TABU_CLI has the field CLIIDMAINT - ' ' (not allowed)

points are welcome!!

Regards,

Srihari

[Former Member]

Hi Sri,

I am not clear with the SE54 trx to create authorization group. Because already some std object is present ( for eg. T_BAST ) and how to assign tables to it.

Can you please suggest the steps to follow( novice in dealing with objects ).

Thanks

Prashant

[Former Member]

SAP already has a lot of standard authorization groups available for tables. These can be seen in SE54 trx or in the table TBRG for object S_TABU_DIS. The asociation between the auth group and the tables can be seen in table TDDAT. An example of such an association would be table T000 linked to auth group SS. So if you want to restrict people from changing/creating clients, remove the access for group SS from the S_TABU_DIS object in their roles.

Now if you want to allow a user access to only some new Z-tables then the procedure would be -

1. create a new auth group for S_TABU_DIS via SE54.

2. modify table TDDAT to associate the required Z-tables to the Z-auth group.

3. create a new role with SM30/31 and the object S_TABU_DIS and only add the new Z-auth group in field DICBERCLS.

4. assign the role to the concerned user. (remember to remove other roles giving access to this object from the user first).

For SE38, there can be two type of control - program display (code) access via S_DEVELOP and execution access via S_PROGRAM.

S_PROGRAM control works on a principle similar to S_TABU_DIS.

The field P_GROUP contains auth group values for programs which are maintained in the table TPGP.

The association between the program and the program group can be maintained using the program RSCSAUTH. (this maintains the table SREPOATH).

Hope this helps. Please award appropriate points.

Regards,

Sanju.

[Former Member]

Hi Prashant,

For Point 2:

You need to create an Authorization Group for table maintenance (SE54) and include all the list of tables u want to restrict the access. Then in S_TABU_DIS, for the field DICBERCLS add this group with activity 03.

By this way the users can have display access only to view those tables which are associated with the Authorization group (in this case, your new Auth.grp)

Regards,

Srihari