Maybe I am being cynical here, but I would still say that its very rare that SAP comes up with something that reduces the daily drudgery we go through as security consultants. Today I discovered something from my colleagues that is really one of the best things I have seen in a very long time. SAP has come up with a new and improved version of the standard security trace ST01. The new transaction can be launched by using the tcode “STAUTHTRACE”. Continue reading “STAUTHTRACE”
Its quite common in the SAP world that one transaction calls another via different menu options. At the code level this is often implemented via the ABAP construct “CALL TRANSACTION”. We know that to start a transaction from menu or typing via the command window, a S_TCODE check is performed at the SAP kernel level. However whether a S_TCODE check is performed for the CALL TRANSACTION statement can be controlled by us through the SE97 tcode. Its not often that we need to mess with the SE97 settings but its good to know about the option is available if needed. Continue reading “SE97 and TCDCOUPLES”
This is a continuation of the many different articles on this blog around security around tables. However, the articles till now has concentrated on the different methods provided by SAP to restrict access to tables. Today’s article on the other hand will talk about a common method of accessing tables, the security implications for this form of access and how we react as security consultant when faced with requests for this form of access. Continue reading “SE16N and SAP_EDIT”
The SE03 transaction (Transport Organizer Tools) is certainly not a security specific application. However it provides at least one report which I find to be invaluable in managing security transports. Basically the report provides all transports (modifiable/ released) which contain a particular role.
We start with the initial screen for SE03 which is really a kind of cockpit to run various applications for transports.
We chose the report “Search for Objects in Requests/Tasks” which gets us to the next screen. To search for roles we need to enter a line with object type ACGR (Activity Group which is old SAP terminology for role), check the relevant boxes as shown and click the execute button.
The output of the report display all transports which contained the affected role.
Though we have just used it for search for roles, we can search for any development objects like Programs, Tables, Org Criterions to ensure that the latest transports are all moved to Production or that no unreleased transports for an object remains in the system.
My apologies if the title of the post make no sense. Probably that’s because of the relatively niche nature of the topic. However, in the last few months, I have come across a few installations where people have run into issues due to security configuration around access to non integrated positions (the so called default position) and thought a new post might be in order.
Both DFCON and ORGPD are authorization switches (refer to my post on Authorization Switches for some background) which control how your SAP security system handles access to employees with non integrated positions (these are the people who exist in the HR component but are not linked to any positions in the Org Mgmt Structure). Setting the proper values for these switches is an one time activity when configuring Structural Authorizations in your SAP system. Since structural authorizations use the OM structure to control access to employees, its a valid question “How do you want to control access to EEs/Pernrs which are not part of the OM structure?” These authorization switches help answer the question. The screen below shows a view from transaction OOAC using the switches.
Note that both these switches control access to non integrated persons but shouldn’t be used at the same time. Use ORGPD switch when using plain vanilla structural authorizations and DFCON when using the context solution. There is also a slight difference in the meaning of the different values possible.
Access to these non integrated persons can be controlled by the value of the Org Unit stored in infotype 0001 (org Assignment). However if there is no org unit also maintained in the infotype, the system provides the option of giving/ denying access to all these persons. These two different cases are highlighted in the below screenshots from IT 0001.
Possible Values for ORGPD/ DFCON and their meaning
1 = Check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. if no values are maintained in IT 0001, deny authorization to the person.
2 = Do not check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. Deny access to all these persons.
3 = Check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. if no values are maintained in IT 0001, give authorization to the person.
4 = Do not check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. Give access to all these persons.
0 (ORGPD) = Structural Authorizations are switched off. So the check for pernrs not present in OM doesn’t arise.
0(DFCON) = Same behavior as maintaining 1 for DFCON with one important difference. Context solution is activated by switching on one or more of the INCON, XXCON, NNCON switches which in turn activates authority check for the P_ORGINCON, P_ORGXXCON or the custom Z object. I would explain with an example, For DFCON = 1, INCON = 1 you would need an authorization with P_ORGINCON with all values * (PROFL, PERSA, etc) to get access to pernrs with default position and no org unit maintained. For DFCON = 0, INCON = 1 you would need an authorization with P_ORGINCON with PROFL value * to get access to pernrs with default position and no org unit maintained. PERSA need not be *.
SAP CRM allows role assignment in two basic ways, indirectly through Business Roles in PPOMA_CRM or directly through security roles assigned to user masters in SU01.
Indirecty role assignment is recommended by SAP as for large organisations with many CRM users and business roles it can lead to significant reduction in maintenance effort. For indirect maintenace, the Business Roles are maintained on a position for a user.
To maintain the business role for an OM object like a position, we select the position in PPOMA_CRM and the menu path goto>detail object>Enhanced Object Description which opens transaction PP01.
From the initial PP01 screen, we can maintain the appropriate value for Business Role for the chosen position.
With the position linked to a user and a business role assigned to the position we are now in a position to assign a security role to the user. While its also possible to directly assign a security role to the user at this stage, SAP provides the report CRMD_UI_ROLE_ASSIGN to make our job easier.
The report can be run for both users or user groups. It basically looks up positions linked to the respective users, checks the business roles assigned to these positions and finally assigns the security roles corresponsing to them to the user masters. The report log after role assignment is shown below
It is also possible to directly assign a security role to a user rather than go through these intermediate steps outlines above. To make this work, in addition to the security role the user parameter CRM_UI_PROFILE needs to be maintained with the correct business role as part of the user master. This removes the need of maintaining the Business Role on the position. However, since all CRM users need to be part of OM structure, it makes sense to use the indirect assignement rather than the direct one.
Transaction variants allows us to selectively mask certain fields in SAP transactions/screens. Though strictly not a security tool, transaction variants can have applications in security by helping to prevent users from updating fields which are not protected through authorization objects
Transaction Variants are created trough the SHD0 t-code. The initial screen SHD0 is given below. To create a transaction variant we mention the name of the parent transaction, give a name of the variant and click the create button.
In our example below, we create a transaction variant ZSU01 for the very common SU01 tcode. The transaction variant allows an administrator only to reset passwords and hides all other functions of SU01. Each transaction variant contains of one or more screen variants depending on the number of screens being called in the entire transaction flow. We don’t have to manually keep track of the screen variants when we are working with transaction variants. As we move from one screen to the next, SHD0 automatically creates and appends a new screen variant to the sequence.
On clicking the create button for ZSU01, we are taken to the standard SU01 screen. We enter a user name and click the change password button. A pop-up window appears with a list of the screen fields. This window contains the attributes of our first screen variant. Its here where we enter a name of the screen variant and can selectively mark screen fields to invisible/output only/required, etc.
The screen variant window has a button for “Menu Functions” where we can selectively hide/de-activate menu items or toolbar buttons. Since our intention is to disable everything except password change options, we end up with below screen.
On clicking the check button from the screen variant we are taken to the next screen and need to save our entries for the password change screen.
On clicking, the save and exit button we are taken to the overview screen for the transaction variant. As shown below, this screen gives the definition of the individual screen variants which form part of the transaction variant. On saving our entries, we are taken to the SHD0 initial screen which shows the transaction variant and the screen variants defined under it.
SHD0 provides a test button here we can check if the newly created transaction variants works as per our requirement. Once tested we create a new Z transaction (ZSU01) for the transaction variant by following the menu path Goto>Create Variant Transaction.
Once set up, this new transaction can be assigned to a user’s role just like a normal transaction. Executing, ZSU01 display a modified form of SU01 screen with all functions other than change password button is disabled.
The SU25 transaction is needed during the initial installation of SAP and during each subsequent upgrade. Its main utility is to copy the SAP provided check indicator defaults from the USOBT and USOBX tables to the corresponding customer tables, USOBT_C and USOBX_C. These two sets of tables are needed so that the customer changes are not over-written by SAP delivered values during a future upgrade. The initial screen of the tcode is shown below.
As can be noted, the SU25 transaction is organized as a sequence of actions which need to be executed in order during installation/upgrade depending on requirement. For example, the first step (1) is to initially fill the customer tables (USOBT_C and USOBX_C) is ONLY executed during initial installation of SAP. Executing this step during a future upgrade will over-write all customer changes to check indicators.
The next set of steps compare the customer values with SAP delivered values. We have the option of accepting one or more of SAP proposed values while keeping the customer values for the rest of the objects. Since any change to check indicators for a transaction will impact all roles with it, a change during SU25 should be thorough analyzed and backed up by rigorous testing of the affected transaction.
The SU25 initial screen also has options to transport the new values for the customer tables, modify and generate roles which are affected by changes made for check indicators or even branch to SU24. Its also a good practice to document all changes performed during SU25 to help in future decision making around security.
We have already come across LSMW for mass changes to SAP data. Let us not assume that LSMW is the only tool which can be used to update data in SAP. SAP provides quite a few number of tools, each with its unique features, to allow mass updation of data. In the current article I talk about the Transaction Recorder tool which can be accessed through the transaction SHDB. Like LSMW, SHDB is also used to record certain user actions in the SAP GUI for a particular transaction. These actions are used to create a recording which can be processed at a later time to upload data. Through SHDB it is also quite easy to generate an ABAP report from the recording and modify the generated code to read an input file with a list of records and upload the data though the program. In this article I demonstrate the entire sequence of actions though a recording to reset the password of a user through SU01.
We start the transaction SHDB and click the button for new recording. We give an appropriate name for the recording and input the transaction (SU01 in this case) which we are trying to record.
On clicking the check button, we are taken to the normal SU01 screen where we rest the password of any user id already created in the system (USER01).
On saving the new password and clicking the back button, we are returned SHDB where we can check the steps in the recording.
To test the recording we change the user id to “USER02” and save the recording. Now we can process the recording from SHDB.
On successful processing for the recording, we get a screen showing that password for USER02 was indeed changed.
Although its technically feasible to manually change the data in the recording and process them through SHDB, the generally accepted approach is to generate a program for the recording and update a list of records though ABAP code. SHDB main screen has options to generate a program from recording.
On selecting this option, SHDB prompts us for the attribute details for the program and generates a skeleton code for the recording. We can now update this skeleton code to read data records from a file into an internal table, and loop over each record to update data into SAP. I am not adding the final code in this example but the basic skeleton is given below.
As you can see from the above example, like LSMW, SHDB provides us with another alternate method of upload of data into a SAP system. Which method you finally chose depends a lot on whether you are more comfortable in writing code or creating a the LSMW script.
The standard SAP authorization trace given by ST01 is not enough for troubleshooting security issues in BW reporting. A ST01 trace will show a basic reference for the two objects S_RS_COMP and S_RS_COMP1 to check access to the query and cube but nothing further than that. SAP provides a completely new authorization trace though the RSECADMIN transaction to troubleshoot analysis authorizations. The error log button gets us to the authorization trace screen.
Once we have “configured log recording” for the affected user, the system logs all OLAP data accesses made by the user.
Displaying the log data gets us into the following screen which shows the details of the security checks for the user.
The trace first displays the name of the InfoProvider and the query name that the user executed. Next, we have a list of characteristics in the cube for which user has non full (*) access as these need to be checked at a more detail level. Lastly we have the authorization checks for these characteristics with non full authorizations. Its this section of the trace thats typically the most helpful in troubleshooting authorization issues.