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: 

auth/no_check_in_some_cases set to N?

Former Member
0 Kudos

Good Morning,

I am having a little trouble with finding out if this authorization object should be set to "N" or "Y". Here is the explanation in the AS_ABAP security guide from SAP:

Setting Up Role Maintenance

You must first configure the system so that you can use the role maintenance function in the

Profile Generator tool. To do this, perform the following steps: ...

1. Set the profile parameter auth/no_check_in_some_cases to the value Y.

2. Execute transaction SU25.

The transaction Profile Generator: Upgrade and First Installation (SU25) copies the proposals for

check indicators and authorization field values delivered by SAP to the customer tables, which

you can then change.

You can then use the role maintenance functions and the Profile Generator to manage the

authorization information for your users.

Is this for Development since that is where you do role maintenance? Should this be set to N in Production? I am having trouble getting to notes right now and I have read about note 416016 but have not read it yet. By setting this to N will it not do any authorization checks? or will it just not bring items in from SU24/SU25 (USOBT_C) when generating a profile (which should not be done in PRD anyway).

Thanks in advance for any assistance.

Kind Regards,

Paul

1 ACCEPTED SOLUTION

Former Member
0 Kudos

It will prevent the system from using "no check" indicators.

It is sometimes the case that transactions or functions are re-used with certain parameters (otherwise you would need to code the whole lot redundantly again...) but it might not be desirable that the user be able to start the transaction directly, maintain all the initial screen values themselves... or be able to complete the function unless it is from a specific calling context which you can control and want the user to be able to use it in those cases.

So it is possible to skip some of the checks but only IF the calling transaction has been setup for it - i.e. maintained in SU24 with a no check indicator, or disabling the check in SE97.

Can be very usefull, but also a bit dangerous if used carelessly.

Cheers,

Julius

4 REPLIES 4

Former Member
0 Kudos

It will prevent the system from using "no check" indicators.

It is sometimes the case that transactions or functions are re-used with certain parameters (otherwise you would need to code the whole lot redundantly again...) but it might not be desirable that the user be able to start the transaction directly, maintain all the initial screen values themselves... or be able to complete the function unless it is from a specific calling context which you can control and want the user to be able to use it in those cases.

So it is possible to skip some of the checks but only IF the calling transaction has been setup for it - i.e. maintained in SU24 with a no check indicator, or disabling the check in SE97.

Can be very usefull, but also a bit dangerous if used carelessly.

Cheers,

Julius

0 Kudos

First let me say Thank you for such a quick responce.

Let me take a moment to repeat what you are saying to make sure that I understand you correctly. You are syaing that by setting it to N it will prevent the system from using the "no check" indicator in SU24/25. If SU24/25 is managed correctly, setting this to N can be very usful. Also will setting this to N protect the system better if SU24/25 is maintained correctly?

Please let me know if I understand you correctly and thank you again for sharing your knowledge with me.

Regards,

Paul

0 Kudos

Check the sticky thread at the top of the forum - and search for other discussions on "SU24 no check" as well. They should cover the topic quite well, a few times already...

> Let me take a moment to repeat what you are saying to make sure that I understand you correctly. You are syaing that by setting it to N it will prevent the system from using the "no check" indicator in SU24/25. If SU24/25 is managed correctly, setting this to N can be very usful. Also will setting this to N protect the system better if SU24/25 is maintained correctly?

"N" will (suddenly) turn a whole load of checks on, which you might not want. You then also cannot use this feature in correct cases where you do want to use it, or the system already expects it.

You should keep the settings the same in all your systems. The default is "Y" (=> "no check" is permitted) but needs to be activated in Su24 for specific use cases in your concept, or the suppressed check disabled again (move to "Check" or "Propose") if the default values don't meet the requirements of your concept.

Particularly if you don't have a well documented and closely managed concept (no offence, but it can happen) then I don't recommend changing the defaults.

Read the note you mentioned and others on "Su24", and the documentation in tcode RZ11 and the application help of PFCG, then it should be clear.

Cheers,

Julius

0 Kudos

Julius,

Thanks you for your assistance. This does help clear things up. I do understand SU24 and what/how it is used... I was just having trouble grasping the use of that profile parameter.

Thank you again for your assistnace.

Regards,

Paul