DFCON & ORGPD – Auth Switches

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.

OOAC - DFCON and ORGPD Switches
OOAC – DFCON and ORGPD 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.

Org Assignment - Default Position with no Org Unit
Org Assignment – Default Position with no Org Unit
Org Assignment - Default Position with Org Unit
Org Assignment – Default Position with Org Unit

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 *.

P_ABAP (HR Reporting)

The authorization checks for PA master data (through P_ORGIN, P_ORGXX, P_PERNR, etc) while running HR reports are very involved and pose a significant performance penalty to the system. For each pernr selected in the report, the authorization system carries out a check for each of the infotypes being accessed.

The P_ABAP (HR Reporting) is used in such cases to simplify the authorization check for PA master data when running HR Reports based on the logical databases SAPDBPNP or SAPDBPAP. The fields available in the object are given below

Authorization Field Long Text
COARS Degree of Simplification of the Authorization Check
REPID ABAP Report Name

The COARS field can two values corresponding to two different degrees of simplification.

  • COARS = 1. The authorization checks for the infotype/subtype combination and for organizational assignment are to be checked separately.
  • COARS = 2. The report is run without any authorization checks for PA master data.

In practice, P_ABAP can be used in two main cases. A value of COARS = 1 can simplify the authorization checks significantly reducing the time needed to execute a report. This is the case for a number of reports in the pay-time component of HCM. For example, an export of PA master data during a typical payroll run would have to read a large number of PA infotypes for all the employees in the enterprise. Using P_ABAP in this case would ensure that the report completes in a reasonable amount of time. Also since these reports are generally run by payroll staff who already have access to almost all user data, a detailed authorization check for all users’ infotypes is often unneccessary.

A second case for using P_ABAP appears when we want non HR users to be able to run some non sensitive reports on HR data without giving them direct access to P_ORGIN, P_ORGXX and similar objects. A value of COARS = 2 would enable these users to run the said report without any authorization check for PA master data.

Its important to note that a P_ABAP authorization is always restricted to particular reports as a value of * or SAPDBPNP would allow any reports on master data to be run without checking proper authority checks.

Securing PD Data

Personnel Development (PD) Data is part of the Personnel Planning (PP) Data model used in SAP HCM. The PP Data model is made up distinct HR object types like positions (S), Persons (P), Jobs (C), Tasks (K), etc. The main use of this data is in Personnel Development (PD), Organizational Management (OM) and the Training and Event Management sub-modules of SAP HCM. In contrast to the PA master data which essentially store data for persons, PD data mainly store the attributes of the different PP object types. Also, the allowed PP infotypes depends on the object type and is controlled through configuration settings. PD data is specially relevant for security as it used to define the Organizational Structure of an enterprise and Organizational Structure in turn is used for the position based security assignment and structural authorizations.

PD data is secured by the authorization object, PLOG (Personnel Planing). The fields of this objects are given below.

Authorization Field Long Text
PLVAR Plan Version
OTYPE Object Type
INFOTYP Infotype
SUBTYP Subtype
ISTAT Planning Status
PPFCODE Function Code

We can better appreciate the use of this object by looking at one of the basic transactions for maintenance of PD data – PP01.

PP01-Initial Screen
PP01-Initial Screen

In the initial screen of PP01, we can easily spot the fields for Plan Version, Object types, Infotypes and Planing Status (the tabs for Active, Planned, Submitted, Approved, Rejected). The buttons highlighted in the toolbar are for different activities on the infotype selected. The permissible activities for the object and infotype combination are contained in the PFCODE field of the authorization object. Among the huge multitude of possible values of PFCODE like INSE (create), disp (display), DEL (delete), CUTI (delimit), LISD (List Display), AEND (Change), LIST (List Display with Change), etc we discuss only the last two.

In the first example we select infotype Object (IT 1000) and click the change button. The infotype change screen allows us to change the name and abbreviation of the object (AEND)

PP01- Change Object
PP01- Change Object

In the second example, we select Relationship (IT 1001) and click the second button from right to get into the Overview Screen which shows all the “relationships” created for the Object. The access being tested is LIST. Also note, that accessing overview screen from a pure display transaction like PP01_disp would have checked for LISD (List display). IT 1001 is also one of the PD infotypes which can be secured at the subtype level. Each relationship record shown on the screen (like A002 – reports, B007 describes) is a separate subtype and is meant to link two different object types. The different relationships between these PP objects is actually used to build the entire Organizational Hierarchy of the enterprise.

