Authorization Object Clarification

[Former Member]

Hi guys,

I have two questions regarding Authorization objects, my first question is, why we canu2019t execute any transaction if we have access to all the authorization objects that has linked to those t-codes for example:

(SA38 or SE38) bringing S_Develop, S_DATASET, and S_PROGRAM if I assign all these authorization objects into the role manually I still don't have access to sa38 or se38. So how come we always say everything is control by authorization object. We always need T-codes in the role either by menu or manually. Is that true?

My second question:

We always say don't assign S_Develop in Production, but we need to assign one general role which should have SU53 and by SAP standard SU53 bringing S_Develop authorization object which is very dangers for Production. How come SAP standard conflicting rule not to assign S_Develop in Production?

Please kindly give your feedback and thoughts

Thanks

Faisal

Edited by: Faisal on Aug 6, 2009 3:39 PM

Edited by: Faisal on Aug 6, 2009 3:39 PM

[jurjen_heeck]

> (SA38 or SE38) bringing S_Develop, S_DATASET, and S_PROGRAM if I assign all these authorization objects into the role manually I still don't have access to sa38 or se38. So how come we always say everything is control by authorization object. We always need T-codes in the role either by menu or manually. Is that true?

Yes, the S_TCODE check is the first line of defense. This check is done for every transaction start and cannot be switched off.

> We always say don't assign S_Develop in Production, but we need to assign one general role which should have SU53 and by SAP standard SU53 bringing S_Develop authorization object which is very dangers for Production. How come SAP standard conflicting rule not to assign S_Develop in Production?

SU53 does not need S_DEVELOP for its normal use.

[Former Member]

Thanks for youu2019re replied

So we can assign S_Develop in the role without SA38 or SE38 no one can execute the transactions because we don't assign the t-codes but they will have S_Develop, is it harmful in Production? What about S_Develop through SU53 should we deactivate the S_Develop or let it go to Production because it is coming thr SU53?

Thanks

Faisal

[sdipanjan]

In which release you are working currently?

Do Not assign any Object Manually in Authorization Data.... Add the Tcode (SU53) in the role menu and let Profile generator decide and pull the relevant Authorization Objects. You will not see S_DEVELOP in this case. Check the proposal for your information.

Regards,

Dipanjan

[Former Member]

I checked it su24 you will get S_Develop when you assign SU53, that's why I was asking this question

Best Regards,

Faisal

[Former Member]

What version are you on?

S_DEVELOP is not in Check Maintain or Proposal = Y status in any of the systems I have access to

[Former Member]

ECC 6.0 it is check/maintain for su53 for sure. It is a new system it hasn't been changed because we are in Relization phase no one touched it yet, I'm the only security person here.

Thanks

Edited by: Faisal on Aug 6, 2009 5:00 PM

[Former Member]

Sounds like someone changed your SU24 settings to include S_DEVELOP in a role for all users on the strength of SU53 being in the menu.

Not a good idea...

SU53 itself is a nice example of the difference between the S_TCODE authority to start something and the authorization objects in the code to actually use it.

You can turn the transaction check at tcode start off for SU53, but depending on the authorizations of the user for the S_USER_AUT object they might only be able to see what failed, or additionally also see what they do have authority for.

S_DEVELOP is the same. There are many ways (not only limited to transactions) via which you can enter the ABAP Workbench Navigation - but once in there the "real checks" take place. The best known examples are via the menu: System --> Status --> Navigate, and the F1 --> Technical Information --> Navigate routes. (in higher releases there is also an SE80 check).

If you want the user to have consistent authorizations in the system and not be subject to silly little mistakes in the menu, S_TCODE and other objects and roles they might have, then rather give them the correct authorization to use the transaction and only in exceptional cases turn the object level checks off in SU24.

My 2 cents,

Julius

[Former Member]

Very curious, I wonder why it is setup like that?

[Former Member]

Beleive me no one changed it, it is standard unless there is some issue with patches when it installed. What about your system is it check.maintain or not.

Should I talk to my basis team about that. I can change the su24 setting but I checked my sandbox and all the other client in sandbox and Dev all are check/maintain.

What you say?

Thanks

Faisal

[Former Member]

First check in SU22 whether some nilly added it there, and then transfered to SU24 later.

It should show up as "original" data in SU22, where the author is not 'SAP'.

Unfortunately in some releases the SU22 data was also delivered with the ID and not the 'SAP' anonymization which can be confusing, but that should not be the case here.

