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: 

Not add authorization objects that exist in role when adding transaction

Former Member
0 Kudos

Hi All,

Is there an option existing in SAP that:

when adding a transaction to a role (or edit existing role) and the authorization objects for this transaction have been maintained in the role, the system should not be adding again the 'standard' SU24 values in the role (which we should then again 'inactivate').

Kind regards,

Kristof.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

For example:

Imagine you have an administrator role to with transactions SCC1, SCC4, SE16 added via the role menu.

The SU24 for these transactions considering object S_TABU_DIS:

SCC1

ACTVT 02

ACTVT 03

DICBERCLS SS

SCC4

ACTVT 01

ACTVT 02

ACTVT 03

DICBERCLS SS

SE16

ACTVT 03

DICBERCLS

But in the administrator role, I want to give S_TABU_DIS with ACTVT = * and DICBERCLS = *.

By doing this and editing the role in 'edit expert mode: read old version and compare new objects', I will get the 3

different instances in from the SU24 for the 3 transactions from above (and an instance with my ACTVT = * and DICBERCLS = *).

By I would only like to have the instance with ACTVT = * and DICBERCLS = * so I inactivate all the other instances, resulting in a large list of inactive objects.

> can I conclude that for administrator roles, it is best not to add the transactions via the menu of the role, but instead adding all the relevant objects manually.

In this example:

Add

S_TCODE: SCC1, SCC4, SE16

S_TABU_DIS: ACTVT = * and DICBERCLS = *

(+ all the other objects related to SCC1, SCC4 and SE16)

thanks

18 REPLIES 18

Former Member
0 Kudos

Hi Kristof.

You can edit the role in expert mode (it is an option in the authorisations tab of the role). I believe there is an option "edit old status".

This will treat the symptoms, but usually this happens because the objects are in "changed" mode as SU24 has not been considered during the role build.

Former Member
0 Kudos

Hi Kristof,

If you want to make any changes to the standard instances which are pulled by SU24 (First time) , then its always a good practise to inactive that standard instance and manually add the instance --> maintain the field values as required.This will result in two instances one it standard(inactive) and the other is Manually added (Active).

If you make any changes to the standard instance then it will change that instance status from Standard to Change or Maintained. This will result in just one instance which is Change or Maintained hence the next time if you open the role in the change mode then it will again pull the standard instance of that object as it was found missing in the role.

Former Member
0 Kudos

> .... the authorization objects for this transaction have been maintained in the role.

It is adding them for different transactions in S_TCODE, which may or may not be related to the menu transactions.

Click on the icon which looks like "the Alps in the early morning with the sun rising in the background" and you will see the transactions and which values they pull in.

If you dont want them, then either remove the values from the proposal indicators in SU24 or maintain them consistently.

If they are pulled in as "standard" with blank or duplicated values, then see this thread:

Cheers,

Julius

Former Member
0 Kudos

Another "common mistake" is that you deleted the standard authorization earlier. When subsequently opening the authorization data it does not know this anymore, so pulls it back in again.

