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: 

Remove S_ALR_87004092

Former Member
0 Kudos

Friends,

I will need to remove the S_ALR_87004092 from Role.

Unfortunately The role has been assigned the S_ALR_* in the S_TCODE.

What range should I put to remove this T code in S_TCODE?

From

Pranav

Edited by: Pranav Thaker on Jan 26, 2010 6:38 PM

1 ACCEPTED SOLUTION

Former Member
0 Kudos

I don't understand why people take such bait for ranging S_ALR type tcodes or wildcarding them. It is just lazy or not properly trained.

Generally they will be hanging in a report tree (take a look at SUIM for example) so just maintain them accurately in SU24 for the trees which you do use and let them be invisible to the menu and automatically populated for your roles in PFCG.

What I normally do is take a look at the favourites of the user and compare this to the actual usage. For example, the navigation path to RSUSR002 and 070 are too long for me considering how often I use them, so I have them directly in the menu as well.

If the user has more than 10 of them, then they are probably not using them anyway or do not know how to. Let alone 15 thousand of them....

Just get the correct values and maintain SU24. It is not difficult, they don't really use much and you only need to do it once.

My 2 cents,

Julius

14 REPLIES 14

jurjen_heeck
Active Contributor
0 Kudos

Between which two other numbers do you think '2' is? And why would that be different in SAP compared to the outside world?

0 Kudos

I do not understand your point. Can you please explain what are you referring to.

The T code is S_ALR_87004092 and It is showing up in SM01.

Pranav

_________________________

Former Member
0 Kudos

I don't understand why people take such bait for ranging S_ALR type tcodes or wildcarding them. It is just lazy or not properly trained.

Generally they will be hanging in a report tree (take a look at SUIM for example) so just maintain them accurately in SU24 for the trees which you do use and let them be invisible to the menu and automatically populated for your roles in PFCG.

What I normally do is take a look at the favourites of the user and compare this to the actual usage. For example, the navigation path to RSUSR002 and 070 are too long for me considering how often I use them, so I have them directly in the menu as well.

If the user has more than 10 of them, then they are probably not using them anyway or do not know how to. Let alone 15 thousand of them....

Just get the correct values and maintain SU24. It is not difficult, they don't really use much and you only need to do it once.

My 2 cents,

Julius

0 Kudos

Julius

We are trying to clean up the mass from <removed_by_moderator> Consultant after the implemetation to reduce the SODs.

Can you please describe in steps whatever you are recommending from your experience?

Thanks,

Pranav

Edited by: Julius Bussche on Jan 26, 2010 10:04 PM

0 Kudos

I don't understand?

My above post explains what I do and it works. An "intensive care" phase after the changes is usefull as well.

You should not range tcodes and authorization fields just to make audit reports go away....

Do it properly, then you only need to do it once and will not have holes in your security.

There are thousands of tcodes in that range. They auditors will find yet another one to pester you with next time....

If you fix the tcode (and RFC and services) entry points, then it makes sense to fix the authorization to actually use them as well and propose usefull values from SU24 as you go alone.

Take a look in the FAQ thread at the top of the forum for the various discussions about SU24. That is what you need and is the "best in class" approach to take.

Cheers,

Julius

0 Kudos

> I don't understand why people take such bait for ranging S_ALR type tcodes or wildcarding them.

I'm sorry Julius, I just couldn't withstand the temptation here.

It was all about working out a set of ranges considering the logical order of the ASCII table and the decimal numbering system, not about wildcarding or ranging S_TCODE.

@Pranav

How difficult is it to come up with:

S_ALR_00000000 - S_ALR_87004091

S_ALR_87004093 - S_ALR_99999999

Just do the math....

Disclaimer: As stated by Julius, this has nothing to do with SAP security.

0 Kudos

> How difficult is it to come up with:

> S_ALR_00000000 - S_ALR_87004091

> S_ALR_87004093 - S_ALR_99999999

> Just do the math....

Also just take a look in TSTC at how many transactions start report SAPLS_CUS_IMG_ACTIVITY and do similar or more critical activities.

In an ECC 6.0 system with several extentions and industry solutions installed, I have 55515 (fifty five thousand five hundred and fifteen) of them...

Minus S_ALR_87004092 leaves 55514 for the auditor to pick a sample from next time.

--> Do the math on that to work out how long the auditor is going to be in da house ...

Cheers,

Julius

0 Kudos

> --> Do the math on that to work out how long the auditor is going to be in da house ...

Auditors need to eat as well

0 Kudos

Yeah, but soon the auditor will look like Mr. Creosote and Pranav like Mr. Bean...

Rather avoid that! -> SU24...

0 Kudos

Thanks Jurgen

Appreciated your help with short and concise response to my question.

Thanks again.

From

Pranav

0 Kudos

Keep us posted over the years about which transactions the auditor wants next time...

Cheers,

Julius

0 Kudos

> Appreciated your help with short and concise response to my question.

There's always this thin line between directly answering a question and really helping people along. They sometimes even collide, like in this case. Do take Julius' advice as well. If the solution I gave you satisfies the auditors they actaully are no good.

0 Kudos

Will do.

Also, I will let External Vendor Consultant know via email as well for adding

Ranges (S_ALR_*) in Roles and profiles for S_TCODE during implementation before auditors comes on board and not following the best practice.

My job is to keep my job by fixing issues and let my Compliance Team know the wonderful work done in the past by external

highly paid SAP Contractors.

I am sure Julius understands.

From

Pranav

0 Kudos

Though you might want to check the implementation documentation before ranting further.

Sometimes the functional consultants or the customer do not deliver the information needed or instruct you to pop a * or range or wildcard into a field so that they can go live.

It is the job of security to warn them of the consequences but not make decisions for them.

Whether or not that was the case here I don't know, but "highly paid SAP consultants" do also get kicked around a lot

Cheers,

Julius