Authorization Restriction of CO11N

[Former Member]

Dear All,

I have to restrict all users so than except few users nobody can use CO11N.

When I checked via Tcode SUIM I found only one role is there which has CO11n with only 3 users in it.

But still so many users are able to use CO11N.Then i created a test role in my DEV system and when I

checked the object associated with Tcode cO11N is "C_AFRU_AWK".

Now again I went to Tcode SUIM is PRD and searched the role which has object "C_AFRU_AWK" I found arond 48 roles and

my problem is I cant even delete this object from those roles as other transaction will get affected.

And due this this object lots of user is accessing CO11N.

Is there a way to restrict this Tcode without affecting other roles.

Regards,

PG

[Former Member]

most of the transactions effected would not be relevant to you. eliminate the irrelevant ones from your list by checking your business processes against the list you get out of tx. SU24 'Edit check indicators in all transactions' Authorization object C_AFRU_AWK.

with this reduced list check again your roles and see where the transactions are used. there may be a few you can reduce that way.

the next step would be to determine which people you want to:

01 enter confirmation

02 process PDC error record (change)

03 display confirmation

85 cancel confirmation

for the respective AUFART and WERKS (order type and plant). maybe you can split those 48 roles that way.

everybody else does not need this authorization.

typical user groups for this authorization (except for the obvious in CS, PP ...) are FI/CO.

[Former Member]

Thanks for all your replies. I tried the various options but couldnt restrict it permanantly as this particular object exist in a lot of "Z" report that include a major production report.

Hence we have blocked this tcode via SM01.

Regards,

PG

[Former Member]

If locking it via SM01 solves the problem then you haven't explored all the security options.

Users can either directly execute it (through tx in the role menu or t-code ranges) or it is called from another transaction and there is no S_TCODE check forced (table TCDCOUPLES/SE97. Fix those two and you will be giving the same restriction as locking the transaction which is not recommended.

[Former Member]

Pramod,

I suppose, you didnt get what was being communicated............

Point taken that C_AFRU_AWK is used in many Z-reports ........we are not suggesting not to use this object inZ-reports.......the idea was to create a new Z-Object (Z_WHATEVER) and assign this object to CO11N in Su24 - Most importantly have an authority-check statemet on this new Z-object in the program that gets called during CO11N transaction

.......that was my level best

[Former Member]

Pramod,

i don't want to waste your time, since the locking of the transaction using SM01 seems to be the solution for you, but i still want to come back to this and suggest that you try what Alex recommended, if of no use in your situation, follow Shekar's advice - it seems sensible to me. i know that authorisations in combination with Z-reports always present a problem, but i still feel that locking down SAP standard because you feel ill with adjusting customer-made objects isn't the best way to handle this. such 'solutions' have a tendency to come back like a boomerang and when they come, they tend to cause much more work than they would have, if handled correctly in the first place.

end of moralising sermon )

have a nice weekend, all.

[Former Member]

Hello,

What you can do to secure this is to create a group variant in DEV and transport it to PRD. In the variant group , you would insert all users who should be restricted to CO11N and there you go the problem is fixed. I have tried this countless times and it works like a charm.

[Former Member]

Hi Pramod,

In my opinion, even if the users have access to the said object without actually having access on the T-Code Co11N, they cannot access the transaction. Suggest you check again the roles for CO11N.

Thanks

Prashanth

[Former Member]

I am pretty sure they can. i know of at least 3 menus where you can jump from the menu -> utilities (or something similar) to the confirmations screens without the transaction being called once. take IW72 for example -> straight from the list go to: -> order -> list of confirmations ... trace it: no occuring of CO11N or IW44 or whatever.

[Former Member]

Hi,

As there are many users who are getting access of transactions C011N, then there must be some other roles also where this transaction is added.

The roles where transaction were not added from menu, this roles will not show in search "Roles by Tcodes".

Search role in SUIM by "Role by Authorization values" . Put Authorization object: S_TCODE and transactio : C011N.

This will show you the complete result.

Remove transactions from these roles accordingly to remove access of the transaction. The new roles those will be shown in the new search, for these roles, transaction needs to be removed from the authorization object: S_TCODE.

Regards,

Sandip

[Former Member]

I tend to agree with Mylene. Although i cannot give you examples off-hand , there are transactions that you can get into without really having them in your authorization set-up. all you need is the right authorizations on the underlying objects.

The check on the transaction is only a first level check, which at times is by-passed (as i said a top of my mind issue could be with FS00 and FS02, similar to what Mylene mentions - i dont think you would needd access to FS02 if you have the right values and the transaction FS00 - could be worng with my example, so please check)

For the problem you face, i suggest that you also check for the access to transaction COR6N - both transactions (CO11N and COR6N use the same underlying SAP program) so it is quite possible that the users having COR6N with the correct object value are able to use CO11N (I dont think CO11N would work if the key in the transaction, the users are reaching there vai some other underlying transaction/authorization.

More or less: this is what Mylene exlpained

[Former Member]

sorry.......forgot to add : If users have transactions with object values, that might lead them to use a different transaction, you could as well create a custom authority object and assign it to the transaction you want the restrictions imposed on, you would also need to have the ABAP code changed for that to have a new authorization-Check statement.

Have the authoriy object then assigned to authorized users only