Restrict authorization to SNOTE transaction

[Former Member]

Hi,

Our requirement is to give SNOTE transaction authorization to user with restricted authorizations(Display SAP Note & Check SAP Note).

We created one test Role with SNOTE Tcode and in authorizations we deactivate/deleted all the objects except S_Tcode(=snote), created one test user and assigned to this Role.

But Still User is having all the access to SNOTE transaction(implement,Reset SAP implementation ...)

Role is created only with SNOTE transaction and User is assigned only this role.

Still why the user is getting all the authorizations of that T Code.

Can any one help on this.

Thanks & Regards,

Raj

[Former Member]

Hi,

Our requirement is to give SNOTE transaction authorization to user with restricted authorizations(Display SAP Note & Check SAP Note).

We created one test Role with SNOTE Tcode and in authorizations we deactivate/deleted all the objects except S_Tcode(=snote), created one test user and assigned to this Role.

But Still User is having all the access to SNOTE transaction(implement,Reset SAP implementation ...)

Role is created only with SNOTE transaction and User is assigned only this role.

Still why the user is getting all the authorizations of that T Code.

Can any one help on this.

Thanks & Regards,

Raj

[jurjen_heeck]

Basically the two ways in which authorizations do not function in the desired way can be tackled in the same manner:

If someone can do too much run the process alongside an ST01 trace to see which checks are actually performed. If a user passes checks which he/she really should not pass based on the actual authorizations in the UMR have a look in SU24 for checks that are switched off.

If Someone can't do enough, trace with the existing authorizations and see which ones fail. Be aware of authorizations that are not vital to the process but only steer screens and fields.

So, when I answer such a question, like the one on SU3 earlier today ( ), I switch on my trace and start the transaction. At the moment I'm both too busy and too lazy so you'll have to do it yourself.

Cheers!

Jurjen

[Former Member]

Hi Jurjen,

We already gone through the steps( ST01, SU53,SU22,SU24...).

But It didnot help.

Still User is getting all the authorizations of transaction SNOTE.

Raj

[jurjen_heeck]

In that case it may well be that there are no extra checks to support restrictions within SNOTE, Some of the technical transactions behave that way, it's all or nothing.

[Former Member]

Hi,

It has been resolved by creating one cust T code with restricted authorizations

Raj

[Bernhard_SAP]

Hello Raj,

just another comment....

I tried waht you have described. My testuser fails in SNOTE as soon he wants to implement the note at the point, where a transport shall be created/used. If the user has no such s_transprt authorization, he will not be able to implement/undo notes(implementation).

b.rgds, Bernhard

[Former Member]

Hi Bernhard,

I tried with a new user who is having only this SNote authorization that too deactivating all the authorization objects of Snote t code.

Still the user is able to implement SAP note.

Raj

[jurjen_heeck]

> Still the user is able to implement SAP note.

This makes me curious about the client settings in the system where you tried this. Do changes trigger transports at all?

Bernards' post makes sense to me in a 'normal' landscape.

[Former Member]

No, It is not triggering transport

[jurjen_heeck]

Ah!, in that case you are right in stating you cannot create a read-only SNOTE assignment for users.

In an SAP-standard (as far as I know) productive environment however, one would implement notes in a development system that is set to automatically record changes i.e. trigger transports. The implementation is then transported through the landscape.

With that in mind you can allow people to start SNOTE but by denying them the right to create or modifiy transports they cannot really implement a note, as Bernard stated.

[Former Member]

Hi,

We are testing this authorization in Development only

Raj

[jurjen_heeck]

> We are testing this authorization in Development only

So now you've found the impact of system settings on your authorization concept

Nice example.