Authorization Check

[Former Member]

Hi,

Can you please tell me in detail, how does the check is carried out for an authorization object with the check flag value ' only check '?

Thanks in advance.

Regards,

Sachhidanand

[Former Member]

Hi,

Take a carefull read through this thread:

Particularly the closing statements from Frank Buchholz about "Check" indicating that there is a navigation possibility in the transaction, however the authorization required to use it should come from a different transaction (with "Check/maintain") if that navigation option is desired.

=> "Check only" does nothing. It is information only.

Cheers,

Julius

[Former Member]

Hi Julius,

Thanks for your reply.

In my project, S_RZL_ADM has the check flag value' x '( ie ' check only ' ) with respect to SM36 in USOBX, as well as USOBX_C. Now, the access to S_RZL_ADM with ACTVT=01 is required if a person wants to include an external command/ program in a background job as a step- one of the major functionalities provided by SM36. So I think, we can't say authorization objects with the check flag value' x ' are generally related to the minor functionalities provided by a transaction.

Second thing, I am doubtful about what you are saying( The access for the authorization objects with the check flag value' x ' should come from the transactions, where these authorization objects have the check flag value' y ' ie' check & maintain '. ). The reason is, I have created a test user in the same system( which I am referring in the above paragraph ) & assigned a test role, which contains only SM36 in the menu. I haven't added S_RZL_ADM in the authorization data by any means. And still the user is able to include external commands. In addition to this, I checked the program for SM36, it contains the check for S_RZL_ADM.

Can you please provide me your views on this?

Thanks in advance.

Regards,

Sachhidanand

[Former Member]

>

>Now, the access to S_RZL_ADM with ACTVT=01 is required if a person wants to include an external command/ program in a background job as a step- one of the major functionalities provided by SM36. So I think, we can't say authorization objects with the check flag value' x ' are generally related to the minor functionalities provided by a transaction.

That is a rare occurance. Realistically very few activities require access to run an external command (I hope you have tightly secured S_LOG_COM). There are always exceptions but in general......

[Former Member]

Hi Sachhidanand,

My view is that you do not have to schedule an external command in a job step (you can also schedule a program => object S_PROGRAM), so you do not have to add S_RZL_ADM to the user's authority, so why should SU24 automatically pull it in?

Regarding your second observation, this is most likely because you (the scheduler) have S_BTCH_ADM = 'Y' authority. Try to release it and see whether the step does infact execute the command (or fails due to missing authority)?

Cheers,

Julius

[Former Member]

Hi Alex,

I think, this is not a rare occurence. The program for SM36 makes it mandatory that, the user( who wants to include an external command/ program in a backgrond job as a step ) should have access to S_RZL_ADM with ACTVT=01.

And as you are telling, S_LOG_COM is related to the execution of an external command/ program.

Regards,

Sachhidanand

[Former Member]

Hi Sachhidanand

We will have to agree to disagree. Scheduling a job which runs an external OS command is a rare occurance in my book when considered within the context of the usual jobs which are scheduled. Furthermore this activity is typically performed by people who would already have these authorisations and inherit this auth object. S_RZL_ADM is certainly not an authorisation you would want to give as default to the majority of people with SM36.

Cheers

Alex

[Former Member]

Hi Julius,

Sometimes( might be rarely ) it is required to include an external command/ program in a background job. So S_RZL_ADM is important.

Regarding the second observation, that test user( scheduler ) does not have S_BTCH_ADM with BTCADMIN=Y. Sorry, I forgot to mention in this my previous message. And I checked,

the test user is able to release a job containing an external command.

Regards,

Sachhidanand

[Former Member]

Hi Alex,

As you are telling, the inclusion of an external command/ program in a background job might be rare. I wanted to tell, the check for S_RZL_ADM with ACTVT=01 is not rare. Means whenever a person tries to include an external command/ program in a background job, this check takes place, provided the check flag value has not been changed from' check only '( SAP proposal ) to' do not check ' & the program for SM36 has not been changed.

Regards,

Sachhidanand

[Former Member]

Hi Sachhidanand,

