SU25 after system upgrade

[Former Member]

After system upgrade, many roles are reported to be processed to merge the new default authorization object in tcode SU25. Unfortunately, values are not maintained for many of them.

My understanding is that the new authorization object is required under new version. In old version, there is not this kind of authorization object, which means this authorization is not checked. So in the upgraded system, we can simply assing * to the missing value fields. The authorization control should keep the same as it before upgrade.

Any suggestion / comment?

Thanks

James

[shivraj_singh2]

James,

Please do not populate the open fields in new objects with *.

Look at the tcodes which are pulling in the new object and then depending upon what functional area that tcode belongs to, engage the functional person to guide what new values should be inserted. This is one way, there can be other methods also but inserting * is never a good idea from security point of view.

Regards,

Shivraj

[Former Member]

Understand * does not support good control.

There are 500 roles and many authorization objects should be determined with a specified value. We are looking for a quick win approach.

In addtion, it is a upgrade project, we do not want to change existing system behaviour.

How about assign a dummy value, ' ', to the business object field?

[Former Member]

Hi Huaiyuan,

Huaiyuan Ji wrote:
There are 500 roles and many authorization objects should be determined with a specified value. We are looking for a quick win approach.
In addtion, it is a upgrade project, we do not want to change existing system behaviour.

In one of my previous upgrade project (4.7C to ECC 6.0) where a lot of new authorization objects were introduced during SU25 run (mostly in FI area if I remember correctly), we deactivated the new authorization during configuration phase and then ran the test cycles. The new authorization objects which failed were the ones really required & they were added on a one to one basis based on system trace ran during testing phase.

I believe its easier to start out by granting bare minimum access to users and then expanding on need basis. Running traces for each new auth object in co-ordination with business analysts during config phase is ideal but that will definitely push the project timeline further. Just my 2 cents!

Thanks

Sandipan

[shivraj_singh2]

As mentioned by Sandipan, deactivating is an option. I remember doing that for one client. And it is definitely better than *. In your case I will go that.

[OttoGold]

Good idea would be to use a special character for these dummy cases, which you can search for afterwards. ' ' is not a good idea, because that is a "real value" in many cases (S_TABU_CLI etc.).

I would go for # for example. You can search for it easily.

Never NEVER assign * where you don`t know what to maintain. AM I CLEAR? NEVER!!

Put dummy value and wait for the user to test. With ST01 trace on it will give you the real values. You can then decide whether to put them to SU24 or maintain fields in the role (org. fields, activities etc.).

Cheers Otto

[Former Member]

A couple of questions:

Why SAP add a new authorization object control point after upgrade?

Suppose old tcode needs control 10 objects, after upgrade, an extra object (11th) was added. Even we assign * to the 11th object, the behaviour is the same as old version, is this correct?

[Former Member]

Hi James,

Actually after an upgrade say an 11th auth object is required, it might mean that your old t-code has been updated with some additional functionality and to control that additional functionality, new auth object was necessary.

[Former Member]

This brings the list of all those roles that are NOT using the latest SU24 . Once you go in the change mode of these parent roles and re-generate , it won’t show up in this list anymore .

1. Tab SU25-2C list the role and the task owner . Tab Non-WRP_Roles lists the roles that exist in TRD-200 but Not in WRP.  Here is what you need to do for each of your parent role :

• (i.) Go to PFCG  and input the parent role name .
• (ii.) Go in the change mode .
• (iii.) Check for the open objects (in yellow color) .
  • If there is an authorization already maintained for that auth object , disable the other un-maintained authorization .
  • If un-maintained authorization is the only one , check in WRP and maintain it as per the values there in production .
  • If the auth object has only un-maintained authorizations PLUS the auth object is not there in the WRP role , simply inactivate all those authorizations .
  • Generate the parent roles and then push the change to all children .
  • Create one transport per parent role .

  Release the transport

[Former Member]

I am Fresher to SAP BASIS and as per my work we did this..

I would like if anyone correct me and add something to it