Restricting SM30 via auth. groups, any flaws in thinking?

[Former Member]

Hi,

I got a request to assign SM30 to a role as table J_1IEWT_ACKN_N needs to be maintained monthly. I checked an earlier thread regarding this table, and in this case maintaining table in DEV + transport is also not accepted.

This role also includes other table maintenance activities (period opening/closing, exchange rate maintenance), but for these SM30 is not required. As this role would now include SM30, it would possibly grant access to quite a bunch of tables (through S_TABU_DIS, DICBERCLS values KC and FC31). User with this role would not have any other roles.

I created a Zxxx-authorization group in SE54, assigned it to the J-table and then included this auth group to S_TABU_DIS object.

As this role only needs access to a few tables, I was thinking of changing the authorization group assignments of these tables from KC/FC31 to Zxxx and then giving only DICBERCLS value Zxxx to the role.

Does this sound like a reasonable solution? Can I just change the auth group assignments of the tables in SE54 or does this have any consequences that should be acknowledged and that I'm not aware of?

[Former Member]

Hi,

The users will still be able to view/maintain tables for the auth groups that they pick up through other uses of S_TABU_DIS.

What I would recommend is that you get a developer to assign the view to a custom transaction and assign that to the role, getting rid of any need for SM30 to be assigned.

[Former Member]

Hi,

I think what Alex proposes of a custom transaction is a very good idea. Personally i would never advise anyone to change the default authorization groups set by SAP. If you change the authorization group of a table from FC31 to ZXXX, it could solve your problem but it might impact someother table/program.

Go to se38 , RS_ABAP_SOURCE_SCAN and enter S_TABU_DIS; FC31. you would get a list of programs that use this authorization group, when you change the authorization groups all the listed programs would NOT consider your table for sure

[Former Member]

Hi,

Custom t-code is now created and works fine. I'll leave the original auth. group (&NC&) in place and add &NC& to DICBERCLS.

Thanks for helpful replies.

[Former Member]

> Custom t-code is now created and works fine. I'll leave the original auth. group (&NC&) in place and add &NC& to DICBERCLS.

This is not a "best practice" approach. &NC& means "not classified" and includes all tables which do not have an authorization group at all, or &NC& as value in the view.

If you are going to use a view, then classify it and grant only that value.

This is safer than expecting the user only to use the one transaction and not being able to "break out" of it's restraints.

Cheers,

Julius

[Former Member]

If you are going to use a view, then classify it and grant only that value.

If I understood correctly, "classifying" means that I should find a proper auth. group for the table instead of &NC&.

I browsed through the groups, but couldn't really determine what would be suitable one (if any).

Would it be even close to good practice to use the Zxxx auth group that I've created and to assign that to the table? Or is it better to stick with the existing ones?

[Former Member]

You should try to find an existing group which contains data with the same classification as this one, and use SE54 to assign the value to it. Possibly, if the correct set of users are already classified for that group then you don't need to change anything inthe roles.

If nothing which already exists matches the classification of the data, then classify it yourself by creating the Zxxx group and assign it via Se54.

If Z-groups already exist, as for the documentation on the concept so that the one you create or use is conform with the intended concept and naming conventions.

There is nothing wrong with a Z-table authorization group.

Cheers,

Julius