PP01- List Display With Change
PP01- List Display With Change

In addition to the PLOG object, PP objects can be further secured through Structural Authorizations. I hope to cover a discussion of Structural Authorizations in a future article.

Securing PA Data

We have already come across PA (Personnel Admin) master data in our initial discussion of different types of the HR data. Out of the box, SAP provides three main authorization objects for securing PA master data, P_ORGIN, P_ORGXX and P_PERNR. Lets see how we can use each one of these in our security design landscape.

PA master data stored in different infotypes is essentially the attributes for the employees of the organisation. To store these attributes each employee is associated with an unique personnel number or PERNR. SAP HCM currently allows a person to have multiple pernrs as part of its extended configuration but that is beyond the scope of our discussion on basic HR security. The basic transaction for maintenance of PA master data is PA30. The first screenprint shows the initial screen of PA30 with the pernr and name of an employee.

PA30 - Initial screen
PA30 - Initial screen

In HR, the pernr similar in use to the system id used in the security system. In fact we use the infotype 0105 (communication), subtype 0001 to store the SAP system id corresponding to the pernr for an user. Later we will find that this link is mandatory for the use of the P_PERNR authorization object.

PA30 - Infotype 0105
PA30 - Infotype 0105

The first step in using any of the PA master data authorization objects is switching on the corrsonding authorization switches for them in the transaction OOAC. For ex, to switch on security checks for P_ORGIN and P_PERNR we need to set the authorization switches AUTSW-ORGIN and AUTSW-PERNR values to 1 respectively. Once switched on, any access to PA master data will check the user master for these authorization objects.

The most important infotype with regard to any discussion on PA master data security is the Organisation Assignment (0001) infotype. The screenprint below shows the IT 0001 screen with the different data contained in it. This infotype is important as the data fields of this infotype are also part of the general authorization objects and are checked during data access. For ex, Personnel Area, EE group, EE subgroup, Cost Center, Payroll Area and the three Administrator fields are all used in the authorization objects.

PA30 - Infotype 0001
PA30 - Infotype 0001

The three common authorization objects with their authorization fields are given below

P_ORGIN (HR: Master Data)

Authorization Field

Long Text

INFTY

Infotype

SUBTY

Subtype

AUTHC

Authorization Level

PERSA

Personnel Area

PERSG

Employee Group

PERSK

Employee Subgroup

VDSK1

Organizational Key

P_ORGXX (HR: Master Data – Extended Check)

Authorization Field

Long Text

INFTY

Infotype

SUBTY

Subtype

AUTHC

Authorization Level

SACHA

Payroll Administrator

SACHP

Master Data Administrator

SACHZ

Time Recording Administrator

SBMOD

Administrator Group

P_PERNR (HR: Master Data – Personnel Number Check)

Authorization Field

Long Text

AUTHC

Authorization Level

PSIGN

Interpretation of Assigned Authorization

INFTY

Infotype

SUBTY

Subtype

As you might have noticed, many of these fields were part of the org assignment infotype. Thus if a security concept is built around personnel area, employee group, employee subgroup we can switch on the check for P_ORGIN and use the auth object in our roles or if the security concept is based around the time, master data and payroll administrators we can use the P_ORGXX authorization object. In some rare scenarios we might even want to use both the authorization objects in our roles. A case where both of them might be used is a scenario where we have different master data administrators for a single personnel area. Here instead of creating of roles with all the different combinations for P_ORGIN (Personnel Area) and P_ORGXX (Administrators), we can reduce the number the of roles by separting out these two accesses into different roles. Finally a combination of the P_ORGIN and P_ORGXX roles will be assigned to a user to make up the total accesss of a HR rep. You would also notice that the standard authorization objects do not have any option to secure PA data at the level of the personnel sub area or cost center. A solution in such cases is provided by the Organization Key field. This is a 14 character field which can be configured to be derived from any of the IT 0001 fields or can be even manually entered by the administrator.

The P_PERNR authorization object is a bit different in functionality from the other two objects. The P_PERNR object provides one of the very few examples of negative authorization concept in SAP. The object is used to provide different authorization to an administrator when accessing his own PERNR. The most common example is of a compensation analyst having access to update the basic pay infotype. Though as part of his usual responsibility, hw would be expected to maintain the basic pay of other employees, we would not want him to give himself a raise. Its at this juncture that P_PERNR and its negative authorization comes to the rescue. The master data authorization of this person might typically be maintained as the following

