spro full authorization without sap_all and sap_new

[Former Member]

Hi Friends,

Can u suggest me how to give spro full authorization without sap_all and sap_new profile.

Thanks & Regards,

Tarun

[Former Member]

Hi Tarun,

Normally SPRO stands for SAP Project Reference Object. So the basic two objects used for this are S_PROJECT

S_PROJECTS

So, if you want to give full access to these - then you have to maintain * value in these fields and also the other objects which are used here are

S_RFC

S_TABU_CLI

S_TABU_DIS

S_TRANSPRT -

So, use the above objects accordingly to get full access to SPRO.

Through SPRO you will even go to number range object - so depending on your requirement use the objects.

Or to escape all the above you may also create a role by using projects.

Hope this might have helped you.

Regards,

[Former Member]

Please search in the forum ..there are so many threads on the SPRO.

There are no definitive answers but lot of ways to achieve it.

You can create a project for any specific modules ...using SPRO_ADMIN and then assign it to customising role in PFCG

[Former Member]

Hi,

Please see the steps below.

If there are any predefined project(s) created, you don't need to perform the first 4 steps.

1.Goto spro_admin, click on create project. Enter project name in the prompt. and enter descripton.

2.Save the project

2. Click on Scope tab, select the first option "Seicfy project scope by making manual selections in

Reference IMG"

3. Now click on Specify scope button, and select the relevant entries for you. If you want all select all.

You need to navigate through the menu and make sure that basis transactions are not added.

Genrerally su01, su02, pfcg, and many other transactions gets added.

4. Now click on "genrate project IMG" button.

5. Now goto PFCG , enter the role name ,description required and save.

6. Click on Menu tab, and click on Utilities menu available in menu bar.

7. Select Customizing auth, and click in add button and select option IMG project, and select the

project you have created (or required one).

8.Now all the transactions in that project will be added (>=20000 generally). Click on Save button and

goto Authorizations tab and manage the authorizations.

9. You can remove the unnecessary transactions from s_tcode object and generate project.

Hope it helps you.

Thanks,

Gowrinadh C

[Former Member]

Hi Gowrinadh & friends,

Thanks for the help.. but still i hv not achieved wat i m loking for..

Actually i don't want user to use only basis trasaction, other than dat user cn use all the trasaction.

I followed the same way as per Gowrinadh, but still not able not able to restrict only basis tcode,

please suggest on this

[Former Member]

Have you edited the S_tcode object inside role. You need to deactivate the diaply one and add new one with all the possible transactions codes from the deactivated version of s_tcode.

Regards,

Gowrinadh

[Former Member]

This looks very suspect to me to be honest....

Are you sure about this and have you actually done this before?

What happens when you try to import all the transactions, and are you sure they are all there when you generate the profiles?

Let us know what happens when you actually do this and test to see what the affect is.

Cheers,

Julius

[Former Member]

Hi Julius/Gowrinadh,

Yes u are right i was not able to generate the role when i followed the same way...

So wat i did, instead of all modules i added only two three modules in it.

but here also i am facing some chalenges like users are not able to run few tcode u can say on 10-15%, they are not able to run, other things are fine.

@Gowrinadh: i also thought of the same way, but is there any other alternative.

please suggest

Regards,

Tarun

[Former Member]

I have implemented this way 8 months ago and users are working with role with out any issues. I know that copying tcodes from s_tcode, 5 at a time is really tough. However, u can see the sequence of transactions, use ranges to simplify them.

Tarun:

After all the methods, I was able to win only in this method.

Regards,

Gowrinadh

[Former Member]

So you manually copy&pasted 20000 tcodes 5 at a time until you either became tired or got to the end only to realized they did not all fit, and then ranged them?

Just curious,

Julius

[Former Member]

You don't need to copy all of them. almost 70% of them comes in sequnce, hence used them in ranges.

also the total no of tcodes in s_tcode will not be same as available in menu. I didn't do it at one go. Took gaps and prepared almost 2 days.

Regards,

Gowrinadh

[Former Member]

Okay, I see now by which approach you have worked.

In earlier releases, one could mostly conclude by the naming convention of the transaction what it was for.

xx01 - create

xx02 - change

xx03 - display

...

Oxxx - IMG maintenance

etc

But this seems to be dwindling away, and with new components having their own name spaces within which they have completely different or even generated names, I think this will become problematic in the long run from such manual or "best guess" role building.

