Solved: ECC 6.0 - authorisation check for object S_CTS_ADM...

Former Member · ‎03-16-2010

Dear all,

we are in post-upgrade activities. I am trying to adjust my roles, make my SU2* etc. I have detected that SAP added object S_CTS_ADMI to various warehousing transactions, such as LI05, LX42 etc. Since this is a Basis object, I cannot deactivate the check in SU24.

There's a vast amount of Basis objects assigned to WM-transactions, like:

S_BDS_DS

S_CTS_ADMI

S_DATASET

S_DEVELOP

S_DOKU_AUT

S_GUI

S_SPO_DEV

S_TRANSLAT

Where you can adjust the proposal, but not the check in itself? What is the sense in this? How do you cope with this?

Any inspiration is greatly appreciated - did I overlook a documentation someplace, maybe?

mvoros · ‎03-16-2010

Hi,

for example object S_CTS_ADMI is not automatically proposed when you add transaction LX42 to role. Actually, all objects mentioned by you are not proposed. So I wouldn't worry too much about these objects.

Cheers

mvoros · ‎03-16-2010

Hi,

for example object S_CTS_ADMI is not automatically proposed when you add transaction LX42 to role. Actually, all objects mentioned by you are not proposed. So I wouldn't worry too much about these objects.

Cheers

Former Member · ‎03-16-2010

Thanks for the answer, Martin ... unfortunately you are partly wrong:

In LI05 S_CTS_ADMI is checked and proposed, all others are checked, but not proposed.

In LX42 they are only checked, but not proposed.

If they are checked, surely I have to provide them, yes?

mvoros · ‎03-16-2010

Yes, I just checked LX42. What I wanted to say is that I would worry only about objects with proposal set to yes. I also agree with Julius's advice about your object.

Cheers

Former Member · ‎03-16-2010

Are you basically saying that you simply bow your heads and accept this freakish concept?

Even grant S_BTCH_ADM for LT03 as well as S_BTC_JOB??

Where do I draw the line?

Former Member · ‎03-16-2010

I don't and report things to SAP for checking their appropriateness.

The S_BTCH_ADM proposal of an empty field is without a doubt such an example and as the transaction could be used on it's own you can make the decision here in PFCG or on the "Application" tab in SU24, or centrally and once only via the "Authorization Object" tab in SU24.

For the objects you have mentioned plus a few more I use the latter option and remove them all.

Cheers,

Julius

Former Member · ‎03-16-2010

>


> I don't and report things to SAP for checking their appropriateness.
> 
> The S_BTCH_ADM proposal of an empty field is without a doubt such an example ...

Ah!! I feel better now. O.k. - I'm going to risk Note 11, I have more than 70 transactions in WM and around it, that are assigned one/more/all of the 'notorious pest' kind of object or S_BTCH_ADM or S_DEVELOP or ... S_RFC

Thank you both for taking the time for me - I will come back to this thread

Former Member · ‎03-16-2010

> I'm going to risk Note 11

I think this problem is a bit light for a development request, though a global "blacklist" for objects in SU24 might have it's uses.

The thing is that if the user only ever had transaction LT03 in the system, then they might need some of those objects and you are proposed to make your choice.

I normally clean the whole lot out for "silly" and "risky" objects from the SAP trace which come in via SU22, particlarly if they are picked up in the trace and the values are left empty.

It takes 2 or 3 days to setup in the beginning and document the central choices, but then you have it behind you.

Irish SAP upgrade peotry

May the road rise up to meet you.
May the wind be always at your back,
May the sun shine warm upon your face,
And the rains fall soft upon your fields,
And, until we apply support packs again,
May SU24 hold you in the proposals of your own hand.

Cheers,

Julius

Former Member · ‎03-16-2010


> Are you basically saying that you simply bow your heads and accept this freakish concept?
> 
> Even grant S_BTCH_ADM for LT03 as well as S_BTC_JOB?? 
> 
> Where do I draw the line?

I agree with you about the pesty objects S_CTS_ADMI with TABL authorizations, i had a posted a thread ealrier regarding transferring bank data which checks for this object, but couldnt get the right examples to cite.

Anyway, reagrding your comment on LT03 - for me, it makes perferct logic to have the objects S_BTCH_JOB and S_BTCH_ADMI checked for this transaction, and i would give access to users on these objects - restrciting it to excecuting their own jobs (S_BTCH_NAM)

