FAQ

Question:I have a request for background job output to be viewed online by several users. I don't want to give global access to spooled jobs but I do want selected users to share the output of certain jobs without having the job run multiple times under each of their user IDs. How can this be done, short of routing hard copies? I've read OSS note #29666 but it doesn't solve the issue.
Answer:You can solve this problem by using authorization and changing the SAP program RSPOSP01 under transaction SP01.Use 3 profiles General:
(1) spool display authorization (object S_ADMI_FCD) use SP0R value,
(2) divice authorization (object S_SPO_DEV) value - what ever you need e.g. "lt*", Per user:
(3) spool action authorization (object S_SPO_ACT) use authorization string;use logical coding like user-id or department-id.

When you schedule the background job, use for the print step the authorization string. You have to search for all the code in the program RSPOSP01 with "IF TSP01-RQAUTH <> ' '" and for IF SPOOLOBJ-RQAUTH <> ' ' and change it with IF TSP01-RQAUTH <> ' OR SY-UNAME <> TSP01-RQOWNER and so on ....You have to do this in more many places in the program!

The story is that R/3 in not doing the AUTHORITY-CHECK OBJECT on the authorization string, if the authorization field in the print definition (attributes) is empty. You can force it to do that if the user is not the owner of the spool. Be careful how you change the code,that you do not impact the higher
level authorization.

Who said that you do not need to know ABAP to do BASIS? I think that he must have been a manager of higher!

Question:In our production 2.1F system we must perform the object deletions in the integrated system and then transport the 'empty' objects. Is there a 'new' way of deleting authorizations/profiles in 3.0B or do we still have to do it the 'old' way? I didn't see any buttons in the users' transport menus for authorizations/profiles...
Answer:Transactions SU02 and SU03 allow you to transport profiles and authorizations. In SU02 for example, enter a profile name, hit enter, and go to the profile menu option. You can choose transport and SAP will give you a list of profiles to choose from. Along with the transport of the profile, it will move all the dependent profiles and authorizations too. (This is not a new 3.0B function, I could do it with 2.2d+ also)

This works for transporting new or existing objects (profiles and authorizations) but it won't work for removing the objects. As far as I can figure out, you still have to delete manually from other instances.