Which brings me to the point of sustainability of the role during regular Support Packs and periodic Upgrades. How are you going to deal with this role then? 2 days to prepare each time seems a bit labour intensive....

Personally I would still favour creating multiple roles from IMG projects and document particularly the S_TABU_DIS and S_PROGRAM authority needed to use them, and assign some or all of them to the SPRO user as required. It makes sense to have a little check list of things which you know should not be included, so that you can verify that nothing unexpected is added... or tweak the coupled transactions a bit to meet your needs.

An alternate option would be to programmatically populate S_TCODE from the SPRO menu itself, after deleting the duplicates from CUS_ACTH and validating that these tcodes and possible wildcards (xxx*) do not introduce any additional TSTC transactions which are not already included in the scrubbed CUS_ACTOBJ anyway...

Cheers,

Julius

[Former Member]

I have prepared a role 8 months back, we passed 2 patch upgrade cycles and I can confirm that this role will work even after the next version of ECC upgrade. If there are any modules or new functionalities required, then customer has to request for it in addition. For which we can build separate role. We can plan for authorizations and build roles based on the inputs for today and tomorrow received from customer. By the way, the max no of consultants and business process owners having this role is not more than 40.

Regards,

Gowrinadh

[Former Member]

Hi Gowrinadh/Julius,

Thanks for your suggestion, I try to use them in ranges, but its still seems to be complicated & lengthy.

either this way or will try to segregate as suggested by Julius(earlier i faced some authorizatoin issues when i did segregation)

The alternative method Julius seems to be intersting, for that i need to do more R&D, will take help from abaper to achieve my goal

Thanks for help

Regards,

Tarun

[Former Member]

Hi Gowrinadh,

This is an interesting discussion. I don't mean to take shots at your concept, but I have some concerns about it as a solution.

> I have prepared a role 8 months back, we passed 2 patch upgrade cycles and I can confirm that this role will work even after the next version of ECC upgrade.

Sometimes the symptoms only make themselves visible later, and we don't know what is coming in the next version of ECC. Of course it should be largely compatable, but there will be new stuff. You can be sure of that.

> If there are any modules or new functionalities required, then customer has to request for it in addition.

My understand is that the customer requests a full and working SPRO role for each release. They will not find the tcodes for you and do not want to play ping-pong via support tickets either with it.

So each time you bill your customer for the 20 or 40 hours work for maintaining these tcodes manually in ranges? Appart from being error-prone, this solution is not scalable for when SAP might introduce another 20000 tcodes into the SPRO. Or someone convinces SAP to introduce an S_TCODE check for every line of code the whole system... (this is something which some people seem to believe in...), which would introduce several billion new tcodes for you...

> For which we can build separate role.

That is different. The question here (and certainly your solution) is to have them in the same role without duplicates but still including all SPRO access.

If you build them as seperate roles, then you can merge them as projects into one composite and live with the duplicates while checking for any known objects which should not be included.

I would agree with you. That is in my opinion a better solution, but it is not what you have been describing earlier.

> We can plan for authorizations and build roles based on the inputs for today and tomorrow received from customer.

That is the whole point in having maintainable roles and scalable processes. Manually maintaining 20k tcodes is incompatable with such requirements.

> By the way, the max no of consultants and business process owners having this role is not more than 40.

I don't think that assigning the role to less people will make it more usefull, nor that assigning it to more people will bring down it's per user cost of maintenance.

