Deactivating S_TODE Object in a large number of Roles

[Former Member]

Hi Experts,

Is there a way to automate the process of deactivating an authorization object from a large number of roles. there is a requirement of deactivating S_TCODE object from a large number of roles. I think eCatt Script cannot be used for this. Is there any other way to automate this process. This is a burning requirement, please suggest a possible solution if there is one for this case.

[Former Member]

Are S_TCODE added manually to the roles and have wildcarded transaction codes in them ? is that the reason, you need to remediate them. Not sure if deactivation is good idea even if they are added manually. You might to investigate further before you deactivate it from the roles. Like what access these are giving to users and do they really need it or not. Then if they need them they should be added to a proper role before you remove them else you will flodded with authorization issue errors.

If S_TCODE is coming up as STANDARD then I do not understand why you want it to be deactivated. S_TCODE is the first check that a transaction does and if you deactivate them, users will start getting error message that they are not authorised for the transactions that they have in their role.

[jurjen_heeck]

If you want to deactivate all instances of the S_TCODE object in a set of roles (which to me seems a strange requirement) you can consider tweaking a PFCG download file.

Firstly, create a copy of one of the roles you want to change, deactivate S_TCODE in the copy and download both the orginal and the copy to separate files. (these are text files)

Now look at the difference between the two downloade textfiles to see which lines you need to manipulate and how.

Download the whole set of roles and copy the downloadfile for safekeeping.

Edit the downloadfile, upload (preferably to a sandbox client at first) and generate the profiles.

As editing download files is not SAP standard nor encouraged by SAP in any way this is at your own risk. That's why you need to keep the original file just in case you mess up.

Jurjen

[Former Member]

I agree, whilst this is not SAP standard or recommended.

