capturing auth check in background for functional testing

[Former Member]

Hi All ,

We want to build a program which monitor all the authorization objects checks for a tester and then prepares a report with all these authorization This report will then be used by a security consultant to build a role or update existing authorizations .

I know ST01 does help us on this but we wanted to add more features to it by adding change request number number for tracebility .

Is there any way to multiple session for trace .this is because we will have multiple tester doing testing at same time . and currently i see that either we can switch trace for one user or to all users in the system .

Any other ideas to do this are also welcomed .

[Former Member]

Hi Rakesh,

I feel you are making the process too complex. A custom program to analyze the auth objects in another custom program, and by adding the CR #s using another program.... huh.. too many programs

This is pretty simple. Any custom program should have some level of authorization restriction through an AUTHORITY CHECK statement, or S_TABU_DIS (if the program retrieves data from tables.) You can easily search for them using SE93 (incase of AUTHORITY CHECK), or TDDAT (table authorization group) table. Make use of them and don't recommend using thousands of custom programs and make yours and the auditors life miserable.

If you still need a program and don't think that it hurts the system performance, and makes the process complex, you have to switch the trace at the user level in ST01.

Regards,

Raghu

[Former Member]

Hi Raghu ,

Thanks for your reply . I think i made you confused . Let me try to explain again in simple way ,

Instead of having Fuctional team coming back and forth for all the security testing we want to use a custom program which will run in background to capure all the auth check that were executed by the tester . The report will then be sent to security to review and update the role .

My question is if there is any way we can do multiple users trace at same time . (I know we can do one user or full system trace but looking for multiple user option )

Edited by: Rakesh Navandar on Nov 24, 2010 7:12 PM

[Former Member]

Why should the funtional guy go" back & forth '? the AbAPer needs to know which objects are beign checked ! Or involve the security team memeber in the development.

[Former Member]

Hi GG,

I agree with you. Working closely together with the developers is best for them and for you and the security aspects of the development work, but that only applies to custom development.

For config of SAP standard functionality you need a functional guru to work with - again preferably a good one who appreciates security aspects.

Testing is a different scenario and still will produce changes required which were previously unknown.

@ all:

An idea I have (possibly for a community project?):