There is some old code posted here already which does what you have described in less than 1 minute. You can find it via the tables I have mentioned above, and will recognize it (and it's age) by the header lines it uses for internal tables. But it still works, since about release 3 point something...

Cheers,

Julius

[Former Member]

Hi Julius,

Yes its interesting. Billing customer 20 hours in anywhere between 3 - 7 years for me doesn't seem to be odd.

Also I am happy to see the other alternatives, however the time used to do that takes more time than the 20 hours.

I am not sure whether you have already done it. If so you can throw some light for us.

Regards,

Gowrinadh

[Former Member]

Hi Tarun,

I understand your concern as its hectic job to spend lot of time on a single role. However, SPRO is like that.

Hopefullly SAP might release SPRO roles atleast in next version.

Regards,

Gowrinadh

[Former Member]

If you are happy to bill your customer and they are happy to pay it, then that is also fine for a while or even 10 years...

For the per module approach, SAp already provides tcode SPRO_ADMIN.

Otherwise, tell your ABAPer to take a look at [cus_acth|http://www.google.ch/search?hl=de&q=cus_acth&meta=] and code which uses it for some ideas to populate the S_TCODE of the role before you generate the profile. It is a bit of a dirty trick, but it does work and you don't need to do it in production...

Cheers,

Julius

[former_member351271]

This message was moderated.

[Former Member]

spro "full" ??   in production??    Do you really know what that means?   Spro is just a tree.   Its buttons mostly open tables using SM30, or call variant transactions to execute something.

If someone wants "full" access to spro in production, which I find ridiculous, then tell them to use a Firefighter or some other logged method to temporarily escalate their privileges.

if someone wants "spro display" then that is also folly.  They need to tell you the specific actions they want to display (which again are probably just tables with SM30) and you can give access using s_tabu_nam for those specific tables.   If they tell you "I don't know what I need in spro" then reject their request as unclear.  it's like saying "give me all access to accounts payable.  i don't know what exactly I'll do so give me everything just in case.  oh, and its urgent too".  it's ridiculous.

for those rare activities that need to be performed directly in production, figure out what they are in QA, and give those specific tcodes in a manual-config role to the specific person doing the config.

[Former Member]

Kesayamol Siriporn wrote:


if someone wants "spro display" then that is also folly.  They need to tell you the specific actions they want to display (which again are probably just tables with SM30) and you can give access using s_tabu_nam for those specific tables.   If they tell you "I don't know what I need in spro" then reject their request as unclear.  it's like saying "give me all access to accounts payable.  i don't know what exactly I'll do so give me everything just in case.  oh, and its urgent too".  it's ridiculous.

The operational risk in granting a well crafted IMG display role is less than implementing a process that slows down access requests because an approver has an unfounded dislike of it.

[Former Member]

I always enjoy and agree with your posts Alex, but unfounded dislike?  when people ask for "spro display" and cannot take the time to articulate which areas of spro they need (in production), then it's the same as asking for s_tabu_dis / dicbercls = * and tcode = * and no security professional likes that.  when using spro_admin to vacuum tcodes into roles, it ends up giving overacess and can fill roles with SoD, assuming those weird variant tcodes used in spro are even defined in a ruleset.  I have found that config teams needing display access to anything in production are able to articulate what exactly they need when pressed, and as long as there is a process to temporary elevate privileges in true emergencies, then teams fall in line and we can keep the production data protected, and prevent IT staff from having super access in production.

[Former Member]

Hi, maybe we are talking at slightly cross purposes re the risk between display and update.  I can't figure out the quote system particularly well but here goes

when people ask for "spro display" and cannot take the time to articulate which areas of spro they need (in production), then it's the same as asking for s_tabu_dis / dicbercls = * and tcode = * and no security professional likes that.

I don't agree with your comparison. SPRO contains a set of relatively static (in that I mean they aren't hugely different between systems that aren't different IS-releases or similar) config options which, with some effort, can be mapped to transactions, table auth groups etc.  Most of us have a reasonable role somewhere in our toolkit that can be deployed.  It's common functionality and a common request that can, in most cases, be granted to the right people to display access with.

when using spro_admin to vacuum tcodes into roles, it ends up giving overacess and can fill roles with SoD, assuming those weird variant tcodes used in spro are even defined in a ruleset.

I refer to my previous post about having a suitable access prepared that deals with most of these "deviations".  In the same way we sanitise any default proposals that SAP makes blindly using SPRO_ADMIN will of course provide challenges. 

  I have found that config teams needing display access to anything in production are able to articulate what exactly they need when pressed, and as long as there is a process to temporary elevate privileges in true emergencies, then teams fall in line and we can keep the production data protected, and prevent IT staff from having super access in production.

In what case would display access to config be an emergency rather than business as usual for many organisations?  It is display, it's not superuser access by most definitions.  For those responsible for dealing with it on a daily basis it is BAU access.  To have to invoke an emergency process to display some config seems an awful waste of time to control something that, in most situations, doesn't require an additional level of control over it.

It is similar to enthusiastic controls designers who insist on OB52 being stuck in a FF process.

Cheers

[Former Member]

Hi

Just wanted to clarify. We are auditors and will always be requiring SPRO full display access as we will be covering almost all business cycles including system admin (Basis) during an year. We do face this issue of not being able to provide full display most of the times. For us even display access in Quality also will do.

Krishnamohan

[former_member351271]

Dear Mr. Siriporn,

              Thanks for your useful support I wiil do the same.

can I provide authorizations of all Tcodes inside SPRO in development server.

further transport request can be generated and move to Quality and further to Production

Thanks and Regards

Aditya Asati