Your options are described in [SAP Note 113290|https://service.sap.com/sap/support/notes/113290]

I sometimes wonder what that "Delete" button could possibly be good for in a standard authorization.. and am still looking

Cheers,

Julius

0 Kudos

I sometimes wonder what that "Delete" button could possibly be good for in a standard authorization.. and am still looking

Agreed

I am not infront of the system, but if I am not wrong when a standard authorization is deleted, even if the role is not being pulled in expert mode, "that" standard authorization comes back if any Tcode is added to that particular role menu and role generated in change mode. - Creating more headache for that auth maintainance which is no where related to the Tcode which was added.

0 Kudos

It will also re-appear if you do a "Read old + merge new" in Expert Mode, which is exactly that which you should ideally be trying to do.

Let see what the feedback is.

Cheers,

Juius

0 Kudos

Hi,

What Julius wrote before is the way of working. I myself, if the role is large or very critical, will make a copy and see what is happening. You can get a lot of information of the status of the objects what is in front of the object when you get in the authorizations. You see new, old, maintained, etc. You can compair the roles in SUIM (the copied one and the one you are working on) and see what is happening. It takes some time, but can be very handy.

Have fun

Bye Jan van Roest

Former Member
0 Kudos

Thanks for your replies.

Is it normal that "administrator" roles are then overloaded with 'inactive standard objects' ?

For administrators, the objects that are coming with a particular transaction are sometimes put to full authorization (with * values) and the value from SU24 are in this case neglected. This means that when such role will be taken in 'edit expert mode', the standard objects will be added again with the values from SU24. Resulting in roles where you have 10 inactive standard objects and 1 active with * authorization...

0 Kudos

For administrators, the objects that are coming with a particular transaction are sometimes put to full authorization (with * values) and the value from SU24 are in this case neglected.

Can you give an example of such a transaction?

Also check in SU25 whether you have setup the PFCG + SU24 correctly (step 1). Do not run it now again!

It still sounds to me as if you are deleting the authorization and the transaction is infact a parameter transaction with unmaintained SU24 values. In this case it pulls the core transaction´s values - but these are generally not * values. Often the fields are empty.

This means that when such role will be taken in 'edit expert mode', the standard objects will be added again with the values from SU24. Resulting in roles where you have 10 inactive standard objects and 1 active with * authorization...

One of the first things I do when setting up the system (or the PFCG) is that I go through SU24 and make some corrections. It takes about 2 or 3 days but then are not bothered by these objects again.

You can still refer to SU22 if you change your mind. Document it well for when you upgrade, otherwise SU25 will be a hassle...

Cheers,

Julius

0 Kudos

>

> One of the first things I do when setting up the system (or the PFCG) is that I go through SU24 and make some corrections. It takes about 2 or 3 days but then are not bothered by these objects again.

>

> You can still refer to SU22 if you change your mind. Document it well for when you upgrade, otherwise SU25 will be a hassle...

>

> Cheers,

> Julius

Julius,

this is away from the discussion but, could you tell us what are the initial corrections that can be made in SU24? . are these corrections for the custom trasactions or is it for the standard ones too, any input on this could be very helpful

0 Kudos

<pre>Some important objects and checks which I generally do are:

1) Verify step 1 in SU25.

2) Verify any changes which might have been made to SU22, and transfer them to SU24.

3) Verify that DEV, QAS and PROD have the same SU22 and SU24 status and where the

"leading" difference is.

4) Analysis of AGR_1251 to see what the potential impact will be of SU24 changes on existing roles.

- Standard... hurray!

- Maintained... good, but they are the main risk for adding values to SU24.

- Changed... symptom of unwanted or incomplete SU24 data and bait for dodos.

- Manually... will not be impacted but should not be a crow's nest.

- Empty without deaktivation... the dodos have already arived.

- Empty with deaktivation... okay, but should not be a crow's nest.

- Copied authorizations... okay, but verify that original is deactivated otherwise it will impact.

5) Remove ALL proposals for the following objects, as they are only to be granted explicitly:

- S_DEVELOP Remove all, and set SE11, 24, 38 and 80 to '03' only (without DEBUG!)

- S_USER* Remove all, and set SUIM to '03' and '08' activities.

- S_BTCH_ADM Remove all

- S_BTCH_NAM Remove all

- S_BTCH_JOB Remove all and set "RELE" as proposal for SMX - as required.

- S_CTS_ADMI Remove all

- S_LOG_COM Remove all

- S_RZL_ADM Remove all

- S_TOOLS_EX Remove all

- S_TRANSPRT Remove all and set SE10 to '03' only.

- S_LSMW Remove all

- B_MASS* Remove all

- S_ADMI_FCD Remove all

6) Remove ALL proposals for the following objects if empty fields are proposed or

