Create Role using SPRO_ADMIN has access to more t-codes then what it shows.

[neil_hoff]

In SPRO_ADMIN I created a Customizing Project and gave it a scope of:

- SAP NetWeaver

- Enterprise Structure

- Cross-Application Components

- SAP xApp Resource and Portfolio Management (SAP xRPM)

- Strategic Enterprise Management/Business Analytics

- Integration with Other mySAP.com Components

When I added the customizing authorizations from this project to the role it displayed that 3500 t-codes were added.

I checked SUIM under "Roles by Role name" and clicked on the Transaction assignment button and 3500 t-codes were displayed.

I then checked SUIM under "Transactions --> Executable for Roles" and it says there are 95,972!

How is this possible?

When I added the role to users they were able to get to t-codes that I couldn't find in the menu.

I have tried deleting the role and re-adding the customizing auth to a role with a different name. I have tried deleting the

customizing project in SPRO_ADMIN and re-creating that then adding it to a different role. I have tried taking a list of all

the t-codes that are in this role, creating a new role and adding them through the text file import. All of these examples have

the same result given above.

Any ideas on how to create this role so that it only has access to the 3500 t-codes it is supposed to have?

Thank you in advance for your help!

Neil

[Former Member]

Check to see whether transaction PIQAGR_CUST has been included? It has a proposal which was slightly misunderstood...

Anyway, which release and SP are you on? There have been a selection of bugs in SUIM over the years and this might be one which is still there in your system.

Cheers,

Julius

Edited by: Julius Bussche on Jan 14, 2010 5:56 PM

[neil_hoff]

Thank you for the quick reply Julius, but PIQAGR_CUST is not included.

So...are there t-codes that give you access to more t-codes?

We are on ECC 6.0

SAP_BASIS 700 0012 SAPKB70012

SAP_ABA 700 0012 SAPKA70012

When we add the role to users they do have access to t-codes that aren't in the 3500 that were added.

Edited by: Neil Hoff on Jan 14, 2010 6:03 PM

[Former Member]

> So...are there t-codes that give you access to more t-codes?

There certainly are (PIQAGR_CUST was an extreme example of such a t-code) but I think the problem here is more likely to be low SP levels.

I don't use that report, but did a quick check and it works okay - there are several SAP notes mentioned in the coding which are more recent than your SP 12. For example are the total number of entries in table TSTC also 95,972?

Can you verify in UST12 that there are 3500 LOW entries in S_TCODE for the authorizations of your role, and no HIGH values nor wildcards?

Cheers,

Julius

[neil_hoff]

>

> I don't use that report, but did a quick check and it works okay - there are several SAP notes mentioned in the coding which are more recent than your SP 12. For example are the total number of entries in table TSTC also 95,972?

There are 105,321 entries in TSTC

>

>Can you verify in UST12 that there are 3500 LOW entries in S_TCODE for the authorizations of your role, and no HIGH >values nor wildcards?

I think this helped me find the issue. There is an entry that has 0 for low and ZZZZZZZZZZZZZZZZZZZZ for high. How would this have gotten added? I tried to go into PFCG and remove this line under s_tcode and it will only allow me to view. This means that it was added through the menu, which makes sense since that is all I have done to this role. Do you know what t-code would do this? Can I remove it?

Can I just delete this entry from the table?

Thanks for the help!

Neil

[Former Member]

> There is an entry that has 0 for low and ZZZZZZZZZZZZZZZZZZZZ for high. How would this have gotten added? I tried to go into PFCG and remove this line under s_tcode and it will only allow me to view.

Then you are experiencing the same as PIQAGR_CUST, but with other consequences and a different source. An S_TCODE, S_RFC and S_SERVICE authorization which is display only is either in the menu or pulled in from SU24.

To find the offending transaction, go to table USOBT_C field HIGH and search for Z* to find it and remove it from SU24. Also check SU22 to see whether it was added there... There might be more than one and other roles will be impacted when they are opened in expert mode!

Then go to USOBT_CD and find the change document for that transaction code for field HIGH = ZZZZZZZZ... and the user name and date of the change.

Find that person, and show them this thread...

You might want to check all other roles which have this transaction in the menu... as that will probably be the origin of the problem and give you an insight into their frustration (and this "workaround" solution).

What you are doing is a hard day's work and for SPRO related roles this solution (or manual authorizations and profiles) is not uncommon to observe.

If the quality of the SU22 data were better then it would be less of a hassle and problem. In SU24 you can tune it and remove such things, but ideally the original system should do this. With each support package SAP improves this data, but there is still a lot of standard junk in there as well.

Retrofitting security is always the most expensive option....

Cheers,

Julius

Edited by: Julius Bussche on Jan 14, 2010 11:00 PM

[neil_hoff]

Hi Julius,

I couldn't find the offending t-code in table USOBT_C because the entry 0 to zzzzzzzzz wasn't next to it.

I manually went through adding groups of t-codes and finally found out the problem t-code was RPM_DX. In SU22, S_TCODE was set to add 0 for low and ZZZZZZ for high.

Thank you for all your help!

Neil

[Former Member]

> In SU22, S_TCODE was set to add 0 for low and ZZZZZZ for high.

Oh!! That is bad news for you!

You should never maintain SU22 directly. That is "SAP data" and "Original data" for the landscape.

I recommend that you get some professional help to synchronize the SU22 and SU24 data, also between the systems in the landscape. It is too lengthy to describe in a forum post as there are many things to check (and correct - release and SP dependently). If you do an upgrade to a higher release you will have several problems... particularly if someone clicks in the "wrong" place in Su25.

If you open a support call with SAP they should be able to take a look.

Cheers,

Julius

[neil_hoff]

I created a message with SAP and they came back with a note:

Note 1416864 - RPM_DX : Authorizations granted for all transactions

It states that you should just make the change in SU22. So I did and everything seems to be OK now.

Thanks again for all your help,

Neil

[Former Member]

Then it seems SAP delivered that strange range. Yes, then they should correct.

However making changes to SU22 is still a dodgey thing to do. The best way is to wait for a support pack to change the SAP data and remove the proposal from SU24 (if that is set up correctly!). So to be honest I don't agree with that SAP Note's solution, although the problem is clear.

My 2 cents,

Julius