Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

When Tcode SE16 Removed then Others Tcodes Or Reports Not Working?

Former Member
0 Kudos

I want to remove Tcode SE16 from pfcg for many roles given to end user, but when it is done, then many reports or tcodes not working properly given to end user, getting error, and I also do not want to give SE16 tcode. Though SE16 have only display rights, because of security issues. So is there any way to do it. So that SE16 can be removed and all reports and tcodes also working fine?

5 REPLIES 5

Colleen
Advisor
Advisor
0 Kudos

Hi Tushar

If you have a lot of end user roles with SE16 there is a good chance that this is just the tip of the g iceberg for how your security roles have been built and maintained.

Most likely, when you remove SE16 from your role you are ripping out S_TABU_DIS (or possible S_TABU_NAM). As a result, any other transaction of program that needs to access tables may have been relying on the authorisation.

I make the comment that it's probably the iceberg as it could imply SU24 hasn't been maintained properly or the roles are just a mess.

So, there isn't an easy way. Ultimately, you remove the SE16 (and any other tables) and then spend a heap of time regression testing the roles to figure out what is now failing. On finding the errors, fix the SU24 for those transactions (run STAUTHTRACE and pick up the auth checks) and then continue to clean up the roles as you go

Sometimes it's just easy to start and rebuild the role again

Regards

Colleen

Former Member
0 Kudos

Only logical explanation for me is that you created parameter transactions to start the generated screen programs of SE16 and then activated the optional OSS note to check S_TCODE in the screen already.

Not a well thought out plan. Rather remove the S_TCODE check implemented and use proper parameter transactions for SE16 itself or proper application reporting.

An illogical explanation would be that the transactions hard coded an S_TCODE 'SE16' just for the hell of it but is not needed. Remove it or replace it with a proper check object.

Cheers,

Julius

Former Member
0 Kudos

Hi Tushar,

as Colleen and Julius imply, but may assume too much knowledge needed to understand:

Unless some advanced fiddling/messing - or alternatively some not at all advanced hard coded checks in custom programs causing the issues - has happened in your system, simply taking away SE16 in object S_TCODE can't have the effect described on different transactions.

However, if you take away SE16 and allow the profile generator to make amendments accordingly, then it will most likely change S_TABU_DIS for table access - and possibly some others. If you haven't set up the profile generator to match your requirements in transaction SU24 (which, unfortunately, most customers haven't), then you never ever trust the changes it makes.

Are you fully familiar with the use and impact of SU24? If not, you urgently need training on this before going ahead.

As a quick fix, you can go back to the roles as they were (assuming they weren't documented, refer to the production system, where I hope they haven't been changed yet awaiting successful tests), and then go in with the direct "change" mode to change S_TCODE only without allowing any interference from automated generation.

As suggested by Colleen: if you haven't set up SU24 properly to reflect your requirements, but used automated suggestions without review, your system is probably in quite a state and auditors really understanding it (most don't) would have a field day.

E.G., if you use HR, I would expect quite a few instances of object P_ABAP in your roles most likely opening up rights much further than intended or unneeded instances of P_ORGXX.

good luck with straightening up!

Sven

Message was edited by: Julius von dem Bussche Spelling mistake corrected

0 Kudos

ewwww. sorry for the typo in your name, Colleen!!!

Mobile app doesn't allow change

0 Kudos

I corrected the spelling.

Good point that it might be that removing SE16 from the menu, removed the "overkill" of S_TABU_DIS and that is interfering with the other transactions which prior had been enjoying a "free ride" on the authorizations.

If role concepts have excessive S_TABU* authorizations and the users have gotten used to it and making use of queries and quick viewer and CO-OM tools as a result, then it is very dangerous to make changes to existing roles. Even more so if "edit old status" has been in use or editing the S_TCODE directly (which SAP has now thankfully blocked completely).

Best approach and medium / long term least effort would be to maintain SU24 correctly and then re-implement the roles.

Cheers,

Julius