Question:I've developed a few user tables for an interfacing application. These user tables should be allowed to be maintained only by certain users using transaction SM31. We do not want the users to be able to maintain any other tables than these user tables.
Answer:
  1. Use SM31 to maintain TDDAT table.
  2. Create a new, unique authorisation group through the 'Valid maintenance authorisation group' option.
  3. Assign the new authorisation group to the user tables you want to protect through the 'Assignment of authorisation groups to tables' option.
  4. Create authorisation(s) for "Table Maintenance (via standard tools such as SM31)" authorisation object (you'll find it under: Basis: Administration object class).
  5. Assign the authorisation(s) to the appropriate users.

Question:There is a table (USOBT) in 3.0B that has transaction and object. But it appears to contain only the transactions that check an object when they're executed. Many objects are buried throughout the transaction that wouldn't appear on this table.
Answer:This table is filled out at the whim of SAP developers and only refects what they want to document. (It appears that it may have some relation to the profile generator SU04). SU04 and SU22 have the look and feel of a work in progress. (3.0)

The tools I recommend for the authorization search are: trace, debug, SU53 and widely ignored but increasingly useful--reading SAP's documentation. Each of these tools has limitations. Even the improved system trace for authorizations and values can yield misleading and incomplete results if misinterpreted.

Question:We are currently analyzing all of the SAP transactions and their corresponding authorization objects to determine how to set up authorization profiles.
Answer:Some things to keep in mind about lists of authorizations and transactions.
  1. The authority check command (C call if you will) returns a return code indicating success or failure in finding an authorization in the user record. Its up to the programmer to deal with it. They don't always deal with it. However, the 2.2. and 3.0 traces don't discern that at all. This
    results in giving authorizations for objects that are not 'really' checked.
  2. Failure analysis (SU53) sometimes indicates a failure but for the reasons noted above the failure is of no consequence. Also, in 2.2 (and apparently also in 3.0) several objects may be checked in sequence. If the first one fails a second object is checked and it may or may not pass. Only the first failure is recorded.Examples are S_BTCH_ADM and S_BTCH_JOB. S_BTCH_ADM will fail on the value Y and S_BTCH_JOB may fail for another reason. Suddenly everyone has S_BTCH_ADM with a value Y when in fact only a value N and appropriate authorization for S_BTCH_JOB would do. S_BTCH_ADM with a value Y is quite a bit of authority to pass out to just anyone.
  3. As someone else pointed out, scan programs don't do well at finding dynamically built authorization checks. Also make sure (if you use these programs) that they scan function calls, includes and external FORMS.
  4. Some authorization checking is configuration dependent. What works for one company may not work for you. This is particularly true for authorization groups in master data and transactions.
  5. SAP has provided some lists in 3.0 in its new utilities. These are very useful but for reasons noted above (and time and effort required to compile) are not complete.
  6. An authorization that protects data one way may not be the same as one that protects it another way. In Controlling access to sets and groups are good examples.My recommendation is that you read and study the documentation (much improved in 3.0) and with careful reference to all other sources (listsetc.) you construct profiles and test them with data in your environemntas configured for production. You'll also want to learn how to use the
    debugger to see for yourself what's happening in authorization checks.

Question:At the moment our own custom written ABAP's (almost exclusively reports) have not been assigned to Authorization Groups. Most of them are not confidential and we would be happy if all users could access them.

However this causes a problem, in that there are so many Authorization Objects making use of the field AUTHORIZATION GROUP. I would have hoped that if the 'Authorization Group' field is left blank for a program, then access would be allowed without any specific Authorization Groups being defined in the authorizations. However this is not the case. The transaction SU53 comes up with the object that was checked, for example, Object "ABAP/4: Program run checks" and a whole lot of garbage in the 'Authorization Group' field e.g. "#.& _23l-%5". In order to give the user access one must then allocate a "*" to the Authorization Group field which is unacceptable from a security point of view. Is this a bug and ought we to be able to leave this field blank in our own ABAP's? Or do we have to create authorization groups and allocate all our ABAP's to it? (even if all of them to the same authorization group?)

Answer:Read OSS Note 39908. I had the same problem and this fixed it. I believe there is a similar problem with M_BEST_WRK where the system is looking for a blank for the Plant and won't accept a real plant number. I have submitted an OSS and await their reply. Maybe you could duplicate the error.

Question:We are in Development and frequently need to Transport Authorizations and Profiles to QA. Does anybody know of a faster way or a better routine for transporting them over to the QA System. Is there a better routine? Currently in SU02 we are selecting "Generate Work Area" then Profile>>Transport and then selecting individually (Let's talk tedium) all of the customized profiles. After hitting "Enter" it takes over an hour to generate the request. Releasing the request takes another hour then it's in the hands of the Transport administrator. Needless to say (but I'll say it anyway) this bogs down the system and is very time consuming. I would like to do this three times a week so QA always has up to date auth's and profiles but obviously can't the way we are doing it now. There is also the question of moving profiles to different clients on the same system. Is RSCLACOP the best way for that? We are running 3.0D.
Answer:One trick we use to speed up the time it takes to select the profiles is to create a "dummy" profile (ZEVERYTHING), which contains all of the Y&Z level profiles (which are the only ones we use).

Given that selection, it only takes us about 1-2 minutes to generate the request. If you are actually selecting all of them, that may be the source of your time delay. (Just a guess.)

Question:In version 2.2F, we used the S_PROGRAM authorization and the ABAP/4 program authorization attribute to secure ABAP/4 programs. In version 3.0E, in order to run SA38, the user requires the S_PROGRAM authorization with an authorization group attribute of "*". This would, in effect, remove all security from all ABAP/4 programs. Has anyone else used other methods to secure the programs?
Answer:In 3.0 d there are bugs like this which we have fixed. Run transaction SE93, put in the transaction code you want to check (in this case SA38), push 'values'. The P_GROUP field ought to be blank i.e. a space. Then your people need only be authorized for Authorization Group (P_GROUP) = ' ' If there is a * instead of a blank then this forces you to authorize for all Authorization groups. There is an OSS message to this effect.

Question:I have a customer request to control access to the Units of Measure table T006, specifically configurations. The request is for about three people to have IMG configuration for the table.
Answer:Just create a new group...change the T006 table to this new group...Create the authorization/Profile (S_TABU_DIS)...That it's..

Question:It seems that a user with the S_QUERY authorization to change queries can do so for all user groups that they are assigned to. We are interested in protecting some queries from being changed while allowing end users to create/modify other queries. Is there a way to limit authorization based on user group? Has anyone else run into this problem?
Answer:First of all: I would recommend you to keep the creation of functional areas and Second: If you give the activity '02' in object 'S_QUERY', the enduser can only To put further security in ABAP/4 queries, please use the field 'Authorization G