P_ORGIN

INFTY 0008

PERSA *

AUTHC W, R, M

P_PERNR

INFTY 0008

PSIGN E

AUTHC W, D, S, E

In the above case, the P_ORGIN authorization gives the comp analyst access to maintain (AUTHC – W – Write) the basic pay (IT 0008) for others but when accessing his own pernr, the value of P_ORGIN is over-ridden by the access in P_PERNR. The value of PSIGN as E (Exclusive) denotes that while accessing IT 0008 for his own pernr, his access will exclude the values maintained for AUTHC (W, D, S, E). The only possible values for AUTHC which excludes the 4 given values are R (Read) and M (matchcode) and as a result the administrator only has display access to his own pay data.

Its very important to remember a few points when trying to use P_PERNR. Firstly P_PERNR can only be used to provide access to a person’s own pernr or personnel record. A corollary of this, is the requirement that for P_PERNR to work a valid system id should be maintained for IT 0105, subtype 0001. This is necessary as the SAP system needs to identify a personnel record with a user master record. Secondly, the only two possible values of the PSIGN field are E (Exclusive) and I (Inclusive). A value of * doesn’t make much in this case as by definition, a * value can be interpreted as either of the two possible values.

Types of HR Data

A discussion of SAP security for a particular application area, like HR, FICO, SD, MM generally starts with an outline of the applications/transactions for the particular area and the authorization objects needed to secure them. This is fully justified as most of the time, security administrators are given a list of tcodes and asked to provide security for them. Starting from the t-code list we would normally look up the individual SU24 entries, look up the documentation for the linked authorization objects, determine if the default values of the linked authorization objects are enough to grant access, investigate whether the SU24 entries for the transaction should be changed and maintain appropriate values for the objects in the roles depending on requested access.
In the present article, we will adopt a slightly different approach for HR. Instead of the transactions that we are trying to secure, let us instead start with a discussion of the data we are trying to secure. SAP application security is remarkably consisitent while accessing the same data, even though data is accessed through different transactions. So once we get a hang of the authorization objects needed to secure a class of data, we can basically use the same objects to secure any transaction which use the same data. HR data, other than configuration data, are contained in three basic groups of tables.

Personnel Administration (PA) data consists of attributes for people, whether employees or applicants and is stored in the PA infotypes. We have already come across PA data in our introductory article on Infotypes. Each infotype in general is associated with a table in the Data Dictionary. Data for employees are stored in PA tables while data for applicants are stored in PB tables. For ex, employee addresses will be stored in PA0006 while applicant addresses is stored in PB0006. All PA and PB tables share a common authorization group PA. So unless we are prepared to modify the default authorization groups for each table, a person with access to PA authorization group through standard table maintenance transactions (like SE16, SM30, SM31), will have access to ALL the PA/PB tables. Due to the sensitive and private nature of PA data, this level of access is rarely given to any user in a production system. Instead access is given to individual infotype, subtype combinations. The authorization objects to secure PA data for employees are P_ORGIN (CON), P_ORGXX (CON) and P_PERNR while P_APPL is used to secure PA data for applicants.

Personnel Planning (PP) data store for “HR Objects”. These objects are identified by letter codes like Person (P), Position (P), Organization Unit (O), Job (C), Cost Center (K), Task (T), etc. These different HR objects are used for Personnel Planning, Personnel Development or Organizational Management. PP data is also stored in infotypes but the underlying tables are of the form HRPXXXX where XXXX = unique infotype id. (Ex Infotype Object (1000) is stored in table HRP1000. Some PP infotype like IT 1017 have both a corresponding HRP and HRT tables, HRP1017 and HRT1017. This is determined by the structure of the infotypes and deson’t impact security). Security for PP infotypes is controlled by authorization Object PLOG.

The final major type of HR data are contained in HR clusters. These are cluster tables PCL1, PCL2, PCL3, etc which store time evaluation results, payroll results, etc. Access to HR payroll clusters is controlled through the P_PCLX authorization object.

Now let us leverage our knowledge of the different types of HR data and the corresponding authorization objects to provide security for one of the most common HR transactions, PA30 which allows the maintenance of HR Master Data.Specifically we use the transaction to maintain the address of a user. The first screen shows the initial PA30 screen when we have selected the user to modify.

PA30 - Initial Screen
PA30 - Initial Screen