If you de-active that S_TCODE object the users with these roles will not be able to run any transaction codes. (Let's hope these users have other roles).

The eCATT option is a no go as it is not safe enough.

The only realistic (NOT recommended) option is to download said roles into a file and edit the file to remove the S_TCODE items and then upload the roles from this edited file. Ensuring that you copy these roles first to have as a failsafe back up if your edit renders the roles irreversibly damaged

Good luck - let us know how you get on.

[Former Member]

Hi,

This process is a part of the SOD checks. We are going to deactivate S_TCODE from the master roles as they are giving access to a large number of unwanted t-codes as well and as per the design we will create seperate roles that have only S_TCODE object having only those transactions that are contained in the baseline entitled to the user.

Please explain the process in detail as I havent done it before.

Thanks!

[Former Member]

> ... and as per the design we will create seperate roles that have only S_TCODE object having only those transactions that are contained in the baseline entitled to the user.

But then they get the tcode anyway, or what?

You should not distroy your roles and the relationship between the tcodes and the standard authorizations for them just for the sake of SOD.

SOD is more than 90% about the application authorization objects and their values. S_TCODE and other entry points (S_RFC, S_SERVICE, FTP, etc...) are only a fraction of the control and you will never find them all to include in a conflicting function.

If the requirement is that the roles themselves should be free of SOD's, then do a proper job of building them with some smaller "special function" roles which can be used on their own as well. That way you leave the assignment of the roles to the business approvers, and the option of an Emergency User concept for the special task is enabled as well.

Cheers,

Julius

[Former Member]

Yes you are right Julius, this is probably not the best approach. But this will help us reduce our violations to large extent. We would deactivate S_TCODE object from our existing single roles that are assigned to users inside there respective composites. We would then create new single roles with S_TCODE object and only these t-codes that the users are authorized to access as per the mapping given by the business. This way although all the objects would be there in the single roles of the composites but the users will be able to access only those t-codes that are present in the new role created with S_TCODE only as from all other roles we would have deactivated S_TCODE.

[Former Member]

That is quite sad actually. Why not invest a bit more time to fix the real problem?

I hope I never have to do any subsequent maintenance on this system's roles...

Cheers,

Julius

[Former Member]

Hi,

This one is done. Theres one more problem, whats the way to add field values in Auth Objects. I have a lrage number of roles where I have to add some field values. Is there a way to automate this other than using the download role option?

[Former Member]

>

> Hi,
> 
> This process is a part of the SOD checks. We are going to deactivate S_TCODE from the master roles as they are giving access to a large number of unwanted t-codes as well and as per the design we will create seperate roles that have only S_TCODE object having only those transactions that are contained in the baseline entitled to the user.

Please, please, please do NOT do this.

If this approach is being proposed by a consultancy then this is bodering on being negligent and should pay for the remediation that will occur.

If this approach is being proposed by internal people then for mercy's sake get them some training as this is very poor practice. Auditors often miss many things but I really hope they use their powers to tear this apart for being an awful idea that will do nothing to improve real segregation of duties.

[Former Member]

>

> Yes you are right Julius, this is probably not the best approach. But this will help us reduce our violations to large extent. 

No it won't. It will potentially hide violations at a tcode level so improve the reporting of defects. It is the auth objects that have the greatest control and is what you should be concerned about, not S_TCODE.

[Former Member]

> Theres one more problem, whats the way to add field values in Auth Objects. I have a lrage number of roles where I have to add some field values. Is there a way to automate this other than using the download role option?

You keep the S_TCODES in the menu intact with the standard and maintained authorizations of the role, and then change them in SU24.

By the sounds of it, it is too late for that. Go figure why I will steer well clear of your system..

Cheers,

Julius

[Former Member]

This sounds like a bad idea - I see where you're going with this. In the end, you hope to have one role with the tcodes that should be given, and another role with the authorizations that will allow that tcode to run.

Unfortunately, this will lead to a lot of issues in the future, because you won't know which objects are required by which transactions. You are better off doing a role redesign that will adjust the roles, or create new roles with transactions that are required and remove everything else.

I would suggest that if you are trying to add tcodes to a new role, then instead of adding it to S_TCODE, just go the menu route, so that the appropriate objects will get pulled in. You can then match the auth values from the original role into this new role so that those tcodes can work properly, and then only remove those tcodes from the old role.

Good luck.

Santosh

[Former Member]

> Unfortunately, this will lead to a lot of issues in the future, because you won't know which objects are required by which transactions.

Exactly. This is a scandal and if the customer knows how to manage the quality of roles then Rasheed will be in big trouble.

Either way, Rasheed will most likely have hot-footed it out of there by the time some other poor sod has to clean up the mess or apply support packs or upgrades of the system.

Probably the only way to make it look as if it is solved is to wrap composite roles around the mess, and thereby make it worse.

This thread is a real shame if the roles were intact before it happened...

Cheers,

Julius

[Former Member]

Hi Guys,

Relax! Take a breath! Julius I guess we too have thought for all this and I already acknowledged that this was not a good desgin strategy. So to make you aware, this a solution we have deviced to work on the proper fix in the background as the amount of violation were huge given the number of role and users.

On the front end this solution will not allow anybody to access anything extra and meanwhile we will be working on the original role and correcting the violations.

Anyways thanks to all of you for the inputs.

One thing more I wanted to confirm that if we have a transaction code in the menu and we have deleted it from the S_TCODE object inside the role how we stop this from showing up at the user menu?

[Former Member]

This message was moderated.

[Former Member]

This message was moderated.

[Former Member]

This message was moderated.

[Former Member]

What would calm me down is to see people who do this getting increasingly worried...

Anyway, it's your customer's problem now, not ours - you got your "solution" and they did warn you.

Cheers,

Julius

[jurjen_heeck]

> One thing more I wanted to confirm that if we have a transaction code in the menu and we have deleted it from the S_TCODE object inside the role how we stop this from showing up at the user menu?

For that you'll have to remove the transaction from the menu. Or delete the whole role menu.

[Former Member]

>

>So to make you aware, this a solution we have deviced to work on the proper fix in the background as the amount of violation >were huge given the number of role and users.

Why don't you just transition to the new design once it is ready for deployment (maybe taking a function by function approach)? Implement mitigating controls over the highest risks and don't waste time on this solution that does not remove SOD.

If this exercise is to purely to reduce the number of SOD's reported (they will still be there) then it will likely not be valid for a single audit cycle as it is acknowledged that a proper remediation is being planned. If the company auditors know what they are doing then this will get hammered and rightly so. Typically the auditors will look a lot more favourably if you focus 100% on the remediation and start phasing it in as appropriate than they will over what is just a bodge that does nothing to prevent segregation of duties from occuring.