SAP_ALL except STMS?

[Former Member]

If it possible to create a role with SAP_ALL authorization except STMS authorization?

[Former Member]

If it possible to create a role with SAP_ALL authorization except STMS authorization?

[jurjen_heeck]

>

> If it possible to create a role with SAP_ALL authorization except STMS authorization?

Sure, use the forum search and read our sticky thread first please.

[Former Member]

Hi Amy,

Yes. Make sure you do NOT modify SAP_ALL.

Use PFCG to create a new role and use SAP_ALL as a template, then you can add and remove t-codes and objects such as STMS.

Thanks and hope this helps.

[Former Member]

> Yes. Make sure you do NOT modify SAP_ALL.

May I ask why you say that or which source you have this information from?

I have successfully modified SAP_ALL without any problems. Actually, no one noticed it nor complained at all.

You can always regenerate it again if you need to...

Cheers,

Julius

[Former Member]

Hi

Yes, you would be able to restict the access STMS by giving SAP_ALL.

1. Enter PFCG

2. Give the role name and create the role

3. Do not enter any transactions in Menu

4. Save the Role

5. In Authorisation tab click Expert Mode and there will be a pop up of template.

6. Choose the template SAP_ALL and then click on Adopt Reference.

7. Click Yes for Insert all Authorisation

8. Message appears " Authorisations Added with complete Information"

9. Identify the objects associated with STMS

S_BTCH_ADM Background Processing: Background Administrator

S_BTCH_JOB Background Processing: Operations on Background Jobs

S_CTS_ADMI Administration Functions in Change and Transport System

S_DATASET Authorization for file access

S_DEVELOP ABAP Workbench

S_RFC Authorization Check for RFC Access

S_RZL_ADM CCMS: System Administration

S_TRANSPRT Transport Organizer

10. Before you generate the role disable the above authorisation objects except S_DATASET, S_RFC and S_RZL_ADM (if you are not using CCMS).

11. Generate the role and test it out. This works...

I have tested it successfully.

Thanks and Regards

Arun R

[Former Member]

>

> S_BTCH_ADM	Background Processing: Background Administrator	
> S_BTCH_JOB	Background Processing: Operations on Background Jobs
> S_CTS_ADMI	Administration Functions in Change and Transport System
> S_DATASET	Authorization for file access
> S_DEVELOP	ABAP Workbench
> S_RFC	Authorization Check for RFC Access	
> S_RZL_ADM	CCMS: System Administration	
> S_TRANSPRT	Transport Organizer
> 
> 10. Before you generate the role disable the above authorisation objects except S_DATASET, S_RFC and S_RZL_ADM (if you are not using CCMS).
> 11. Generate the role and test it out. This works...
> 
> I have tested it successfully.
> 
> Thanks and Regards
> 
> Arun R

The downside of that approach is that the role will no longer be SAP_ALL without STMS...disabling those other objects will also remove access to a whole load of other functionality.

[Former Member]

Hi

That is his requirement. Yes, I agree disabling those other objects will also remove access to a whole load of other functionality.

We are disabling only the objects related to the STMS. He would face some problem when he executes the batch process and apart from that there will be no issues.

Thanks and Regards

Arun R

[Former Member]

>

> We are disabling only the objects related to the STMS. He would face some problem when he executes the batch process and apart from that there will be no issues.
> 
> Thanks and Regards
> 
> Arun R

Hi Arun,

Inactivating S_DEVELOP will cause many, many more problems if you have a user requiring almost SAP_ALL access.

[Former Member]

Yes, We should not deactivate S_DEVELOP.

I agree to this.

We can deactivate the following which will not have any impact on the other transactions:

S_BTCH_ADM Background Processing: Background Administrator

S_BTCH_JOB Background Processing: Operations on Background Jobs

S_CTS_ADMI Administration Functions in Change and Transport System

S_TRANSPRT Transport Organizer

Thanks and Regards

Arun R

Edited by: Arunachalam Ramanathan on Dec 5, 2008 7:51 AM

[Former Member]

Thanks all.

I do what you suggest:

1. Create a new role

2. Choose templete from SAP_ALL

3. Inactive authorization:

S_CTS_ADMI

Then I got "You have no authorization...." when use T-code STMS.

[Former Member]

You need to disable the authorisation object S_TRANSPRT also.

Please disable that also.

[Former Member]

It depends on how you have setup your STMS, and also defined the QA steps. These will determine check checks are performed by the system (actually, in which system they are performed as well).

Cheers,

Julius

[Former Member]

Hi Julius,

I have always been advised by teachers and other sap authorizations consultants to not directly modify SAP_ALL. Rather to copy or create a new role using it as a template, since it's SAP delivered and a sensitive authorization.

You are 100% correct that it usually won't cause issues, and can be regenerated. I was mostly just mentioning it as a reference to best practices.

Thanks!

-Ben

[Former Member]

Perhaps it is just folk-lore... like removing a tcode from SAP_ALL will be SAP_ALL minus a whole application component....

[Former Member]

>

> I have always been advised by teachers and other sap authorizations consultants to not directly modify SAP_ALL.  Rather to copy or create a new role using it as a template, since it's SAP delivered and a sensitive authorization.

Hi Ben,

The more time I spend in security the more I realise that most people's idea of "best practice" is what they think/make up ( It's not a reference to this thread though )

Cheers

Alex

[Former Member]

Which part of the STMS do you want to restrict?

The STMS is not just a "transaction". It is a "system" on it's own which has almost nothing at all to do with the transaction code.

Please tell us what you want to achieve, not about transaction codes.

Cheers,

Julius

[koehntopp]

I have a hard time believing that removing STMS but leaving in several 10000 TCodes + Objects will do any good at all. What a crap idea....

I'm getting too old for this....

Frank.

[Former Member]

> I'm getting too old for this....

Perhaps a nice relaxing weekend will cheer you up...

[Former Member]

>

> I have a hard time believing that removing STMS but leaving in several 10000 TCodes + Objects will do any good at all. What a crap idea....
> 
> I'm getting too old for this....
> 
> Frank.

Frank, it's not the age, it's repeating that mantra!

[jurjen_heeck]

> Frank, it's not the age, it's repeating that mantra!

Spot on!

[Former Member]

>

> > Frank, it's not the age, it's repeating that mantra!
> 
> Spot on!

I agree as well. It can get tedious.

Although it is nice to help people realize that there is more to SAP than just tcodes and SAP_ALL and learn a thing or two along the way, I don't see how we can combat this without forcing a comprehensive search (or training) before being able to post.

Another option would be to disable the S_TCODE object completely in the standard system and see what happens...

Cheers,

Julius

[Former Member]

>

> 
> Another option would be to disable the S_TCODE object completely in the standard system and see what happens... 
> 
> Cheers,
> Julius

You'll be telling people to start using SU02 next

[Former Member]

Hi,

Why dont you create a role with reference to SAP_ALL and remove STMS transaction from the S_TCODE object. Initially the value will be *.

Disabling the other object could create problem from performing other tasks.

Thanks and Regards,

Amit.

[jurjen_heeck]

> Why dont you create a role with reference to SAP_ALL and remove STMS transaction from the S_TCODE object.

Bwahahahaa! You've made my friday! I hope you protect your personal belongings with a bit more serious measures. OMG! ROTFLMAO!

[Former Member]

Hi Amit

If we provide SAP_ALL, the value for the authorisation object would be * rather than transactions entered in.

Test it out by giving SAP_ALL and confirm what values are assigned for the authorisation object S_TCODE.

Thanks and Regards

Arun R