Now we select the address infotype and click the change button which leads us into the Address screen. We can update the address maintained for the employee. In addition PA30 allows us to save maintain text for an infotype entry by using the menu path Edit->Maintain text. An infotype with maintained text is indicated by the higlighted text icon in the infotype header as shown below.

PA30 - Update Address
PA30 - Update Address

In the sequence of actions above we update address (IT 0006) of an employee. Since address is an attribute of an employee we know that we are dealing with PA data. As a double confirmation, address data is stored in IT 0006 which falls in the range of PA infotypes (refer to the earlier post on infotypes for individual ranges). Hence we would need to provide update access (W = Write )to authorization objects P_ORGIN (CON), P_ORGXX (CON) and P_PERNR for infotype 0006. Which of these objects are actually checked are determined by the values of the authorization switches which we have already encountered in an earlier post. In addition to the actual address we also maintained some text for the infotype entry. This text however is not stored in the infotype table but in cluster tables. So an update access to P_PCLX is needed as well. The su24 entry for PA30 makes our job easy as it already provides the default cluster id which stores the text (clusters PC and TX). We are not updating attributes for any HR objects in the above sequence. So we do not need to be concerned with PLOG. However, there are other operations in PA30 which infact updates PD data. Hence, SU24 defaults for PA30, list PLOG as well.

The above analysis becomes specially useful when trying to secure obscure t-codes without correct SU24 defaults maintained. Once we understand what kind of data the t-code is accessing, we can predict what all security is needed to execute it.

Infotypes

Infotypes or Information Types always form an integral component of any discussion on SAP HCM. In general infotypes are structures to stores related HR data. For example, address of an employee is stored in an unique infotype 0006. Similarly we have different infotypes storing personal data (0002), bank details (0009) , basic salary (0008), etc. Some infotypes are further sub-divided into subtypes, an example being the address infotype. An address entry can belong to the subtype permanent residence, temporary residence, emergency address, mailing address, etc. Infotypes are relevant from a security standpoint as SAP provides standard authorization objects which allow us to secure infotype, subtype combinations for users.

The first thing to note from the above examples is that all of them are attributes of a person. You store address of a person, salary of a person, bank details of a person. Howver, infotypes can just as well store attrbutes of HR objects like positions, jobs, tasks, etc. Depending on whether an infotype stores attributes for a person or a HR object, we can divide them into infotypes required in Personnel Administration (PA) or Personnel Planning (PP) respectively. The PP infotypes are also referrred to as infotypes for Organizational Management (OM)or Personnel Development (PD). The distinction between PA and PP infotypes is important for security as the two basic types of infotypes are secured by means of different authorization objects.

Another point to note from the above examples is the fact that each infotype is associated with an unique 4 digit number. This unique identifier might vary from 0000 to 9999 and is broken into sub-ranges depending on the type of the information stored as shown below

  • 0000 – 0999 – Personnel Administration (PA)
  • 1000 – 1999 – Personnel Planning (PP)
  • 2000 – 2999 – Time Management (PA)
  • 4000 – 4999 – Recruitment (PA)
  • 9000 – 9999 – Customer Specific (Can store either PA or PP information depending on infotype configuration

This preliminary introduction to infotypes would help us in our later discussions when we investigate ways to secure individual infotypes.

HR Basics

SAP HR deals with private employee data much of which might be of sensitive nature. As a result the HR security is typically more stringent that security for the other SAP modules. In a lot of non HR applications, security is more geared towards prevention of wrongful entry of data into the system. However, in the case of HR, even the display of private data might lead to non compliance with prevailing laws and regulations.

Other than the overtly sensitive nature of HR data,another reason of separating it out into its own category on this site is to emphasize  two unique provisions in HR.

  • Firstly, most of SAP security is based on positive authorization, i.e presence of a particular authorization in the user buffer gives access to new functionality. HR is one area where negative authorization can also be used in addition to the existing positive authorizations. Negative authorization in this case prevents an user from accessing some application due to the presence of a certain authorization in his user buffer.
  • Secondly, HR uses structural authorizations to restrict HR access to a certain hierarchy within an authorization independent to the general authorizations assigned through roles.

SAP HCM

Human Capital Management or SAP HR is the SAP module dealing with Human Resources and includes business processes like

  • Recruitment
  • Personnel Administration
  • Personnel Development
  • Payroll
  • Compensation Management
  • Training & Event Management