If all your users with access to SM36 are also (intendedly) to have S_RZL_ADM authorizations, then you could add S_RZL_ADM with values to the SU24 "check/Maintain" indicator for SM36... however such users would most likely have access to tcode SM49 as well (from which they, in my opinion correctly, will have the authority and the check indicators are already maintained in the default SU24 indicators (ie. SU22).

I don't know why your job step is executing the command, so I can only guess.... you have a different user entered in the job step and than the scheduler of the job (and creator of the job step), and you yourself have SAP_ALL (so you have S_RZL_ADM and S_BTCH_NAM...)?

Cheers,

Julius

[Former Member]

>

> Hi Alex,
> 
> As you are telling, the inclusion of an external command/ program in a background job might be rare. I wanted to tell, the check for S_RZL_ADM with ACTVT=01 is not rare. Means whenever a person tries to include an external command/ program in a background job, this check takes place, provided the check flag value has not been changed from' check only '( SAP proposal ) to' do not check ' & the program for SM36 has not been changed.
> 
> Regards,
> Sachhidanand

Hi Sachhidanand

The check for S_RZL_ADM is rare as it is a fundamental system level auth value and is used in relatively few situations in the majority of implementations.

It would appear that in <i>your</i> implementation there are a lot of background jobs running external commands. You are getting checks against S_RZL_ADM because SAP knows that there is high risk in doing this and is checking against an auth object which should reflect adequate authorisation.

Considering what external commands have the ability to do (thanks to the user executing them on the OS having rather high privileges - not quite root but close enough), jobs involving these should be part of a structured scheduling process, scheduled by people who know exactly what they are doing.

Typically only Basis and maybe batch users have this authorisation, it is not something that users outside these teams should have in a production environment. Give this in prod to end users and it is likely that your external auditors will comment on this.

When you understand what this controls it's easy to see why it would be foolhardy of SAP to include S_RZL_ADM, ACTVT=01 as a proposal value for everyone with SM36.

[Former Member]

> Sachhidanand Rankhambe wrote:

> I wanted to tell, the check for S_RZL_ADM with ACTVT=01 is not rare. Means whenever a person tries to include an external command/ program in a background job, this check takes place, provided the check flag value has not been changed from' check only '( SAP proposal ) to' do not check ' & the program for SM36 has not been changed.

If that is the way your processes are designed and your users are trained, then that is what you get for it => lots of S_RZL_ADM access is needed for any all (or most) users authorized for SM36.

So yes, you can add it in SU24 to the "Check/Maintain" indicator with values so that you are reminded of this every time you add SM36 to a role. That is what SU24 is there for...

Cheers,

Julius

[Former Member]

> Alex Ayers wrote:

> ... jobs involving these should be part of a structured scheduling process, scheduled by people who know exactly what they are doing.

Assuming that only people who know what they are doing have access to SM36 to administrate scheduled jobs, then perhaps it is okay to add it in SU24. But I agree that SAP should not add it to SU22 (for all the rest of us).

Okay Sachhidanand, I give up... please tell us the answer?

Cheers,

Julius

[Former Member]

Hi Julius,

The step user is the test user itself( having only SM36 access ).

And I think, we are deviating from my main concern. Using this example I wanted to tell, I think,

1) authorization objects with the check flag value' check only ' have some importance. They are not just for information.

2) the users having access to a transaction automatically get the access to the authorization objetcs related to that transaction & having the check flag value' check only '.

Regards,

Sachhidanand

[Former Member]

>

> Assuming that only people who know what they are doing have access to SM36 to administrate scheduled jobs, then perhaps it is okay to add it in SU24. But I agree that SAP should not add it to SU22 (for all the rest of us).

That's a nice assumption

[Former Member]

Hi Julius,

I am extremely sorry, I have never used SU22 & am not authorized for the same. So no idea about its use.

And regarding my previous message( where I have mentioned two points ) I have specifically mentioned, I think. Means I am not sure about the second point & want to confirm the same with you people.

Regards,

Sachhidanand

[Former Member]

Hello Sachhidanand,

> The step user is the test user itself( having only SM36 access ).

