restrict authorization for function module CALL_TRANSACTION_FROM_TABLE

[former_member209962]

Hi Friends,

We want to restrict function module CALL_TRANSACTION_FROM_TABLE , basically this function module is helping users to by pass the authorization and use any t code they want and we want to restrict this access.

Scenario is user is going to se37 and putting functional module CALL_TRANSACTION_FROM_TABLE and executing it and then put any t code and execute and they can enter in any t code.

Is there any way to restrict function module?

Thanks

Tabrayz

[Former Member]

Are you sure that function is bypassing security? It simply uses the "call transaction" statement to call whatever transaction is listed in the input parameter. "Call transaction" does all the relevant authority checks, doesn't it?

Or am I misunderstanding the problem?

Steve.

[former_member209962]

Dear Steve,

Thanks for your quick reply, yes with the help of this function module it is by passing the authorization which is provided in his/ her role.

Please see below link to understand it more

http://www.saptechnical.com/Tutorials/ABAP/Auth/Index.htm

Thanks

Tabrayz

[Former Member]

That function module does use "call transaction" to run the transaction, and I know that this respects authority checks. What is doesn't do is check for an S_TCODE authorisation for the transaction itself. It may be that you can run, say, ME21N to create a purchase order, but you should not be able to actually save the order without the relevant authorisations for plant, purchasing group, purchasing org, etc. That assumes the transaction you are calling has authority checks in it. If it doesn't...

But, I've looked at two systems I have access to here. An older one (R/3 4.7 - basis release 6.20) behaves exactly as above. A newer one (ERP6 EHP5 - basis release 7.02) has an extra check that the user has authorisation to run the specified transaction. I believe, therefore, that in this case you would not be able to even start the transaction if you didn't have permission.

Which version of NetWeaver are you running? Does this match the behaviour you are seeing?

Steve.

[former_member209962]

Dear Steve,

If user has authorization to run function module mainly for the abapers as they have to  have access to se37 and functional module and it can be miss use like they can do transports by them self without proper approval.

Hence we want to give theM access to run functional module but only restrict call transaction functional module.

I am not talking about end users or business users as they don't have access to run  TCODE se37 or se14.  This is only for ABAPERS .

Our system  is ehp4 on win2008 with oracle 10.2

Thanks

Tabrayz

[Former Member]

So you want to give users the ability to run any FM they like, with the exception of call_transaction_from_table? Is that right? I honestly don't think that's going to solve your problem. There are plenty of other function modules that are going to allow them do undesirable things.

My point still stands, though. "call transaction" respects all the auth objects that the called transaction does. It does not bypass any authority checks. The only problem I can see is that early versions of the call_transaction_from_table did not check the S_TCODE auth object itself. I don't know when that extra check was introduced, but it is certainly in my systems. Look at the source code of call_transaction_from table and see if there's a "call function 'AUTHORITY_CHECK_TCODE'" near the top. I'm guessing that's not present in your systems.

But none of this addresses your fundamental problem. You have ABAP developers that don't respect your rules. You can put as many security checks as you want into the system, but if you have ABAP developers that want to bypass those checks, they will always find a way. Including "back doors" in reports and other custom code is easy to do and you'll only find them with a careful code review of everything before being transported to live.

By all means try to restrict use as much as possible. You should of course do that. But if your developers aren't trustworthy you'll still have a big problem.

[former_member209962]

Dear Steve,

Thanks for explaining in so detail yes I completely agree with you.

But still  i am trying to make it secure and i am not sure till what extent i can achieve this.

So you want to give users the ability to run any FM they like, with the exception of call_transaction_from_table? Is that right?

YES

Please let me know if there is way to achieve it.

Thanks

Tabrayz

[madhankumardham]

Hi Tabrayz,

Please have a look at SAP Note: 1583301. Corrections are given in this note to include Authority check in the function module.

[Former Member]

I don't believe there is a way to achieve it, no. But even if there was, what's to stop a developer from writing their own version with identical source code and calling that instead?

Is this the production system we're talking about? If so, then I suggest the answer is to not allow access to SE37 at all. Just like you should not allow access to SE38, or SA38, or pretty much every other transaction code beginning with 'S' 🙂

Steve.

[Former Member]

That's a pretty obscure note - well found! Yes, that is exactly the difference I was talking about above. My system must have the relevant support pack installed already, and I guess Tabrayz's system doesn't.

However, this still really doesn't address the problem.

Steve.

[Former Member]

Hi Tabrayz,

You can simply put restriction on this FM. Because it is standard SAP FM and they have not even maintained any authorization object for this.

But what I am not convinced is the fact that ABAPERs can move transport using this FM by running t.code se01. Because if you have not given the authorization for se01 or any other transaction to the users ( ABAPERs) then they can not execute it even by using this FM, as this FM is only launching the t.code and nothing else.

If the user can't transport the changes using t.code SE01 then they can not even do that using this FM.

But even if it is creating trouble for you then you can either opt for disabling this FM ( as this FM is of not much significance ), or raise an OSS to SAP to provide some authorization object for this FM .

For disabling the FM you can try using the below approach :

1. By using the SAP GUI, logon to the SAP system.
2. Run the SE16 transaction code.
3. Enter /IBMMON/ITM_CNFG as the table name.
4. To create a new entry, press F5.
5. In the PARM NAME field, enter the name of the SAP function module.
6. In the VALUE CHAR field, enter No.
7. Click Save.

Though I am not very sure it would work as in many new versions this table is not active. So, in worst case raise it to SAP to disable the FM .

Regards

Gaurang

[Former Member]

That table is associated with IBM Tivoli Monitoring. I don't see how that's of any help here.

[former_member209962]

Dear Madhan kumar,

Thanks for your help issue is solved after apply note 1583301

Thanks to all for there valuable comments.

Thanks

Tabrayz

[former_member209962]

Dear Madhan kumar,

Thanks for your help issue is solved after apply note 1583301

Thanks to all for there valuable comments.

Thanks

Tabrayz

[Frank_Buchholz]

The ABAP statement CALL TRANSACTION has a serious security risk by itself as it omity any check for authorization object S_TCODE. We treat it as serious even if all following authority checks within the coding of the transaction are executed. Therefore, SAP is searching for all usage of this statement in SAP programs and adds CALL FUNCTION 'AUTHORITY_CHECK_TCODE'. The result are security notes like the already mentioned note 1583301.

Any ABAP developer has to follow the same rule.

Finally I agree that there should not exist any development activity in non-defelopment systems especially of course not in production systems. This includes the usage of very critical authorization for debug-replace and the authorization to start functions via SE37.

Kind regards

Frank Buchholz