There have been quite a few conversations around the ability to actual build such a role and under what circumstances it is valid. Your comment reads like a link only response when the better question would have been "Why do you need such a role"?
If this role is for Production then I would be concerned. I get your point is that you need to obviously restrict access. However, the article your link to without any context does not provide the risks or things to consider. Hence, my comment on this thread.
As the person asking the question has already marked your question as "correct" there is now probably another system out there that will be inadequately restricted and team under the false impression they have followed security guidelines and managed their risk.
In future, if you are going to give such advise in the from of a link only it would be worth providing more context. Your comment implied you were provide the solution and not an example.
@Said Shepal - if you are still following this thread, what do you want a SAP_ALL display role for? I recommend you read the comments in the document linked to you to see the risks as it is not an easy item to achieve (unless you revoke SE* transactions to prevent program execution and go through all of the 80k+ transactions).
firstly, this role for audit team, I know that you are want to secure this role as much as possible, because of this t revoke some transaction SE* to prevent program execution already.
If this is for production and for audit, I highly recommend you design the role like any other end users and obtain requirements. Then drive the role build all through transaction codes.
If you are allowing full display then grant them the end user reporting transactions, audit logs and SE16 (hate to suggest granting this) table access. That should meet their requirements. You don't need to provide a cut down version of SAP_ALL
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.