Question:
Hi all,
I am at a client working on a SOX remediation project. As part of the process of eliminating SOD (segregation of duties) issues from existing roles, we are retesting the roles.
During the testing, we have uncovered several cases where transactions cannot be executed because the called transaction is not in the test user's authorizations. It currently works in production because the authorization is contained in another role assigned to the user. As roles are being tested singly, we are identifying authorization 'gaps.'
I would normally go to OSS to search for this, but I am waiting on the client for access to OSS, so I thought I would come here and put the question to the group.
The client states that in the case of a called transaction, that it is only necessary to give access to the original transaction and that it is not required to grant access to the called transaction and its associated authorization object(s).
An example would be transaction FEBP which calls transaction FB01. In this case, the client claims that it should not be necessary to add S_TCODE, TCD=FB01 to the role in order for the user to be able to execute transaction FEBP. The client states that it is possible and that they have been doing it this way before. When asked for documentation or specific examples, the client could not recall.
I have never heard of this and have never seen or heard of it being done. Historically, when there is a called transaction, I add it manually to S_TCODE. (I don't add it to the menu.) If further authorizations for the called transaction are required, I also add them manually to the role.
My question is this: Has anyone ever heard of this? Does anyone know if it is even possible?
The only possibility *I* can think of (right now) is a user exit from the original program (or include) which would either turn off the authorization check or grant access in that one case. Grant access? Turn off the authorization??? Obviously, that doesn't sit well with a security person.
Any help/input would be greatly appreciated.
_________________
carrie
carrie.barrott@aegisinfosec.com
Answer:
As someone would say: Working as designed.
This is a very good thing.
Any SOX remediation project that is based on transaction code access is dead aborning. You say you are at a client. It sounds like you are a consultant. This is a question we may expect from a new employee who is learning SAP security but this is not what we expect from paid consultants.
If you are an auditor please examine your auditing standards that require competency.
Answer:
Note that some transactions are checked when they are in a call transaction. This is because SAP explicitly added a check before the call transaction. But the SAP default is that transactions invoked by call transaction have no authority check.
You can also read the documentation for SE97 to see how you can modify this behavior.
Answer:
I know that some T-Codes might refer to another, but it only happens when you perform certain actions while executing the assigned T-Code. For instance you will need FB03 in order to display journal entry in FBL3N. This action commonly known as drilldown will trigger the need for FB03. Meanwhile, FBL3N alone don't need FB03 in order to run.
You might need to confirm to your 'client' how they 'use' the T-Codes.
Thanks.
Answer:
As was noted... Working as designed...BUT
You have bigger problems than the S_TCODE check on a transfer to another tcode. If you have a role which does not have all the access needed to perform the functionality implied in a single role but allows it with a combination you have:
1. poorly designed roles
2. Poorly TESTED roles, and
3. Potential for a raft of SOX issues by combining role.
S_TCODE check in higher versions of SAP can be configured woth SE97 to require the tocde to be present or not. IF they do not want the tcode explicetley listed or granted in S_TCODE thenyou have to configure SE97 to Stop the S_TCODE check, other wise you configure SU24 to ADD FB01 to S_TCODE when FEBP is aded to a role.