Cheers,

Julius

[Former Member]

In the version of ECC6 I have access to at the moment, S_DEVELOP is set to Check with proposal = No, so will not be pulled through in to a role. There are no change logs for this during the time installed.

[sdipanjan]

Did you check the SAP Proposal also? The check indicator you are viewing there is the Customer Table proposal.

If you check in the Application tool bar, there is a Button called "SAP Data". Please click on that button to see the SAP proposal (entries of table USOBT and USOBX) and let us know what you are getting for S_DEVELOP as SAP Data.

Regards,

Dipanjan

[Former Member]

It says SAP propsl = YS and also proposal is = YS. What you guys say?

Is it installation or patches? My sandbox and Dev in all clients are same. one more thing I checked my IDES system that is the only system doesn't have YS, it has NO in the proposal. SO IDES system is correct or whatever?

But in IDES system for the SAP propsl still = YS

Best Regards,

Faisal

Edited by: Faisal on Aug 6, 2009 5:47 PM

Edited by: Faisal on Aug 6, 2009 5:50 PM

[Former Member]

> What you guys say?

Someone hacked your SU22 data...

[Former Member]

I modified su24 I changed propossal = No for the S_Develop but SAP propsl I didn't touch it its still = YS. but after I changed it it is still brigning the Object into the Role. Can you please tell me what's wrong

do I have to change SAP Propsl also

Please Advice

Thanks

Faisal

[Former Member]

Has step 1 of SU25 been run before in these systems?

After changing SU24, you need to do a "Read old status and merge with new data" in expert mode for the authorizations of the menu objects to be adjusted.

But it would be wise to first check how the roles have been built and how intact the authorization data is to start with, as you could be in for a surprise... particularly if standard authorizations have been deleted in the past and the merge has not been used! Why standard authorizations can be deleted at all I actually don't know...

Cheers,

Julius

[Former Member]

Please advice me !

These are brand new systems, Sandbox and Dev never upgradet from SU25. As I mentioned in my pervious post its pretty vaired that SU53 pulling S_Develop, S_USER_AGR, S_USER_AUT, and S_USER_GRP. I had to fix these su24 standard propossal they are all SAP Proposal.

Now I changed all the proposals for the above Authorization objects to "NO" but I didn't touch the SAP proposal which was the last column. and then I went to one of the role which has su53 and went through EDIT mode I still see S_Develop pulling, I don't unserstand why.

Please advice

Thanks a lot

Faisal

[sdipanjan]

> I modified su24 I changed propossal = No for the S_Develop but SAP propsl I didn't touch it its still = YS. but after I changed it it is still brigning the Object into the Role. Can you please tell me what's wrong

>

Please check the status of the Object showing in the Profile Generator. If it is manually (I presume this is the reason of not getting the effect of check proposal you modified) and if maximum objects are manually added then I would suggest to delete that role and then create a new role. Add the TCodes in Menu tab and then maintain their authorizations in Authorization tab to generate the profile at last.

> do I have to change SAP Propsl also

>

No. never.

Regards,

Dipanjan

[Former Member]

If the authorization is in "Changed" status then SU24 changes no longer take affect and a new standard authorization is not inserted. Is that the case?

Running step 1 of SU25 is something you should have done rightttt at the beginning after the installation.

Sounds like a real mess you have there...

Okay, back to the beginning: Please check in report RSPFPAR what the value is of the parameter "transport/type"? Is it a SAP system?

=> SU53 does have the capability of checking S_DEVELOP if you want to double-click on the object name (which will take you into SU21 - a development type transaction...). But that is not sufficient reason on it's own to propose it. Only to check it.

Please confirm the transport/type parameter?

Cheers,

Julius

[Former Member]

Julius, you are right dude, it was in "changed" status. So far I fixed the SU53 issue but I think I found another one Su56 bringing same Authorization objects as Su53 was pulling.

My question is how do I know which are the right Authorization objects for su56 or any tranaction code. Please advise if su56 should pull S_DEVELOP, S_USER_AGR, S_USER_GRP, and S_USER_AUT. I might need to change the setting for SU56 as well.

I think I also need to create OSS note to find out why su24 setting are like that for my system. Is it because Basis didn't installed it right or something else

Meam while I like to fix SU56 if the above authorization objects are not belong to Su56. I really appreciated you guys. You guys were really helpfull

Thank you so much

Faisal

[Former Member]

You need to decide for yourself what you want to propose and what not. The check flag is more of a capability indicator ...