When you have a delivery withe 60 line items and you need to create trasnfer order (complete the Picking and Putaway) you wouldnt want to do it one by one, so it is logical that SAP has provided an option of running it as a foreground excecution or for background processing

Just like you, I would like to know more on the S_CTS_ADMI object BUT i do not agree to your argument on LT03

Former Member · ‎03-16-2010

I am not sure I follow your argument on LT03 -> you can perfectly well submit PutAway to background without needing to administrate jobs at all ...

... but as Julius so very poetically said: everybody as she/he sees fit - and anyway, that's just one transaction out of a lot ...

Former Member · ‎03-16-2010

> restrciting it to excecuting their own jobs (S_BTCH_NAM)

No. Your own jobs do not require any authorizations at all, except S_BTCH_JOB = RELE to finally release them.

If periodic jobs are going to be scheduled you should use a SYSTEM user for this, and define the available system users (plural) in such a way and with such authorizations that the administrators of the jobs can be organizationally kept apart via object S_BTCH_NAM.

See [SAP Note 101146|https://service.sap.com/sap/support/notes/101146]

These objects are also notorious pests in SU53 as well. You just have to understand it once, and then you are okay.

Cheers,

Julius

Former Member · ‎03-16-2010

> and anyway, that's just one transaction out of a lot ...

That is why there is an "Authorization Object" tab in SU24 --> Mass maintenance.

Former Member · ‎03-16-2010


> > and anyway, that's just one transaction out of a lot ...
> That is why there is an "Authorization Object" tab in SU24 --> Mass maintenance.

yes, I know ... it's only that - when objects (like S_CTS_ADMI) are assigned without reason and/or a pattern and/or a concept I could understand and/or a documentation I could worm my way through, that I get irritated. This is not about 'getting used to' - this is about transparancy (?).

I think I will get started on that 'blacklist' also ...

Edited by: Mylène Dorias on Mar 16, 2010 1:34 PM

Former Member · ‎03-16-2010

>


> If periodic jobs are going to be scheduled you should use a SYSTEM user for this, and define the available system users (plural) in such a way and with such authorizations that the administrators of the jobs can be organizationally kept apart via object S_BTCH_NAM.

Its not even that - nothing to schedule, nothing periodically, no report to submit - the transaction LT03 allows you to 'Generate PutAway' either directly or in background. ... no idea how, but you don't need an authorisation for that.

Former Member · ‎03-16-2010

> no idea how, but you don't need an authorisation for that.

This is because S_BTCH_JOB is needed for the release, so it checks your authority. But, S_BTCH_ADM overrides S_BTCH_JOB for those who are batch admins (=Y?) in which case S_BTCH_JOB is no longer required at all.

It is just one of those things you need to know by reading the documentation, otherwise you don't know it and would not of your own accord chance upon the idea that it might work that way.

Cheers,

Julius

Former Member · ‎03-19-2010

{climbing mode}

Got note 11. Make room please, Julius - I'm coming over to your side of the fence. Spread the word: mass-deactivation is our weapon of choice!

{climbing mode}

Former Member · ‎03-19-2010

Guys, sorry - there seems to be something wrong with the tool where I can assign ponits to you - I get an error message.

Let's wait, until this is fixed - I'll come back then.

Former Member · ‎03-19-2010

> Spread the word: mass-deactivation is our weapon of choice!

Yes, I agree with you and would certainly use it to block a selection of objects from being proposed at all - particularly if they are "repeat offenders"..

Currently I simply remove them on-mass in SU24 and keep a list of the ones for which I do it.

Let us know how the development request goes.

Cheers,

Julius

Former Member · ‎03-16-2010

The "check" indicator documents the capabilities of the transaction, you do not have to use it "that way".

The "proposal" is a suggestion of the intended way to use it and implies that the check is somewhere there but does not have to be.

S_ADMI_FCD function TABL is a notorious pest (search for a comment by Bernhard Hochreiter) as is S_TRANSLAT and actually all the others you have mentioned as well.

I suggest making a basic decision how to deal with them and add them to a basic functions role for all users after investigating them once and for all, and then nowhere else. This works for me and when you apply SP's etc and SAP suggests them again from their own traces then you can centrally reject the lot.

Cheers,

Julius

ECC 6.0 - authorisation check for object S_CTS_ADMI in WM (LI05)