So (in my own words to confirm I understand): You logged on with this test user (a dialog user), created a job in SM36 and scheduled an OS command in a jobstep which has this user as the step user as well. The role of the test user does not have any S_BTCH_ADM object authority, nor does it have any S_RZL_ADM object authority. You released the job, and the command executed.

Is that what happened?

Can this same test user also go into an existing job and change a command in an existing jobstep?

> 1) authorization objects with the check flag value' check only ' have some importance. They are not just for information.

If the check is not in the program, adding "Check" flags to SU24 will not help.

I find it very usefull information, but what is it then (a "check" flag in SU24) if not information only?

> 2) the users having access to a transaction automatically get the access to the authorization objetcs related to that transaction & having the check flag value' check only '.

No, that would be "Check/Maintain" (in higher releases: "Proposal = Yes").

> ...I have never used SU22 & am not authorized for the same. So no idea about its use.

SU22 is for SAP to maintain the "out-of-the-box" delivered defaults for the SU24 defaults of PFCG. You should not normally ever need to change SU22 (only tune SU24 to suite your requirements). Have you performed the intial steps in SU25 to set up SU24?

Cheers,

Julius

PS: A few years ago, back on 4.6C, I worked with someone who created a transaction variant for the screen program, to hide the command options if not authorized (I think S_RZL_ADM ACTVT '03' was used, which is also the only field of this object b.t.w...) and change the "program" to select them only from report transactions (as type of transaction) for which the user must be authorized (object S_TCODE), however the program name was still entered when the transaction name was selected by the user, of course. It looked nice, from the end user perspective

[Former Member]

Hi Julius,

Yes, you are almost correct. Two corrections, S_BTCH_ADM is there, but unmaintained( I have kept as it is. ) & I deleted the job before execution because I am not authorized.

The test user is able to change the command.

And I agree with you, if not coded properly, there is no use of checks in SU24.

Regarding my second point, the following facts cause me to think in this way.

1) S_RZL_ADM has the check flag value' check only ' with respect to SM36.

2) The program for SM36 contains the check for S_RZL_ADM with ACTVT=01.

3) Though I am unable to find S_RZL_ADM in the authorization data of that test role, as well as in the user buffer of the test user, the test user is able to include an external command in a background job.

Thank you very much for giving the information on SU22.:-)

But I kindly request you to

1) explain SU22 in detail( possibly with an eg ).

2) tell, when we should go for SU22( possibly with an eg ).

No, I have never used SU24 & SU25. Even not authorized to try. But I have little bit idea.

Regards,

Sachhidanand

[Former Member]

Hi Julius,

I forgot to mention, I am getting,

3 <- S_RZL_ADM:ACTVT=01

in ST01 for the test user.

Can you please tell me, what does 3 indicate? Even 1.

Thanks in advance.

Regards,

Sachhidanand

[Former Member]

Hi Sachhidanand,

Perhaps I have completely misunderstood what you are asking about "check flag value' check only '" when you state that "No, I have never used SU24 & SU25. Even not authorized to try. But I have little bit idea."

You will find a number of SAP notes which refer to SU22 for examples. The authoritative one as far as I know is Note 368496 - Check indicators and default authorization values, Important remark # 3:

> In numerous notes from application components, customers are requested to supplement missing default data manually using Transaction SU22. This is not the correct transaction for this purpose! Transaction SU22 only allows to modify SAP data in Tables USOBX and USOBT. If you want to change your customer data, use Transaction SU24! If you find out that check indicators and default authorization values are missing in your system, create a message in the component of the transaction concerned, and ask for the missing data to be made available via a Support Package or in advance in an upload file. Give this note as a reference.

Regarding the trace, which release are you on?

I just ran a trace in a 7.00 system doing what you described. Required authority was:

OBJECT 'S_BTCH_ADM'

ID 'BTCADMIN' FIELD 'Y'

(this also beats S_BTCH_JOB b.t.w.)

and

OBJECT 'S_LOG_COM'

ID 'COMMAND' FIELD <the command>

ID 'OPSYSTEM' FIELD 'ANYOS'

