Z_PROGRAM does not run with SAP_ALL

[Former Member]

Hi All,

System: ECC 6.0

I have a test ID with SAP_ALL and SAP_NEW authorizations, but I am not not able to execute a Z Program with this Test ID, but other users can.

Compared other users UMR with this Test ID and they match up 100%.

All the related auth. Objects checked and they have *

Your suggestions will be help full.

Thanks

Vidyar

Also I created a role with SE38 with full authorization and assigned the role to the Test ID, but still it does say that " You are not authorized to use the program "

Edited by: VIDYAR on Jan 18, 2011 7:11 PM

Edited by: VIDYAR on Jan 18, 2011 7:11 PM

Edited by: Julius Bussche on Jan 19, 2011 8:12 AM

Subject title made more meaningful

[Former Member]

Z programs are not automatically included in SAP_ALL. They are definitely not part of the SAP delivered SAP_NEW profile. There are multiple ways to include Z programs in your SAP_ALL profile. Assuming that the Z program is not using a custom authorization object, some people will wild card Y and Z programs and transactions in the SAP_ALL profile through SU02 maintenance. Others will regenerate SAP_ALL periodically to pick up new transactions and authorization objects. One method is to update SAP_ALL by executing RSUSR406. At some point auditors may ask you why you are even assigining SAP_ALL. If you need to find out where the process is failing you can perform a trace with ST01 or review the users buffer with SU56. If other Z programs existed when SAP_ALL was last generated, they would be included, but any custom program created after this was generated will be missing. Depending on the authority checks within the custom program, if a trace does not completely answer your questions, you can work with a developer to perform a trace.

[Former Member]

Hi Greg,

1. Thank you for replying.

2. Even though if the SAP_ALL is not generated after the Z program was included, it should work with SE38 when I use the specific Z program name under the respective field of object S_PROGRAM. Which It is not. So a little confused.

3. I had traced before but did not mention earlier. The trace comes back with RC=0 succesful authorization, also SU53 says successful.

4. As per the SAP_ALL assignment it is not on the Golden client path, so it is O.K. with the audit.

Thanks

Vidyar

[Former Member]

9 times out of 10 such a mysterious message has nothing to do with the authorization concept of authority-check statements and you anyway cannot control the execution of a program based on it' name.

Display the code in SE38 and search for ABAP statement constructs using system field "sy-uname". For example:

if sy-uname NE ('cappsg' AND 'busschej').
exit with message xxx using 'You are not authorized'.
endif.

or

data: iv_uname type xubname.

iv_uname = sy-uname.

select single * from ZUSR_AUTH_TABLE where 
zname = iv_uname.

if sy-subrc 0.

exit with message xxx using 'You are not authorized'.
endif.

Then look in the table ZUSR_AUTH_TABLE for the lists of authorized users and where it's maintenance dialog is.

Terrible concept, very bad practice but unfortunately it happens - particularly when developers are not given security requirements or have little faith in the existing authorization based implementation in roles.

Can be a mess to fix as well. Good luck.

Cheers,

Julius

[arpan_paik]

Dear Julius,

Good piece of info. I have seen 2nd type of issue once. However our developer was bit fair with security people so for exception the message was with corresponding table name. results not so trouble indentifying the problem.

Just based on curiocity, does this consept used in workflow to set possible agent?

Regards,

Arpan Paik

[Former Member]

Hi Julius,

You are right, I got it.

Thak you for the response I really appritiate it.

It is the 1st type of the issue you mentioned.

thank you for the help again.

Thanks

Vidyar.

Edited by: VIDYAR on Jan 18, 2011 8:26 PM

[Former Member]

To base a user name specific check on application data is not unusual nor new.

Purchase requisition approvals, transport owners, sensitive field checks if FI master data, etc. However these have a status dependency (typically "open") after which they time out.

A user entered into user name "check tables" such as these do not expire with the application data status being completed, and if there is no other check in the code then anyone can run it (even if you delete their user ID with an extra commit...

It is a very bad sign of confidence to find this in your code, but is popular as a lowbrainer way of defering authorization management to some business department without having to open up PFCG to them and your development system.

Note: Programs are client independent (except for queries) but these tables are mostly client-dependent "in the wild".

Lets wait for the OP to get back to us. Perhaps the select statement is client specified...

Cheers,

Julius

[Former Member]

It is the 1st type of the issue you mentioned

This was historically done for some quick-fix programs. Still bad...

The better ones added a sy-datum field check in addition.

Please open the thread again because I only provided a diagnostic of the problem. You still need to solve it....

Cheers,

Julius

[arpan_paik]

 Please open the thread again because I only provided a diagnostic of the problem. You still need to solve it....  

Looking for worm, turned out to be cobra!

[Former Member]

Hello Julius,

I agree that the program needs a fix, This program was written about 6 to 7 years before and modified as and when required.

My objective is to move over to PFCG rather than the Z-program.

I would hold on until I get a feed back from the ABAP team.

Thanks

Vidyar

[Former Member]

Good for you. Well done!