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”
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 *.
The PRGN_CUST tables contains entries for a number of switches which can affect the default behavior of various security transactions. To move away from the default behavior, we need to create the entries for the switches with the appropriate values. The list of allowed entries keep on changing depending on the version of SAP being used. Hence, the best way to find the allowed list of values for your system is to open up the table in SM30 and try to enter a new entry. A search for the possible entries will display the allowed entries and also the SAP notes which describe their use.
The screen below, gives some of the possible entries for a system on SAP R/3 4.7.
SAP provides two different ways of securing OLAP data in BW. The first is the traditional, and till BW 3.5 the only way, using Z authorization objects for reporting. The second way, which was introduced as part of BI 7, uses analysis authorizations. So the first step in BW security, should always be to choose the concept which we want to use in our BW landscape.
We can reach the switch settings option through the transaction SPRO as shown below
Once inside the transaction, we just choose the appropriate authorization concept setting and save our entry. Though its appears to be a single setting, we should give some thought about which authorization concept to use as migrating from one concept to another takes a significant amount of time for design, testing and implementation.
SAP recommends that for new projects at least we use the concept of analysis authorizations for security as it provides significant advantages over the old concept. There is also the possibility that in the future SAP might stop supporting the old authorization concept completely in their products. Thus in our future discussions on BW security, I would concentrate on analysis authorizations.
Before going into detailed configuration for analysis authorizations, it might be worth to look at a few of the advantages of analysis authorizations over reporting authorization objects.
- Reporting authorization objects are Z or Y objects of the RSR class (SAP Business Information Warehouse – Reporting). As authorization objects they are limited to a maximum of 10 authorization fields per object. Analysis authorizations have no such restrictions.
- The new concept allows us to separately secure the navigational attributes used in an InfoProvider. For example, the authorization object 0COSTCENTER can have different security when it appears as an InfoObject in an InfoProvider and when it appears as a navigational attribute for another InfoObject. In the old concept, both these cases will have the same security.
SAP Business Information Warehouse – Reporting
In a large organization using structural authorizations, the PD profiles assigned to a user might return thousands of distinct objects. Evaluating the entire PD profile at run time to generate the object list, for each access to HR data, can lead to a significant degradation in performance of HR transactions. Since the performance penalty is mostly due to the evluation of the entire object list for an user during run time, the situation can be improved by storing the list of objects for a user.
SAP provides a table T77UU to store a index of all objects returned by the PD profiles for each user. However, since this is a static list of the objects we have to periodically regenerate the index for all user who are maintained in this table. If a user is not entered in this table, his PD profiles are evaluated at runtime to generate the object list. This will consume more time but will not adversely impact performance if the number of objects for the user is below a certain critical threshold.
The T77UU table is very rarely maintained manually. SAP provides two programs, RHBAUS02 – Check and compare T77UU (user data in SAP memory) and RHBAUS00 – Regeneration of INDX for Structural Authorization, to automate updation of the table and regeneration of the user indexes. The screen below shows, the selection criteria for the RHBAUS02 report. The report can be run for one or multiple users and for a certain threshold level of HR objects. The program evaluates the PD profiles for all the users entered in the selection screen and if the number of authorized objects returned is more than the threshold value updates the user in the T77UU table. Conversely if the number of objects for a user falls below the threshold, the user entry is removed from the T77UU table. Typically , a weekly batch run should be sufficient to take care of changing org structure and the profile assignment for users.
PD profiles can be assigned to users in two basic ways
- Transaction OOSB can be used to assign one or more PD profiles directly to users. Adding entries to the T77UA table through SM30/SM31 has the same effect.
- PD profiles can also be assigned to OM objects like positions through infotype 1017 (through transactions like PP01/PP03).
Also note that an user without an entry in the T77UA table would by default have the PD profile access which is assigned to the SAP* user in the table. SAP provides a standard program RHPROFL0, to read the PD profile values from IT 1017 for a position and create an entry in the T77UA table for the user assigned to the position. For SAP installations using indirect assignment of profiles, this program is generally scheduled to run in batch every night. A screen with the various options available for this program is shown below.
- Assigning the PD profiles to the position instead of direct assignment in the T77UA table can potentially save a lot of effort in manual maintenance of profile entries and is the recommended practice.
PD profiles are created through the OOSP transaction. SAP provides a few standard profiles but to a large extent, PD profiles are created by individual customer depending on their requirements.
The definition of PD profiles is stored in the T77PR table. Lets have a look at the definition of the standard PD profile for “MANAGER”
Some features to note about the definition of the PD profile.
- Each record in the table is independent of the other records and gives access to a certain number of objects.
- Each record has values for PV (Plan Version), OT (Object Type ), Object ID, EvalPath (Evaluation Path), StatV (Status Vector), Depth, M (Maintenance Flag), Selection Period and Function Module.
- PV denotes the plan version for which the profile is valid.
- OT is the object type of the object id value.
- Object ID gives the start object when an evaluation path is used in the profile or an individual object.
- If evaluation path is maintained, the PD profile returns the object along the PD profile. maintaining an evaluation path will only work if a start object value is maintained explicitly or dynamically through Function Modules.
- Status Vector is used to determine the status of the objects/relationships while creating the structure. A StatV of 12 for example will consider relationships of status Active (1) or Planned (2).
- Depth determines the level of the hierarchial structure till which the evaluation path is constructed. No maintained value indicates that the entire org structure returned by the evaluation path will be constructed.
- Maintenance(M) flag determines whether a person will be able to maintain the returned objects.
- Period determines the validity period of the objects/relationships while creating the structure. A value of D creates the structure which is valid on that day. A blank value indicates that the structure is not limited by the validity dates for the corresponding relationships.
- The function module field can be used to dynamically generate a start object. Efficient use of this option can greatly reduce the maintenance effort for PD profiles. Two standard function modules are supplied by SAP, RH_GET_MANAGER_ASSIGNMENT returns the org unit for which the user is a chief while RH_GET_ORG_ASSIGNMENT returns the org unit for a user. New function modules can be created by customers as per requirement.
Structural Authorizations as the name suggests are used to restrict access to a certain organizational structure. As such they are only used while accessing HR data. In general, structural authorizations serve two purposes
- Restrict access to certain OM objects like Org Units, Jobs, Tasks, Qualification Catalogs etc.
- In interaction with the access to authorization objects for PA master data, they can restrict access to certain set of persons in the enterprise.
While using structural authorizations, its important to note that
- A person’s total authorization is a result of the interaction between his general authorizations (through roles) and his structural authorizations (through PD profiles).
- Secondly, structural authorizations are always used to restrict access. You can never use structural authorizations to grant access. It can only be used to restrict access to a smaller set of objects or people than is already given though a general authorizations.
- While using structural authorizations to restrict access, we need to ensure to add access to the corresponding objects are also added to the user’s roles through PLOG.
Since we have already extensively discussed, security roles and their assignment we will use the next few articles to describe PD profiles and their assignment.
An Evaluation Path is a chain of relationships between related OM objects in the Organizational Hierarchy. Different evaluation paths can be used to return different sets of OM objects even when all of the individual paths start from the same start object. As such, evaluation paths are used in a lot in OM reports and in structural authorizations.
Evaluation Paths are created/maintained through the transaction OOAW shown below. The standard SAP system ships with a number of pre-defined evaluation paths. Since the standard evaluation paths can only use the standard relationships and objects defined in SAP, it stands to reason that we need to create new evaluation paths to use our own relationships/OM objects.
As an example we select the evaluation path PERSON and see how its defined
The PERSON evaluation path is meant to return the OM objects used in staffing along a standard organizational hierarchy. As such it can be used to evaluate the reportees of a line supervisor and is used as such in the MANAGER structural profile. The definition of the evaluation path starts with an org unit. The path returns all positions (S) assigned to the start org unit (O) and the persons (P) linked to the said positions. Finally to build the entire org hierarchy the path continues to evaluate the sub-ordinate org units and positions (lines 30 and 40).
Once defined, the evaluation path can be used to return a particular view of the org hierarchy through the PPST transaction.
The report output shows the evaluated objects.
In the next article, we explore the use of evaluation paths in defining structural authorizations or PD profiles
In our article on SU24, we saw the feasibility of selectively switching off checks for certain authorization objects. However, HR objects (objects for authorization class HR) can not be marked as “Do not check”. Howver, there is another option for selectively switching off checks for HR objects. This is done be setting the values of authorization switches (through transaction OOAC) or directly modifying the HR config table (T77S0). The available authorization switches are shown below.
You can look at the standard SAP documentation for the functionality of each of the switches but let me list a few of them
- AUTSW – ORGIN – Switch on (1) or off (0) for authorization object P_ORGIN. This object is used to check for access to Personnel Admininstration (PA) master data through infotypes.
- AUTSW – PERNR – Switch on or off check for P_PERNR object for an employee’s own personnel number
- AUTSW – ORGPD – Switch off (0) or on (1,2,3,4) the structural authorization checks.