ID 'HOST' FIELD <the host name>

Actually it checked this authority when saving the job step and again when I released it.

(which is what Alex has already mentioned)

I did not do anything (and neither did my command) to invoke any S_RZL_ADM checks.

I then executed the same command from SM49. The same checks were made on 'S_LOG_COM', but the system also checked to see whether I had S_RZL_ADM id ACTVT field '01', in which case it disabled some things in the tool bar, including the "create" button (which is SM69), but only checked 'S_LOG_COM' when I actually executed the command!

So, I would say that Alex is right in that S_LOG_COM is your control and S_RZL_ADM should be avoided, as it can do more serious stuff (such as rename commands for S_LOG_COM...).

Do you agree?

Cheers,

Julius

[Former Member]

> That's a nice assumption

Assumptions are cool! I always carry assumptions with me in my backpack...

Enjoy the weekend,

Julius

[Former Member]

Hi Julius,

I am extremely sorry for the late reply.

Let me clear, I want to confirm, whether giving a transaction access automatically gives the access to the authorisation objects having the check flag value' check only ' for that transaction, or not?

Thanks a lot for the information on SU22.:-)

The version is 4.6C.

Its a surprise for me, S_LOG_COM got checked while saving the job step( instead of S_RZL_ADM ) & releasing the job. Actually it controls the external command execution access.

Anyway, I am still stuck with the above( mentioned in" Let me clear...... " ) doubt. Can you please help me? Thanks in advance.

Regards,

Sachhidanand

[Former Member]

Hi Sachhidanand,

> Let me clear, I want to confirm, whether giving a transaction access automatically gives the access to the authorisation objects having the check flag value' check only ' for that transaction, or not?

No, it will not automatically do this. The closest thing to this is the "Check/maintain" indicator and values (maintained in SU24) which will propose the authorizations when you add the transaction to the role menu or merge the authorization data in PFCG after changes to SU24.

> The version is 4.6C.

That is helpfull to know. I should have asked earlier...

> Its a surprise for me, S_LOG_COM got checked while saving the job step( instead of S_RZL_ADM ) & releasing the job. Actually it controls the external command execution access.

Check SAP note 854060 (which should be current for you). There is also an activation switch mentioned, if you want the check to be performed against the "jobstep user" in addition to the "job scheduler". It might also make sense to use dedicated system type users in your job scheduling so that only the administrators (as human SAPGui capable dialog users) have this access.

Hope that helps,

Julius

[Former Member]

Hi Julius,

If you have some free time, then can you please do one thing? Please

1) create a test user in your system.

2) assign a test role containing only one transaction having some authorisation objects with the check flag value' check only ' in USOBX_C.

3) log into the system as the test user.

4) try to carry the activities( using the above transaction ) for which( atleast ) one of the above authorisation objects will get checked.

5) let me know the result.

Thanks in advance.

Regards,

Sachhidanand

[Former Member]

> 1) create a test user in your system.

> 2) assign a test role containing only one transaction having some authorisation objects with the check flag value' check only ' in USOBX_C.

> 3) log into the system as the test user.

> 4) try to carry the activities( using the above transaction ) for which( atleast ) one of the above authorisation objects will get checked.

> 5) let me know the result.

Okay, done: using SM36 with limited S_BTCH_JOB authority only.

What were your results?

Cheers,

Julius

[Former Member]

Hi Julius,

As mentioned previously, the test user is able to

1) include an external command in a background job &

2) release the job

though S_RZL_ADM( which is getting checked with RC=3 ) is not there in the authorisation data.

Regards,

Sachhidanand

[Former Member]

Hi Sachidanand,

For me there were checks on S_BTCH_ADM which failed (rc=12) which are normal and can be ignored, when I started the transaction.

When scheduling an external command in a step with the same test ID, the system raised an error (rc=12, no authority for S_LOG_COM command PING etc).

When attempting to select an "external program" to execute the command, an error was raised as well (rc=12, no authority for S_RZL_ADM actvt 01).

