Defining of function permissions using "NOT" condition / Access Control 10.0

[Former Member]

Hello all,

We are trying to exclude a couple of program names from the authorization object S_DEVELOP using the "NOT" Condition in the permission definition. However when we enter the value which has to be not critical and save the function and generate the rules and enter the value * in the authorization filed in the authorization role we expect the role to be popped up as critical in summery result of analysis. But we get the result "No valuation". How can this be? Can anyone describe me the logic of the "NOT" condition in access control function permissions?

Thank you in advance

Mehran

[Former Member]

Thanks Colleen, Thanks Ameet,

It's really better to make the exclusion per defining of ranges and not using the NOT-condition. However I am still confused about the logic of this condition.

So maybe you can help me with my main problem:

as already noted above we want to exclude the object names starting with AQ* from our function permission definition. This is about the tcode SE11 and authorization object S_DEVELOP.

Following ranges have already been defined:

0* - 9*

A* - AP*

AR* - Z*

But how about objects all starting with signs such as slash (/), underscore (_) etc. And our customer has a lot of objects starting with these special signs. Do you have an idea how a range definition for this could be?

Thanks,

Mehran

[Former Member]

Hi Mehran,

From my understanding and experience, I would add the permission with the value range and instead of adding NOT condition, I would prefer making that condition "INACTIVE".

e.g.

S_DEVELOP     Value From: A*     Value To: AP*     Status: Inactive

and same for other permissions.

By including NOT condition at the value range for any permission level will exclude that particular line (permission with the provided value range) and nothing else (if I am not wrong).

So, even for the objects starting with special characters, I assume by doing the same way and making those objects INACTIVE, you should be able to exclude the value range from the criticality levels while running the risks reports.

Hope this is clear now, kindly let us know in case of any issues.

Regards,

Ameet

[Former Member]

Dear Ameet,

I fear our understanding of "exclude" is different.

I don't want to exclude the range from function permission. I want it to be excluded from analysis.

I try to explain it a bit deeper:

I have created two roles with SE11 in role menu and entered the value * for all authorization field of the object S_DEVELOP in the first one and only AQ* for the field object name in the second one and * for all other fields in second role as well.

Now I want to have a definition range for object name in my function causing following:

1. when I analyse the first role I expect to have a valuation because of having all values in *

2. When I analyse the second role I expect to have no valuations

Defining the range for object name is clear so far except the rage for special characters. Our customer has a count about 100 or more characters in use. So is there a way for defining of ranges for special characters like for letters or numbers?   (0*-9* or A*-Z*)

Thanks

Mehran

[Colleen]

Hi Mehran

First up, have a look at some SAP help on ranges. Although this is SAP authorizations it still applies to GRC risks.

http://help.sap.com/saphelp_nw73/helpdata/en/4c/a289f2d4233b9ee10000000a42189b/content.htm?frameset=...

I took note of the SAP help link from this little gem

In short - you don't need to put an asterisk in the FROM value if defining a range (i.e. entering a TO as well). You do need the asterisk in the FROM value if entering a "Begins with" (no TO being mentioned). No asterisk means explicit value match.

If you want to exclude a particular value - e.g. values beginning with AQ* you would need to enter the following lines

From	To	Operator
/	AP*	OR
AR	Z*	OR
_*		OR
0	9*	OR

In the first value it is grabbing all /* values and then A through to values AP but NOT values beginning with AQ. It then skips to all values beginning with AU and follows through to Z inclusive.

If trying to figure out ranges, go find the field in the system and look up the table that it comes from. Sort them to see the sequences.

What values do you have starting with the underscore? If you are unsure of you can add them in the FROM with the user of the asterisk (shown the third example above).

In relation to the use of the NOT operator - as mentioned this is intended for HR authorisations to handle object like P_PERNR. If you have PSIGN = E for Infotype 0008 (Basis pay) then that means that you do not have access to maintain your own basic pay even if you happened to have P_ORGIN access. The NOT operator allows you to defined this

Finally, here's some useful SAP notes for the operators (note they do refer to an older version of GRC but still helpful for history and context)

• 1358952 - Rule Architect - logic of the NOT operator
• 1330165 - Instructions on how to use Operators AND OR NOT

Regards

Colleen

[Former Member]

Hi Colleen,

does the range /* TO AP* really cover all special characters? What about & or % or any other special characters?

It's essential to find a range where every special characters are covered.

Thank you very much in advance!

Manuel

[Colleen]

Hi Manuel

Not 100% sure. I think you need to have a look at the ASCII Or EBDIC sequencing (this was mentioned in the link I sent you).

But question to you - for the values in S_DEVELOP for DEVCLASS - which ones would start with such a special character? All custom ones will start with Z or Y; 3-party adds ons typically are /* and then SAP have their own set (as well as $TMP for local)?

Part of using ranges is also the context of possible values to begin with. Have a look at DEVCLASS configuration and see what the limits are. You may not need to cater for any other specials if it's not possible to use them.

No you don't have to do range. You could define as /* with not TO value. Refer the example I did for _* (it would pick all values beginning with the underscore).

Regards

Colleen

[Former Member]

Hi Mehran,

First of all, if any range is a part of the function permission then in order to exclude this selection from the analysis, you need to go with operator "NOT".

So with your requirements, for function permission selection entry with AQ*, NOT operator should do.

Hope this is clear.

Kindly let us know whether or not your concerns have been addressed.

Regards,

Ameet

[Former Member]

Thanks a lot, Colleen!

[Former Member]

Hi Mehran,

If you got your concerns addressed then you can mark the answers and close this thread or let us know if you have any follow-up questions.

Regards,

Ameet

[Former Member]

Hi Mehran,

First thing, if you wish to exclude the reports starting from AQ* (as per your snap shots) so that these reports should not be falling under risk violations, you can deactivate (inactive) the status of that particular selection in Function-->Permission.

And in fact, you are getting no violations post running the risk reports, so what is your concern exactly?

You would get to see the violations for other authorization fields as usual except violations on S_DEVELOP for OBJNAME field.

NOT: it means if you have any other value, then it will return it even if you have the NOT value as well.

You can refer below notes, though these are for low versions but the concepts are the same for AC 10.x as well.

http://service.sap.com/sap/support/notes/1330165

http://service.sap.com/sap/support/notes/1358952

Kindly paste your risk violation reports and be more considerate with your concerns.

Regards,

Ameet

[Colleen]

I was under the impression the NOT operator was for some HR authorisations only. I think there is a note explaining that.