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

Context Solution

In the modern enterprises, its very common that dual responsibilities are performed by the same individual. For example a Line Manager in the Training department of an Organization needs access to certain infotypes (like org assignment, personal data, education, etc) for all employees as part of the process structure. In addition to the above, by virtue of his position in the org hierarchy as a Line Manager, he would also need significantly more access (like basic pay for instance) to the employees who report up to him. This is problem of contextual security and is can not be handled properly through the structures that we have covered so far.

Let us investigate further about the possible security solution in this case and try to understand why it might not meet the full requirements. We would need at least two roles for the training manager – on role with training infotypes and a second one with infotypes needed by the line manager. Further we also likely to have two PD profiles as well – on with access to all employees and the other with access to only the direct reports. When the 2 structural and general authorization profiles are assigned to the same person, like to the Training Manager in our discussion, we find that he has access to both sensitive and non sensitive infotypes for all employees. The sensitive access is not limited to only the direct reports as the security system has no way of understanding that access in the manager role needs to be restricted to only the direct reports (the people who are part of the manager PD profile).

The context solution introduced as part of SAP R/3 4.7 seeks to address this very gap in HR security. The context solution introduces new authorization switches and the corresponding authorization objects. To switch on checks for any of the new objects, the corresponding switches should be set to 1. Its also customary to switch off checks(value 0) for the non context authorization objects. The relevant switches are given below

  • AUTSW-INCON HR: Master Data (Context) for object P_ORGINCON
  • AUTSW-XXCON HR: Master Data – Enhanced Check (Context) for object P_ORGXXCON
  • AUTSW-NNCON HR:Customer-Specific Authorization Check (Context) for customer specific authorization object. The switch corresponds to AUTSW-NNNNN (HR: Customer-Specific Authorization Check) in the non context solution.

In addition to the three switches above there is a fourth switch used by the context solution. This last switch – AUTSW – DFCON – HR: Default Position (Context) – is analogous to ORGPD switch used in normal structural authorization as it controls access to non integrated personnel numbers (persons who are on a default position and as a result are not mapped to the organizational structure).

The fields for the individual authorization objects P_ORGINCON and P_ORGXXCON are given below.


Authorization Field Long Text
INFTY Infotype
SUBTY Subtype
AUTHC Authorization Level
PERSA Personnel Area
PERSG Employee Group
PERSK Employee Subgroup
VDSK 1 Organizational Key
PROFL Authorization Profile


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
PROFL Authorization Profile

You will notice that new authorization objects differ from the corresponding old objects in a single respect. Both of these have the new field PROFL (Authorization Profile). The PROFL field is meant to store the value of the PD profile for which each general authorization is valid. In other words, the PROFL field serves to link the general authorization with the corresponding structural authorization. Context problems, like the one we discussed about the Training manager, can now be easily solved by maintaining the correct PD profile on the role.

The context solution is truly a welcome addition to the other security features of SAP HCM as it allows us to solve scenarios which couldn’t be solved with the means at our disposal till now. However it comes at the cost of increaded maintenance effort as now in addition the PD profiles assigned to the user, we need to maintain the correct PD profiles for the role as well. Also, we should remember that the context solution only addresses the context problems for accessing people (PA master data). There is still no context solution for PD data secured through PLOG.

PD Profiles – Performance

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.

RHBAUS02 - Update user data in SAP memory
RHBAUS02 - Update user data in SAP memory
The RHBAUS00 program is generally run after the last run for RHBAUS02 has completed and hence finished updating entries in T77UU. The RHBAUS00 program re-generates the indexes, and hence the objects authorized for a user, for all users entered in selection whose entries also exist in T77UU. In a practical scenario the OM structure of an enterprise keeps changing from day to day. Since, the index only stores the objects that were effective during the last time when it was re-generated, RHBAUS00 should be scheduled to be run periodically. A daily batch run for the program is mostly sufficient to take care of the changing org structure however even in such cases, indexes of individual users might need to be specifically regenerated through the program or its linked tcode, S_PH0_48000110.
RHBAUS00 - Regenerate user INDX
RHBAUS00 - Regenerate user INDX

PD Profiles – Definition

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.

OOSP - PD Profiles
OOSP - PD Profiles

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”

T77PR - PD Profile Definition
T77PR - PD Profile Definition

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

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.