I confirmed this in a ST01 trace, a SU53 dropped into the error popup and display debugging. I did this with and without a "check on" in USOBX_C (maintained via SU24, for SM36). Same result.

I think the difference here is the release level which you are on and possibly an outdated patch level as well? So our tests are comparing apples and pears.

Cheers,

Julius

[Former Member]

Hi Julius,

You have mentioned, some checks can be ignored. Can you please tell me, which checks get ignored? Even in my case, I am getting RC=3( Can you please tell me, what does 3 indicate? ) for S_RZL_ADM, but the user is able to proceed further.

Regards,

Sachhidanand

[Former Member]

RC = 3 means Object not contained in user buffer

If a trace code returns > 0 and the transaction proceeds then it because SAP has not deemed it critical enough to stop the process. In the AUTHORITY-CHECK error handling for SY-SUBRC results the developer can control the code depending on what the return code is.

[Former Member]

Hi Sachhidanand,

What I meant by "can be ignored" is that the trace showed a check on S_BTCH_ADM = 'Y' which failed for my test user, but that is no reason to add it to the test user's role (therefore, I ignore it). The system did not check it to be able to raise an error "You are not authorized to use SM36 at all"; it checked my authority to determine which navigation in the transaction it will allow me to use and how much information (e.g. cross-client) it should show me.

I did not see any "rc=3" at my release (7.00, last patched on Wednesday (this week)). What it might be is that the authority-check is performed in a different program (function pool) to check the authorization of the user. The external program returned an exception with the value 3 (whatever that may mean to the external program), but the programmer did not react to the exception.

Sorry, I can only guess about your "3" as I don't have one of my own

Cheers and enjoy the weekend,

Julius

[Former Member]

Hi Alex,

Even RC=12 indicates the required authorisation object is missing. So, is this version dependent?

Regards,

Sachhidanand

[Former Member]

>

> Hi Alex,
> 
> Even RC=12 indicates the required authorisation object is missing. So, is this version dependent?
> 
> Regards,
> Sachhidanand

Hi,

It sounds like SAP is looking for the auth object, can't find it at all in the buffer so the system return code ( SY-SUBRC) = 12. The code for the transaction you are running has some logic which approximates to

if SY-SUBRC = 12 then ignore this and proceed. Often this is referred to as a soft fail (i.e. it has failed, we know it has failed, but don't do anything about it). This will have been entirely down to either what the the programmer for the program wanted to do rather than any setting in the USOB* tables etc.

[Bernhard_SAP]

....to clarify....

System Fields

sy-subrc Meaning

0 Authorization successful or no check was carried out. An authorization for the authorization object was found in the user master record. It's value sets include the specified values.

4 Authorization check not successful. One or several authorizations were indeed found for the authorization object in the user master record and they include the value sets, but not the values specified, or incorrect or too many authorization fields were specified.

12 No authorization was found for the authorization object in the user master record.

24 Incorrect authorization fields or an incorrect number of authorization fields was found. This return value is no longer set since Release 6.20. Up to Release 4.6 it is set only if the profile parameter "auth/new_buffering" has a value less than 3.

40 An invalid user ID has been entered in user.

Divide the sy-subrc by 4 and you get the returncode displayed in the trace....

From kernel side the check-flags (usobx_c=SU24-entries) C(Check) and CM (Check/maintain) have exactly the same effect. The difference is only that with CM the proposals are added to PFCG if there are some (means the object is added in pfcg with maintained values if there are some).

But the statement authority-check is handled completely same for boths

settings C and CM by the kernel.

b.rgds, Bernhard

[Former Member]

Hi Bernhard,

Thank you.:-)

Regards,

Sachhidanand

[Former Member]

To protect business data and functions against unauthorized access, SAP programs

utilize authorization checks.

In order to pass an authorization check of this type, a user needs the appropriate authorization.

Authorizations are assigned using profiles in the form of roles, which are entered into the user master record.

The ABAP statement "authority-check" is used to check the authorization object

assigned to the transaction. The check is performed during transaction start by

the ABAP program called by the transaction. Certain field values are always required for authorization objects whcich are mentioned in the "authority-check".