Authorization objects and value assignments to fields (F_SKA1_KTP, KTOPL)

[Former Member]

Hello,

I am trying to identify who can create master records in the CoA? So I am running 2 queries via report RSUSR002 with the following parameters:

Transaction FS01 with authorization object F_SKA1_KTP (ACTV=01 & KTOPL=CAN or KTOPL=* )

Transaction FS01 with authorization object F_SKA1_KTP (ACTV=01 & KTOPL=CAN )

The first query returns a larger result set, so I have the following questions:

1. What is the impact of putting a * in the first query? Does it mean that it will look for users who have been assigned * in the KTOPL filed or is it just wild character that will return all possible combinations?

2. One of the users reported by the first query had KTOPL = ' ' - do you guys know what is the impact of this? Is it that they can modify all CoA or none since access to specific CoA has not been explicitly granted?

3. Sometimes fileds such as ACTV or BUKRS can be assigned values of * - how can I search for these via report RSUSR002?

Hope what I have written above is not too confusing. Thanks you for your time!

Martin

[Former Member]

Answer to Your first question ;

1. What is the impact of putting a * in the first query? Does it mean that it will look for users who have been assigned * in the KTOPL filed or is it just wild character that will return all possible combinations?

Here the search is purley boolen logic-->the system looks for both :

ACTV=01 & KTOPL=CAN

ACTV=01 & KTOPL=* )

Hence naturally your search results will be larger than just "ACTV=01 & KTOPL=CAN"

The rest of your questions I didnot find time to read it fully..once Ido that I will give my inpouts !

Thx

[Former Member]

1. * is a wildcard character which will show up all instances of the object being searched. i.e. regardless of what value it has. It does not specifically look for the single value ' * ' or '01 or '01, 02' etc.

2. In some reports/ transactions you cannot leave a field as blank. When this is done the authorization check automatically checks for a value ' '. To counter this the value is given in the role.

@Gurus: Kindly correct me if my understanding here is wrong.

3. I'm not sure if such a query can be executed in RSUSR002. In such cases, I generally generate a report from the tables AGR_1251 (or AGR_1252 for org levels) and AGR_USERS.

You can also create a custom query combining such tables in SQVI.

Hope this helps.

Regards

[jurjen_heeck]

> 3. Sometimes fileds such as ACTV or BUKRS can be assigned values of * - how can I search for these via report RSUSR002?

Type a hash symbol (#) in front of the *. This will stop the system from interpreting the * as a wildcard.

Jurjen

[Former Member]

> 3. Sometimes fileds such as ACTV or BUKRS can be assigned values of * - how can I search for these via report RSUSR002?

There is also a difference between '#' and '#**'.

- #** = all defined values of the field are present in the authorizations of the user. These are either check tables or domains (with defined value ranges).

This, is however not necessarily a "*" value in the authorizations....

- #* is exactly a '*' value in the authorization

A "*" was found, regardless of the field type of the authorization object.

Many authorization fields have defined value ranges for documented uses. So... adding "*" to authorization fields which do have documented uses, can in special cases add some undocumented features...

A classic example is authorization object S_ADMI_FCD => you should never dish out full authority for that... and even if you do... then sometimes even "*" is not enough...

See [SAP Note 978447|https://service.sap.com/sap/support/notes/978447] for a documented adaptation for this and some other selection techniques (and tools).

Cheers,

Julius

Edited by: Julius Bussche on Aug 25, 2008 8:01 AM

Corrected which-is-which *.

[Bernhard_SAP]

HI all,

additional remark, if you are facing unexpected results......

there is another very important correction regarding the search including more than one search criteria:

[SAP Note 1227083|https://service.sap.com/sap/support/notes/1227083]

without this correction strange results may occur.

The Kernel patch of [SAP Note 1150995|https://service.sap.com/sap/support/notes/1150995] is advisable, because only with that patch the new coding is used. (There seem still to be some porblems with the 'old' coding....)

b.rgds,

Bernhard

[Former Member]

Hi Everyone,

Thank you so much for the helpful inputs. Without your help I might have ended up with unreliable results!

Best

Martin

[Former Member]

Thank you Bernhard!