if full access is proposed or maintain them correctly in some known cases.

- S_PROGRAM remove all empty proposals and *'s

- S_RFC remove all empty proposals and maintain known ones for FMs which will be used.

- S_IDOCMONI remove all empty proposals and set all others to u201803u2019 display.

- S_IDOCDEFT remove all empty proposals and exclude all delete and modify activities from others.

- S_TABU_DIS remove all empty proposals, or set all others to u201803u2019 display (also remove '01'...)

- S_TABU_CLI change all 'X' to ' '

- S_ARCHIVE remove all empty proposals and set all others to u201803u2019 display.

I also correct several other objects, but as there are many I only do this if the transaction

is infact used.

Keep an eye out for anything pulling in a star (full access) and empty fields for optional objects.

Do you want to start a wiki for this as well?

Cheers,

Julius<pre>

Edited by: Julius Bussche on Jan 13, 2010 3:38 PM

Formatting hobbled due to limit of characters.

0 Kudos

> Some important objects and checks which I generally do are:

Very usefull info Julius! Thank you, thank you, thank you, thank you, thank you!

May I suggest a sticky entry?

0 Kudos

The advantage of a wiki is that everyone can contribute to it...

I will add it to the sticky for now, until Shekar has his wiki up and running

Cheers,

Julius

Former Member
0 Kudos

For example:

Imagine you have an administrator role to with transactions SCC1, SCC4, SE16 added via the role menu.

The SU24 for these transactions considering object S_TABU_DIS:

SCC1

ACTVT 02

ACTVT 03

DICBERCLS SS

SCC4

ACTVT 01

ACTVT 02

ACTVT 03

DICBERCLS SS

SE16

ACTVT 03

DICBERCLS

But in the administrator role, I want to give S_TABU_DIS with ACTVT = * and DICBERCLS = *.

By doing this and editing the role in 'edit expert mode: read old version and compare new objects', I will get the 3

different instances in from the SU24 for the 3 transactions from above (and an instance with my ACTVT = * and DICBERCLS = *).

By I would only like to have the instance with ACTVT = * and DICBERCLS = * so I inactivate all the other instances, resulting in a large list of inactive objects.

> can I conclude that for administrator roles, it is best not to add the transactions via the menu of the role, but instead adding all the relevant objects manually.

In this example:

Add

S_TCODE: SCC1, SCC4, SE16

S_TABU_DIS: ACTVT = * and DICBERCLS = *

(+ all the other objects related to SCC1, SCC4 and SE16)

thanks

0 Kudos

If you are adding * values for S_TABU_DIS then you might as well add S_TCODE manually, and probably give it a * as well. The user can then add them to their favourites, or just remember the 3 tcode names.

Your security will be the same....

If the transactions become more complex and the user needs more granular access to control what they can do and what should remain "protected", then use the role menu and the SU24 proposals.

Your security will improve...

Cheers,

Julius

0 Kudos

> But in the administrator role, I want to give S_TABU_DIS with ACTVT = * and DICBERCLS = *.

That I find scary. Why do you want to open up your system so wide?

What will you do when S_DEVELOP is pulled into your administrators' role?

0 Kudos

The role might be for the DBA's who anyway might have access to all tables at that level?

If it only has this access, and no development access, memory management, etc from the application then it could still be in the ball park of reason.

I think display access should do most of the trick, but a few tables can be maintained from SE16 & SM30 and for the purpose of application table change logs and F4 search help this makes more sense than DB tools. They will enter the correct values, or find the missing ones.

So, I would split the S_TABU_DIS authorizations into 2: One for display (03) and one with explicit values for the groups with change (02).

> What will you do when S_DEVELOP is pulled into your administrators' role?

Now ex-DBA's with a boat skipper license... that is scary.. )

Cheers,

Julius

Former Member
0 Kudos

Thank you all for the information on this topic.