There already is an SDN blog on how to trace users and extract more usefull information from the trace, and I hope we will see it in the standard soon. See [Frank Buchholz's "Show ST01 authorization trace"|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16729] [original link is broken] [original link is broken] [original link is broken];

Now with that as data source, we could assign a personal "delta role" to each (set of) tester(s) and have a job monitoring the trace every minute or when the user triggers an event (would be better).

The step program reads the trace information into the program for all sy-subrc NE 0 and then filters out a "black list" of known red-herrings, such as:

S_TCODE = values which don't exist in TSTC are typing errors.
S_ALV_LAYO = ALV reports open to change the layout.
S_CTS_ADMI = TABL provoked by returning to the menu or CALL SCREEN 100.
S_TRANSLAT = actvt '02' provoked by messages.
S_DOKU_AUT = ' ' provoked by views.
S_DEVELOP = DEBUG '03' provoked by Short Dumps and report writer queries to make 
*               the DEBUG button invisible.
S_USER_GRP = actvt '05' provoked by many vendor and customer transaction in logistics 
*                where the old SU05 "internet user" was given the option to 
*                change their "internet password".
S_PROJECT = ' ' provoked by the F4 search help on many fields. 
S_BTCH_ADM and S_BTCH_NAM = show up as failover for S_BTCH_JOB and set screen 
*                variables in SM37 / SM36 

Additionally, we could collect a program / tcode context list with reason codes to add for other well known application specific red-herrings. Org. levels will be tricky, but can be done.

Other "critical" authorizations which are known will be easy to add to a negative "black" list. Just ask your auditors for them...

Then, based on what is left over... we automatically re-generate the profile of the already assigned delta role so that the user can carry on testing.

Another feature option would be to additionally transfer all the left over data with the tcode contexts to a flat file in the format of the SU22 "original data" upload, and then use SU25 back in DEV to upgrade the roles from the testing results instead of manually transfering the the delta role to the real one.

I built a very similar solution for a customer once for K_REPO_CCA but they ended up not using it because they converted to K_CCA.

I think the trick will be to collect the DB for the "blacklist" (to be perfect, it should be release dependent... but community projects are good for such data.

Also the calls for the generation are not released functions and very tricky to use so they might change or easily go wrong in local addaptations (variables in screens are global!). As a community effort we might be able to persuade SAP to provide interface stability though and add warnings about being attacked by devils if some includes are touched?

I would be very happy to contribute, but don't want to end up doing everything (like some other security wiki requests have...).

Anyone else interested in working on this?

Cheers,

Julius

Edited by: Julius Bussche on Nov 24, 2010 10:12 PM

[Former Member]

Hi Julius,

Awesome! I like the approach. Let me know what other contributions are required? I am ready to take up tasks to get a more better and better features. Let me know.

Rgds,

Raghu

[Former Member]

Hi Raghu,

I am first checking with SAP whether they have something similar in the pipeline or concerns (I have one) and will get back to you.

Cheers,

Julius

[Former Member]

>

> Hi Raghu,
> 
> I am first checking with SAP whether they have something similar in the pipeline or concerns (I have one) and will get back to you.
> 
> Cheers,
> Julius

Just the one concern?

I'm also happy to contribute to this so if there is anything I can do, fire away.

[Former Member]

Hi Julius ,

Thanks for you reply . I am working on this solution with a bit different approach .

What i was thinking was to get all the auth objects that were run by tester and then check with the composite role on what objects are missing The report will then be sent to security consultant . Security consultant will then mark the objects as Include/Exclude . The program will then be enhanced to modify the role to add all the objects that were marked as include . (Still i need to work on this design )

Currently i am struck with the problem on how to state trace for multiple users only . I dont want to start the trace for all the user as we will end up creating a large trace file and then work on regular clean up. i will not be able to use single user trace as lot of tester will be testing at a same time . Can anyone share opinion on this .

[mvoros]

Hi Rakesh,

>

> What i was thinking was to get all the auth objects that were run by tester and then check with the composite role on what objects are missing  The report will then be sent to security consultant . Security consultant will then mark the objects as  Include/Exclude . The  program will then be enhanced to modify the role to add all the objects that were marked as include . (Still i need to work on this design ) 

I don't think that this is feasible approach. Generally, you should try to avoid adding manual objects to roles. You should always try to use SU24 entries. In this case you want to identify missing objects which is OK but then add manually all missing objects into role which is wrong. If you want to do it properly, then you need to figure which transaction should be added to role or which transaction is missing that object in SU24. I don't think it's possible to do automate this step.

Cheers

[Former Member]

Hi Julius ,

Did you get any reply from SAP if there is anything like this in pipeline .

Thanks Rakesh .

[Former Member]

Hi Martin

" In this case you want to identify missing objects which is OK but then add manually all missing objects into role which is wrong. "

I agree with you that we should not add objects manually to the role . I am still working on the design and feasibility and also how it suits our landscape .

All ,

Still looking for option on tracing multiple user(Not ALL) at a time .

Thanks

Rakesh

Edited by: Rakesh Navandar on Nov 30, 2010 7:16 PM

Edited by: Rakesh Navandar on Nov 30, 2010 7:17 PM

[Former Member]

It will take a little while, so don't stop your project...

@ Martin wrote:

If you want to do it properly, then you need to figure which transaction should be added to role or which transaction is missing that object in SU24. I don't think it's possible to do automate this step.

This data (transaction context, source code location, reason codes) is available in the ST01 trace file and (optionally) as you know in table USOB_AUTHVALTRC as well.

If there were a "black list" and "white list" of these contexts for objects which are known to be not allowed or generally okay (such as "base check functions) then the manual steps of maintaining SU24 could be automated to an extent (via SU25) and more importantly --> for testing purposes the event of the failed auth check can add the authorization values to the user's delta role automatically so that they can carry on testing.

This is a much better approach IMHO than SAP_ALL with trace on or relying on transaction SU53 (may your armpits become infested with the flees of a thousand camels...) information to automatically build roles or find missing auths.

The two main hurdles I see are gathering a ruleset for the blacklisting and whitelisting (which I think an SDN wiki would be a cool source for), and, a stable API for the role generation (for this we need help from SAP because there isn't one).

Cheers,

Julius

[Former Member]

Hi Julius ,

Thanks for your guidence .

Would it be recommended to put ST01 trace on for such solution .What kind of approach you followed previously .

Also how was the load on the system and was there any effect on performance .

Appreciate you help !

Thanks

Rakesh

[Former Member]

With a limited amount of activity going on, yes you can use that - but there will be performance impacts from ST01 on very busy large numbers of users.

A better option would be to use the solution described in [SAP Note 543164|https://service.sap.com/sap/support/notes/543164] . I have used this before and was very happy. However it will only propose "original data" values to you where the code reached the check, with the intention of adding them to SU24 back in DEV as a manual process. Some well built roles with good functional gurus, then is normally not necessary.

It also explains some of the nonsense in SU22 when "the rules" are not understood or adhered to... --> see Frank Buchholz's answer to question # 1 in

For larger developments with lots of testing going on in authorization areas where none of the gurus has gone before and no captain's logbook was left behind to read either... it is the Rolls-Royce of what is currently available.

Cheers,

Julius

[Former Member]

The two main hurdles I see are gathering a ruleset for the blacklisting and whitelisting (which I think an SDN wiki would be a cool source for), and, a stable API for the role generation (for this we need help from SAP because there isn't one).

I have been playing around a lot with this and managed to solve these problems and am almost finished with the coding.

Using shadow tables for black, white and grey lists from the usage of the system and failed auth checks, it is possible to give these messages, user behaviour, sy-tcode contexts, source code locations, return codes and reason codes some application logic life to generate roles based on the events. I am even adding a "check SAP Notes" feature which will look context specifically from the results for authorization relevant SAP notes as "hints" to navigate into when reading the log.

A prototyp example to illustrate the automation when no user interaction is required nor possible --> Create a basic role for a SYSTEM RFC user (see SAP note 460089) and then let the interfaces run for a while. When you get back from your coffee break, pub lunch or vacation... the role based on what it actually used (minimum rights principle) is finished.

Same goes for end users given the task of testing what they need or their existing roles after upgrades or generating "delta roles" which contain only the "delta authorizations" for emergencies.

Cool heh?

If anyone would like to be a "beta tester" then let me know. I would need to verify the data I have in the shadow tables and that it's artificial intelligence to collect the generation rules in the tables works for various obscure scenarios.

RESPAREA in controlling I have covered already (if that means anything to you...). Asset Accounting, HR and Industry Solutions are going to be a tough nut to crack. For the moment I black-listed them...

Cheers,

Julius

[Former Member]

Hi

This goes way over my head to be perfectly honest....

I can see that the thread has investigated some interesting options for delta check etc but are we getting way ahead of ourselves here? Are we going back to a profile all trace and filling in the gaps?

We know the user will run F110 (say) but then go off on a tangent and bring in multiple objects based on their understanding of the proess rather than the best practice.

Sorry to be a kill-joy but I think we need to keep it simple but maybe this is more advanced than I am used to?

Kind regards

David

Edited by: David Berry on Jan 8, 2011 12:05 AM

[Former Member]

Yes, there is a "**** in **** out" aspect to it, that is always omnipresent... but with an application logic between the result (and contexts, and blacklists, etc) and the generation you can filter out much of the nonsense returned from the runtime environment.

The beauty of OO programming is that you can TRY and CATCH exceptions at all layers of the application (UI, processing logic, logical unit of work in "helper classes") and make the thing articifically intelligent depending on the layer the interaction is comming from.

User input is often not intelligent and should not assumed to be so, until validated (as a little example...).

As a sceptic, you make a perfect beta-tester. Upgrade to paranoid control-freak and this is exactly what you are looking for plus the system still works without short-dumps...

Sorry to be a kill-joy but I think we need to keep it simple

That is just User Interface (UI) programming. Important and should not be faked for what is really happening under the bonnet, but it is possible to make a UI for such a tool very intuitive and simple, even although the business logic in the application is complex and in this case has the ability to adapt itself to it's use. The more it is used, the cleverer it gets to build roles.

Artificial intelligence in ABAP (in a light-weight sense, without blowing up the planet or anything like that...

Anyway, I thought it was a cool idea and am puting some effort into it without it generating **** authorization values or "guess work" (very common point of security failure).

Cheers,

Julius

[Former Member]

Artificial intelligence in ABAP (in a light-weight sense, without blowing up the planet or anything like that... 

Terminator - original

Sarah Connor: What did he just say?

Gas Station Attendant: He said there's a storm coming in.

Sarah Connor: I know.

Forrest Gump

My momma always said, "'SAP'(changed) was like a box of chocolates. You never know what you're gonna get."

Sorry - couldn't resist...

David

Edited by: David Berry on Jan 9, 2011 12:39 AM

[Former Member]

LOL

Also reminds me of Sledge Hammer:

Captain Trunk: Sledge, you cannot disarm that nuclear bomb! 
Sledge Hammer: Trust me, I know what I'm doing. 

I looked around and found some products on the market which attempt something similar, but they base their data on SU53 (!!) from the users and make direct updates on the AGR* tables to generate derived roles using the function behind SUPC....

Go figure for yourself why I thought it possible to use a better approach

Cheers,

Julius

[Former Member]

A little update:

I have a beta version working and done some interesting testing:

- I have 174 entries in the black-list now (known false-positives) which are generally independent of the transaction context.

- I have 743 entries generated into the white-list (via the self-learning feature) which are transaction specific.

What I then did was compare these to the SU24 entries maintained by some customers of mine who use it extensively. For tcodes not equal to Z* and Y* and USOBT_C field MODIFIED = 'X' the white-list had a very high hitrate for a role based on vanilla FI accountant menu role, vanilla Controller menu role and my "Display All" auditor role.

So... what to do next? --> additional download button from the context sensitive missing auths generator into the format of the SU24 upload function.

If anyone is interested in comparing USOBT_C field MODIFIED = 'X' (or made any other progress) feel free to post them here or contact me (see my SDN Business Card).

Cheers,

Julius

[mvoros]

Hi Julius,

maybe I am still in holiday mode but where can I download your tool? Happy to help with additional feature and code review.

Cheers

[Former Member]

Hi Martin,

I am hoping that it can be downloaded frpm the SMP oneday, but that will take a while still.

We are not finished with the coding and testing yet, but with some luck you will be able to see it latest at the 2011 TechEd Demo Jam contest

What would be very usefull is to verify the white, black and grey-list logic. If you have maintained any SAP transactions and know specific proposals which make sense in SU24, then they would be very usefull for testing that the tool "thinks" the same way.

Cheers,

Julius

[Former Member]

Hi

Hardly worth adding as SU24 has been unmaintained for the last 11 years...

OH11 TR P_TCODE TCD OH11 UK_DBERRY 27.10.2010 15:04:16 X

PFCG TR S_USER_SAS ACTVT 22 UK_DBERRY 11.10.2010 16:28:25 X

PFCG TR S_USER_SAS ACT_GROUP UK_DBERRY 11.10.2010 16:28:12 X

PFCG TR S_USER_SAS CLASS UK_DBERRY 11.10.2010 16:28:12 X

PFCG TR S_USER_SAS PROFILE UK_DBERRY 11.10.2010 16:28:12 X

PFCG TR S_USER_SAS SUBSYSTEM UK_DBERRY 11.10.2010 16:28:12 X

SP02 TR S_RFC ACTVT 16 UK_DBERRY 14.12.2010 13:51:40 X

SP02 TR S_RFC RFC_NAME SLST UK_DBERRY 14.12.2010 13:55:24 X

SP02 TR S_RFC RFC_TYPE FUGR UK_DBERRY 14.12.2010 13:55:31 X

XK02 TR F_BNKA_MAN ACTVT UK_DBERRY 22.10.2010 11:50:55 X

YTCD TR S_RZL_ADM ACTVT 01 UK_DBERRY 09.11.2010 08:40:34 X

YTCD TR S_RZL_ADM ACTVT 03 UK_DBERRY 09.11.2010 08:40:34 X

ZHR_AUDIT TR S_TCODE TCD ZHR_AUDIT UK_DBERRY 05.11.2010 10:49:11 X

Hope it helps

[Former Member]

Thanks David!

Interesting examples - I added some of them to the lists and will explain how and why:

OH11 TR P_TCODE TCD OH11 UK_DBERRY 27.10.2010 15:04:16 X

In release 7.01 this p_tcode check is right upfront at the start of the transaction and included as a proposal. Probably you saved in Su24 and a popup appeared stating that "Data has been automatically corrected"? I added it now as an active authorization for the automatic role generation, as it makes sense, but should normally not happen anymore.

PFCG TR S_USER_SAS ACTVT 22 UK_DBERRY 11.10.2010 16:28:25 X
PFCG TR S_USER_SAS ACT_GROUP UK_DBERRY 11.10.2010 16:28:12 X
PFCG TR S_USER_SAS CLASS UK_DBERRY 11.10.2010 16:28:12 X
PFCG TR S_USER_SAS PROFILE UK_DBERRY 11.10.2010 16:28:12 X
PFCG TR S_USER_SAS SUBSYSTEM UK_DBERRY 11.10.2010 16:28:12 X

These are all blacklisted, so cannot be selected (independent of the tcode). You need to add them intentionally without any intuitive invitation to do so.

SP02 TR S_RFC ACTVT 16 UK_DBERRY 14.12.2010 13:51:40 X
SP02 TR S_RFC RFC_NAME SLST UK_DBERRY 14.12.2010 13:55:24 X
SP02 TR S_RFC RFC_TYPE FUGR UK_DBERRY 14.12.2010 13:55:31 X

Good catch. RFC_NAME = SLST is often in the "common role for all users" so did not fail for me, but SP02 is a good candidate for adding it, so it is an active whitelist entry and will automatically be generated into the role (unless you intervene in the analysis UI).

XK02 TR F_BNKA_MAN ACTVT UK_DBERRY 22.10.2010 11:50:55 X

Tricky one... I added the object itself as passive whitelist entry as it may not always be desired. If selected for any XK* contexts, then the tool adds them to the greylist and starts passively suggesting the corresponding activities for XK01, XK02, XK03 (if the user was in that transaction code). These are then permitted, but much prior have been selected for generation for the tool to figure out that they should become active.

YTCD TR S_RZL_ADM ACTVT 01 UK_DBERRY 09.11.2010 08:40:34 X
YTCD TR S_RZL_ADM ACTVT 03 UK_DBERRY 09.11.2010 08:40:34 X
ZHR_AUDIT TR S_TCODE TCD ZHR_AUDIT UK_DBERRY 05.11.2010 10:49:11 X

These are Z- tcodes and will differ from implementation to implementation, so I did not add anything. However, the white, black and grey lists permit naming conventions of transactions to white list certain objects and when the grey list starts noticing a pattern (if you use a naming convention!

Asset accounting, SD and HR are real nut-crackers though. I am thinking of creating a validation against selected customizing settings which are authorization relevant, in addition to the usage of the tool anyway, to build the implementation specific greylist when the tool is used. For example, respecting the PRGN_CUST settings, but there are MANY more.

As all this runs in a test / QA system and not PROD or DEV, I have felt more confident to build in such speculative intuition into a tool. Normally I am too paranoid about production systems and the integrity of development systems. Nice breath of fresh air!

I hope you folks don't mind me keeping you updated with my ideas and looking for sparing partners

Cheers,

Julius

[Former Member]

Another little update after 3 "ramp-up" customers are happy with this invention and SAP has taken an interest in it:

On 10th June 2011 there will be a Security Info Day in Walldorf (in German) and a world tour which will follow (in English).

Key note address is by SAP Chief Security Officer Michael Hartmann.

Two notches down the agenda is a 50 minute presentation and live demo about this thread here on SDN!

You can register here --> http://www.sap.com/germany/about/events/search/overview/index.epx?EventID=7919 for the event. You can also "test drive" the Automatic Role Builder at this event. (See the "Agenda" button)

With a push of luck you might even see it in SAP standard oneday...

Cheers,

Julius

[Former Member]

Hi Julius

Well done that man. Can't attend but I wish you all the best.

Regards

David

[Former Member]

Hello Julius,

I am very happy to see something like this being worked on. Would love to see this become "standard".

We were discussing how aggravating it is to try to create a new role, just using ST01 for a single user, to grab the list of the rogue authorization objects that get missed sometimes. A very slow and cumbersome process of course...

We have a small authorization cleanup project we are working on, and this tool would be awesome to use. Are you still looking for more testers?

Thanks,

Butch

[Former Member]

Hi DB and Butch,

I already tested it with 3 multinationals for the basic BC, FI and CO scenerios and they are happy.

Currently I am testing Analysis Authorizations in BW when the user assignment is via ABAP objects and not direct in RSECADMIN (this is also SAP's recommendation to be able to integrate with IdM).

What I am currently testing together with two friends is modelling of org. levels and open fields beyond single role boundardies for ABAP object roles and generation of AA auths for BW from this model or external data modelling with a default from SPRO.

If the complexity can be mastered and the UI made simple and intuitive, then I think a mass generation based on a model producing roles with standard and maintained authorizations is possible.

A hard nut to crack is HR dependencies and infrastructural issues (Web Services and RFC connections) but I am working on it to be able to generate roles for them without "red herrings".

Cheers,

Julius

[Former Member]

Hi Julius

This sounds like you are straying into the realms of Otto's 'Thing of Evil' program?

I still stick to PFCG is good and all else (including LSMW's with the first name 'Theresa' in SU01 - there being 695 of them in the end) are bad

Lost a perfectly good contract doing evil things outside of PFCG...

Anyhoo, sounds like a damned fine experiment - only wish I understood the basics rather than keeping my 'clogs' at the ready

Kind regards

David

Edited by: David Berry on Jun 2, 2011 11:41 PM

[Former Member]

Yes, being carefull and using APIs is always advisable....

This thread here is about singe role analysis with user assignment and generation / transfering to SU24 and information integration with external sources (GRC / IdM).

Otto's thread is about scalability of derivation rules from reliable analysis sources, which is different...

Yes... such a qualitative role build tool with validated field inputs and mass generation capability with respect for customizing would be a nice tool --> he discussed it with me at length before posting it here - which I recommended him to do.

Also yes... I advised Otto to steer clear of LSMW and eCATT in his quest for stable coding. Same goes for Batch-Input...

Application APIs from stable calling contexts is the way to go.

Cheers,

Julius

[Former Member]

A little update: from first rollouts I have collected all the grey list data for typical RFC scenarios and transfered these to the SU24 proposals delivered with the application.

The tool can now also be run in RFC mode. Via the transaction ID it then keeps the context of the original RFC called function module, so you can load the FMs into the menu and then test.

Optionally you can transfer the actual values to the proposals if there is a compelling reason to do so. The tool also shows you whether the authority-check was successful because of the FM in the menu making the proposal or whether it came from a different role (as we all know that the only real test is in PROD). You can then download from PROD into the SU24 upload file format for DEV until all checks (e.g. Z-functions...) are contained in the role being tested. In QAS the same values are generated "on the fly" so that testing can continue. You can also "rollback" to other (legacy) authorizations and analyze the differences based on the roles which caused the successful auth checks. Reason codes and hints to SAP notes for checks are also supplied, so you do not have to read or debug the code to understand the important parts. You can also add your own hints (I added some to SDN threads as well in addition to the SAP documentation and notes).

If all goes well, then the tool will become available as a SAP service (possibly integrated into SolMan - which I am currently working on together with SAP). Currently it has a partner service product status, so there are some costs involved (disclaimer).

If I am allowed to boast a little bit... the tool really rocks!

Further announcements will probably come from SAP...

Cheers,

Julius

Edited by: Julius Bussche on Jul 21, 2011 11:03 PM

[Former Member]

If I am allowed to boast a little bit... the tool really rocks! 

Boast away

[Former Member]

Hey Julius,

Did this ever progress to an actual product available anywhere, either through SAP, or through a 3rd party?

I searched around a little on marketplace, but didn't see anything.  May be searching for the wrong keywords.

Figured it would be just as easy to come back to this original thread and just see what the latest news was, since it has now been another 2+ years for it to evolve.

Thanks,

Butch

[Former Member]

Indeed, very valuable gems have been added on the kernel side of the user buffer and AUTHORITY-CHECK statement over the past year.

The most important of these is that if certain conditions are met (see methodology and applications used in the SAP Note 1682316) then you can analyze which authorization assigned was responsible for the successful check. This was needed for RFC users as you cannot realistically test them.

Trick is to give or leave them with SAP_ALL as the LAST authorization they have and then just simulate that the previous one(s) is always sufficient, but nothing will ever really fail.

Actually you can do the same for dialog users as well. Let them switch between simulations in production until they feel comfortable means you dont necessarily have to test at all anymore... just simulate for long enough and collect data on which authorization set sy-subrc to 0.

The redesigns of the roles are completely error free and no one notices anything of the fact that there was a big change. Works like a charm... 🙂

Cheers,

Julius

[mvoros]

Hi,

as far as I know you can have only one trace for each application server. But you can run your tests with different usernames and then split trace data using username. But I don't understand why you want to generate these reports. You should try to use only values from SU24 during build of your roles. The consultants can just put all relevant tcodes to role, fill missing values and then run your program if it's enough or something is still missing (SU24 is not perfect).

Cheers

[Former Member]

is that program not executable in foreground?

if yes, then debug and put breakpoint on 'authority-check' keyword.