If you don't have consistent approaches to changing SU24 for specific transaction contexts, the I would recommend accepting SAP's proposals for the large part, and consequently also accepting SAP's intended transactions by choosing them carefully.

Have you checked the "transport/type" param yet? That would be slightly different.

Actually, another possibility here is that the basis guys copied the DB table accross from some existing central one which they once had setup as a "building block". Tempting but also not a good idea, particularly for release dependencies and when SAP improves the SU22 data quality, as they have....

Cheers,

Julius

[Former Member]

transport/systemtype there are three column

First one is: User defined Value = empty (blank)

Second one: System default Value = CUSTOMER

Third column: System default Value (Unsubsitituted Form) = CUSTOMER

I guess I need to talk to my Basis team I don't know what esle is messed up in the system.

thank you so much

Faisal

[Former Member]

Yes, I would ask the basis team who did the installation about why SU25 steps are not run and why there are these non-standard values in SU22.

Good luck,

Julius

[sdipanjan]

Adding few points with Jurjen:

> I have two questions regarding Authorization objects, my first question is, why we canu2019t execute any transaction if we have access to all the authorization objects that has linked to those t-codes for example:

>

> (SA38 or SE38) bringing S_Develop, S_DATASET, and S_PROGRAM if I assign all these authorization objects into the role manually I still don't have access to sa38 or se38. So how come we always say everything is control by authorization object. We always need T-codes in the role either by menu or manually. Is that true?

>

The series of Checks while you are trying to execute some TCode/Report is like below:

1. Check whether the TCode is existing in the system (TSTC, TSTCT, TSTCA, TSTCP etc.) tables. If this check fails, you will get an error message and system will not go for further checks i.e. Authorization checks against the available authorization instances in User's Buffer content.

2. The first level of Authorization check for any TCode is done against the Object S_TCode.

3. After passing through the point 2, the authorization checks for other Objects take place with an AND operator.

> My second question:

>

> We always say don't assign S_Develop in Production, but we need to assign one general role which should have SU53 and by SAP standard SU53 bringing S_Develop authorization object which is very dangers for Production. How come SAP standard conflicting rule not to assign S_Develop in Production?

>

> Please kindly give your feedback and thoughts

>

SU53 doesn't require S_DEVELOP for any user action. Please go through the documentation of S_DEVELOP and available notes to understand the necessity of these critical objects.

Regards,

Dipanjan

[Former Member]

I think We need S_DEVELOP (03) on SUSO to look at the details of the Auth. object in the error message. SAP Note:- 968915.

[Former Member]

> We need S_DEVELOP (03) on SUSO to look at the details of the Auth. object...

... to be able to do so. SU53 has this ability. But I would not consider it advisable to propose it - just in the same way that S_USER_AUT might not be desired as the user can find all the holes and ranges and features which are hidden from them in the authorization concept. It is not a "needed" authorization to use the transactions.

A strong indicator of this is that SU53 is checking DUMMY for several of the fields of S_DEVELOP - this means the user needs the authorization if they are to navigate further, but it is expected that they should have this authorization from somewhere else and not SU53. These DUMMY checks combined with the proposal added to SU22 (SU24) for S_DEVELOP with only SUSO maintained is without a doubt the culprit for causing the "Changed" authorization.

So it looks like there are actually 2 nillies in the system, working together in tandem without knowing it...

Cheers,

Julius

[Former Member]

Hi Julius(or Mr. Bussche ;... kidding) , I have to agree with You on no need of this object for the users( except we(s. admins). but sure not somebody tampered the checks on faisal's system. this check came with the system. I think you have to agree on this.

[Former Member]

2nd attempt...

Hi Keerti,

No problem with "Bussche". Some people just say "Hey, you!!" to me...

I agree that the Check flag is correct (the transaction has the capability) but the "Proposal = YES" is illogical and even stupid.

It is not included in the standard system SU22 (except for Faisal's...) and does not make any sense to me if it did.

The navigation from SU53 is checking DUMMY values for the fields of S_DEVELOP (other than ACTVT and OBJTYPE).

Okay, one could maintain all the package names, program names, etc but that is not included either, which encourages authorizations with "Changed" status.

This is in my opinion worse than "Manually" and would cause hundreds of "Inactive" authorizations as the SU53 user should obtain their S_DEVELOP access from somewhere else to be able to use this navigation....

... or cause a big mess for all users, as we have seen here.

Cheers,

Julius