regarding deleting auth object

[Former Member]

Hello gurus,

I need to delete an auth object which is in 53 roles in development system. I tried searching regarding the deletion of auth objects in this forum i didnt find it. Could any one tell me the procedure how to delete the auth object which is present in 53 roles.

Thanks

[Former Member]

Hi,

Why do you want to delete the object from 53 roles?

Objects are pulled when you add an tcode to the role and if its an customized tcode then you need to set su24.

I am afraid to say that you need to delete the authorization object from each role manually.

There is no standard way to delete an authorization object from many roles.

Short note: If you have impleted GRC then you have some options of mass changes to the roles through Role Expert

Rakesh

[Former Member]

Hi Avinash,

You'll need to go into each of the 53 roles from where you want to delete the auth.object.

Go to the authorization tab of each of the roles.

Find the auth. object which you want to delete and then look for an icon with a red line next to the traffic light and click on it.This will make the object inactive and the trash icon will then appear beside it.You can then delete the auth. object by clicking on the trash icon.Then save and generate the profile again.After the changes to the individual roles have been made you can mass transport all the 53 roles at once from DEV to other systems in your landscape.

Note:It is never recommended to delete an auth. object from the role this way.If the auth. object is not required then u can just make it inactive.There is no way you can mass delete an auth. object from 53 roles at once unless u r using GRC.

Thanks,

Saby..

[Former Member]

I understand that your question is answered, but wanted to add a little comment (although I don't know which type of system you have, nor release nor what the name of this auth object is.... so this is a "shot in the dark":

If your roles have been built in the way SAP intended roles to be built (maintaining roles via the menu), then it might be possible for you to identify which transaction (for example) was the "culprit" to have pulling this object in, even although you did not (or now do not any longer) want it in any role which contains it for that reason.

You should check whether these 53 roles have authorizations generated as "standard" or "maintained" (not "changed", or "manually"). Check that no other role with this authorization is dependent only on this transaction to retain the standard or maintained authorization value (or know this from the documented use case of the transaction).

If sy-subrc = 0 still... go to SU24 and remove the check indicator for the menu transaction(s) causing this authorization to be concluded by leaving "check" only.

Then open each of the 53 roles once only, and select "Read Old, Merge New Data" from the expert menu and regenerate.

Manual authorizations will not be touched.

Changed authorizations will not be touched.

Deactivated authorizations will not be touched.

However any > 54th roles which have this standard authorization only from the above (no longer desirable) transaction and should keep it, will be your (or someone else's)mess to sort out when you upgrade and the lights turn yellow.

If you already have a lot of manuals and changed authorizations, then rather don't do this. It either need to be done properly, or not at all AFAIK (BW folks will be hard to convince...).

A carefull choice of transaction combined with good SU24 data and avoiding manual inserts as much as is possible helps a lot to avoid a mess (and subsequent consequences).

Sorry for the rant, but I could not resist

Cheers,

Julius

[Former Member]

Agree with your comment Julius!!!

Its all how good you maintain your su24 to reduce the clean up activities

Rakesh

[Former Member]

I have observed that many answers here assume that the (intended) authorization concept is trashed already.

Of course, that creates more trash and more mess for (others who have to perform) subsequent maintenance or upgrades.

Sadly, this also has enough weight to force SAP into providing (authorization protected) upload tools and and manual workarounds.

But if "basis" is only doing all security as a "hobby on the side", then you will get what you asked for...

Perhaps SDN should host a "Hall of Shame"...

(just joking)

Cheers,

Julius