Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Need to remove STMS from profiles - s_a.develop, s_a.system, s_a.customiz

Former Member
0 Kudos

We need to remove access to transaction STMS from a few profiles.

Ex:

s_a.develop

s_a.system

s_a.customiz

& others

What's the best way to accomplish this.

I know for ex: s_a.system under s_tcode it has *

I know for ex: s_a.develop under s_tcode it has a-st, su3, su5, sv-z*

Could i just change them to

a* - stl* , stn* - stz, st0 - st9* , t- z

Thanks

Joe

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Joe,

I have taken the liberty of marking this question as unanswered again, as it is by no means answered even although you have very usefull responses from Jurjen and Zaheer about the SAP delivered profiles.

Just to clear the SAP profiles issue (which includes SAP delivered roles) these are to my knowledge built while testing the applications (and others for negative testing them). They are not transaction specific and as you might notice they are also "manually" and "changed".

But SAP throws them in for you to use if you are not willing to make a bit of effort of your own.

So... STMS....

First, you must realize that STMS is not a transaction. It is also not an application on it's own either. It is a system which has the capability of managing and technically transporting changes to objects and even transaction data throughout a landscape for systems controlled by the domain controller (ideally the production system) which has the capability of checking where the transport is approved from (approval steps defined in the QA system).

If setup correctly, it requires user interaction (and authentication) with the correct authority (primarily S_CTS_ADMI and S_TRANSPRT for more granular checks, and others as well (depending on how you manage change management (the CTS - Change and Transport System).

It has nothing to do with S_TCODE (as far as security is concerned) and you need to accept that fact. I recommend that you first inform yourself about how (and whether) the STMS is setup at all...

It cannot be excluded that your developers are taking the piss out of you.... and your auditors are a waste of money if they are happy with ranging around S_TCODE to become invisible to some audit tool...

Some tips:

- Check the authority of user ID TMSADM in client 000. If SAP_ALL, then you are toasted.

- Check the user type of TMSADM in client 000. If "Communication" then you are toasted.

- Check that the STMS domain controller is the production SID, otherwise you are toasted.

- Check that the backup controller is the QA system and the QA steps are flagged, else toasted.

- Check S_CTS_ADMI authority in all systems... they are most likely the toasters......

- Check a number of other fine tuning stuff...

Sorry for what might appear to be harsh answers, and I understand from your comments that you have been thrown in the deep end there and have a tough job.

But you will find help and support here, and quick-and-dirty is not a valid reason to close the thread here and settle for less which is way below the security bar.

Please reconsider your question and the answers, and search service.sap.com and talk to you basis folks about it and then take your time to discuss and close the thread properly once you are happy.

It may take a while, but that is okay. We will help you where we can.

Cheers,

Julius

ps: Please also use the search before asking (preferably more) detailed questions. Eg "user TMSADM" is a good start.

5 REPLIES 5

jurjen_heeck
Active Contributor
0 Kudos

> We need to remove access to transaction STMS from a few profiles.

Oh, great, another one that thinks S_TCODE is the best security measure......

> I know for ex: s_a.system under s_tcode it has *

So, these are SAP profiles, why use them anyway? Take them away from your users if their authorizations are too wide.

What's so wrong with proper security design and implementation?

> I know for ex: s_a.develop under s_tcode it has a-st, su3, su5, sv-z*

> Could i just change them to

> a* - stl* , stn* - stz, st0 - st9* , t- z

Yep, that would leave everything working but not as desired. Please tell us what you are trying to accomplish, give us your problem instead of the solution you've come up with. It's not going to work, trust me.

0 Kudos

Jurien

Auditors are asking us to remove STMS from abapers.

Abapers have S_a.system , s_a.develop & other profiles assigned to their userid.

I have not been to any Security classes and I'm learning this the hard way.

THis is on the job training with no other Sap security person available to ask question.

Thanks

Joe

0 Kudos

Yups, that really a hard way.

Actually Auditors wants to have a restricted access for developer and which is accomplish able with custom roles development where you can have better control.

Using SAP default profiles itself is not a good approach. You create a custom roles with the help of some developers and then replace the SAP profiles with the new restricted custom roles.

This will make the Auditors happy... if this is what you are trying to achieve

Cheers !!

Zaheer

0 Kudos

Hi Joe,

> Auditors are asking us to remove STMS from abapers.

> Abapers have S_a.system , s_a.develop & other profiles assigned to their userid.

There's the base of your problem. Your auditors are not aware of the fact that abapers with the proper autorizations to do their development work on a dev system can bypass almost any authority check they want.

Have your auditors specify what they will allow abapers to do and on which system. Trying to set up authorizations by denying rights is the wrong way around. What you really need is proper roles for your developers. They should not need any of the mentioned profiles. There's no magic in those. Really.

> I have not been to any Security classes and I'm learning this the hard way.

Prepare for a lengthy period of learning after which you will ony know how to fool your regular auditors (and they do not appear to be very bright) but not how to really secure an SAP system.

> THis is on the job training with no other Sap security person available to ask question.

Demand at least SAP courses ADM940 and ADM950. Preferably ADM960 as well. The last one will give you a clue about the uselessness of roles and profiles if the back end is not properly secured. The first course is a real must. There's no way you're going to find it all out by yourself in a reasonable amount of time. This forum is not a substitute for training.

For the mean time, hire an SAP security consultant who'll help you set up shop and really train you.

I whish you lots of luck, you're going to need it.

Jurjen

Former Member
0 Kudos

Hi Joe,

I have taken the liberty of marking this question as unanswered again, as it is by no means answered even although you have very usefull responses from Jurjen and Zaheer about the SAP delivered profiles.

Just to clear the SAP profiles issue (which includes SAP delivered roles) these are to my knowledge built while testing the applications (and others for negative testing them). They are not transaction specific and as you might notice they are also "manually" and "changed".

But SAP throws them in for you to use if you are not willing to make a bit of effort of your own.

So... STMS....

First, you must realize that STMS is not a transaction. It is also not an application on it's own either. It is a system which has the capability of managing and technically transporting changes to objects and even transaction data throughout a landscape for systems controlled by the domain controller (ideally the production system) which has the capability of checking where the transport is approved from (approval steps defined in the QA system).

If setup correctly, it requires user interaction (and authentication) with the correct authority (primarily S_CTS_ADMI and S_TRANSPRT for more granular checks, and others as well (depending on how you manage change management (the CTS - Change and Transport System).

It has nothing to do with S_TCODE (as far as security is concerned) and you need to accept that fact. I recommend that you first inform yourself about how (and whether) the STMS is setup at all...

It cannot be excluded that your developers are taking the piss out of you.... and your auditors are a waste of money if they are happy with ranging around S_TCODE to become invisible to some audit tool...

Some tips:

- Check the authority of user ID TMSADM in client 000. If SAP_ALL, then you are toasted.

- Check the user type of TMSADM in client 000. If "Communication" then you are toasted.

- Check that the STMS domain controller is the production SID, otherwise you are toasted.

- Check that the backup controller is the QA system and the QA steps are flagged, else toasted.

- Check S_CTS_ADMI authority in all systems... they are most likely the toasters......

- Check a number of other fine tuning stuff...

Sorry for what might appear to be harsh answers, and I understand from your comments that you have been thrown in the deep end there and have a tough job.

But you will find help and support here, and quick-and-dirty is not a valid reason to close the thread here and settle for less which is way below the security bar.

Please reconsider your question and the answers, and search service.sap.com and talk to you basis folks about it and then take your time to discuss and close the thread properly once you are happy.

It may take a while, but that is okay. We will help you where we can.

Cheers,

Julius

ps: Please also use the search before asking (preferably more) detailed questions. Eg "user TMSADM" is a good start.