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.
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 *.
Aninda,
I have configured my OOAC swithces as follow:
AUTSW ADAYS 15
AUTSW APPRO 0
AUTSW DFCON 4
AUTSW INCON 1
AUTSW NNCON 0
AUTSW NNNNN 0
AUTSW ORGIN 0
AUTSW ORGPD 1
AUTSW ORGXX 0
AUTSW PERNR 1
AUTSW XXCON 0
I do not see how Context will work if ORGDP=0. My understanding of the CONTEXT solution is that there has to be an intersection between Structural authorization and general authorization. So far my OOAC switches work with no problems except today I noticed that if ORG ASSGMNT=00000000
and POSITION = 99999999 then I get an authorization error. You sugested that PERSA should be assigned the value *. What if the client wants to restrict access to PERSA as I am facing? How do I get non-intergrated positions discribed above to work without authorization errors?
2. How do I get RHBAUS02/RHBAUS00 to run immediately following any object assignment /update to user without always going back into SE38 to run those reports? Can I schedule these reports to run constantly..I mean immediately following changes in the user’s object repository?
Thank you
Atta
The switch ORGPD was used for Structural Authorization in a non context scenario. In the context solution, ORGPD has been replaced by DFCON which controls access to non integrated pernr and INCON, XXCON and NNCON switches which control the authority checks for PA auth objects. In your case the ORGPD value is interfering with the DFCON value and restricting access. Try changing value to 0 which should take care of the issue you reported.
The best practice while using RHBAUS02/RHBAUS00 is to schedule it to run in background once every day. As far as I know you can not automate it to run evry time the OM structure is changed, neither is it advisable to run them like this as that would cause a needless load on server resource. Also investigate if you need these jobs at all. As long as the OM objects per user is less than 1000 or so, these jobs are not going to make too much of a difference.
Thank you very much. Resetting ORGPD =0 has fixed another authorization error message when POSITION=99999999 and
ORG Unit is NOT equal to 00000000
Excellent work Aninda.
Greetings,
I have set DFCON=4.(Do not evaluate ,grant access by default to 99999999 positions). I had to chane to this setting when the HR team couldn’t enter data for contractors and temps. It works exactly as expected except it grants access in all areas regardless of what PROFL value is set for the substructure.
For example, A Time Administrator in Chicago is able to enter CATS records for position 99999999 in say Columbia and infact for all position 999999999 regardless of the ORG Unit assignment. Is there anything I can recomend to restrict non intergrated poosition access by Time Admins? You think INFOTYPE 0003 with a LOCKED payroll status will surfice to prevent any risk of entering time data and paying retirees by accident?
Hi Atta,
Please go through this article and try to understand how each of the possible values of the DFCON switch works. In your case, a value of DFCON of 0 or 1 would be a better compromise than the values of 2 or 4 you are using.
Thanks,
Aninda
Hi Aninda,
Thanks for responding. I will keep changing DFCON values to see which one works well for my set up.
Hi Aninda,
How does MSS PD profile work? Is the MSS PD profile also provided as default from SAP like the “ALL” PD profile? Can you provide some insight into automating MSS-PD profile assignment to managers? My stratergy is to assign the MSS PD profile to each manager’s position in the structure as well as in each MSS role and then scheduling RHPROFL0 to update T77UA. Do I need to build each MSS PD profile based on root object or does it work like a function module?
Thanks
Atta
SAP provides a standard function module to determine the start object for a manager profile. To the best of my knowledge, you would have to build the PD profile yourself as I don’t believe SAP doesn’t provide any profile to work out of the box. For automating assignment, you can assign the PD profile to each manager’s profile and run RHPROFL0 as you have been doing.
Thanks,
Aninda
Hi Aninda,
Currently we are using standard role based security for HCM system(SAP ECC 6.), and client wants to go for Structural authorisation.
Current set up is like below.
Authorization object is – P_ORGIN
and Authorisation switch Values(OOAC) are like below
AUTSW ADAYS 15 HR: Tolerance Time for Authorization Check
AUTSW APPRO 0 HR: Test Procedures
AUTSW DFCON 1 HR: Default Position (Context)
AUTSW INCON 0 HR: Master Data (Context)
AUTSW NNCON 0 HR:Customer-Specific Authorization Check (Context)
AUTSW NNNNN 0 HR: Customer-Specific Authorization Check
AUTSW ORGIN 1 HR: Master Data
AUTSW ORGPD 0 HR: Structural Authorization Check
AUTSW ORGXX 0 HR: Master Data – Extended Check
AUTSW PERNR 0 HR: Master Data – Personnel Number Check
AUTSW XXCON 0 HR: Master Data – Enhanced Check (Context)
I need some help/Guidance on below.
1 We have employees with default positions 9* and do not have any organizational assignment(in IT0001), what switch should I enable and what should be the value(I have gone through the documentation alreadyt, but I need recommendation).in order to get the report on these employees
2 We have Employees with Positions starting 8* and 7* and do not have any organizational assignment(in IT0001), as these employees are not assigned with SAP default positions, how do I handle this in order to get the report on these employees. Is any body having similar situtation and what are the best practices are followed (Like usage of BADIs and Function Modules etc).
3. can authorisation switches DFCON and ORGPD can be enabled at the same time?
4. Whether DFCON will work along with P_ORGIN, because I did some testing but seems to be not working.
Responses will be highly appreciated and correct recommendations will be rewareded.
Thanks alot in advacne.
Regards,
R K
1. For plain structural auths, you use ORGPD. For the context solution, you use DFCON in combination of with either of INCON, XXCON or NNCON. Whether you use the context solution is driven by requirements.
2. DFCON/ORGPD values are again driven by requirements and who should be able to see the people on default position. There is no general guidance as such.
3. Where in the Org Hierarchy do the employee positions starting with 8* and 9* fall in. The structural authorization concept first evaluates the org structure and only evaluates the Org Unit in IT 0001 for non integrated positions, i.e. positions which are not part of the standard OM structure.
BTW, I am wondering how correct recommendations will be rewarded 🙂
Hi Aninda,
I was trying to reset ORGPD=0 as we are using non integrated default position. But I am not able to make changes as it is saying “Do not make change (SAP Entry)”
Its just a warning. Ignore it 🙂
Hi Aninda,
We have DEFCON as 2, ORGPD as 3, INCON as 1 and PERNR as 1.
Str Profile ZHR_MANAGER
User is maped to OM Structure
Issue – When user tries to execute PFTC for one of the standard task, it does not show up anything and gives a message task does not exist.
However, if we remove, str profile from user id, then user is able to see same task. What could be the issue?
Please note – user have str profile mapped in T77UA. User does have access to P_ORGINCON with str profile. PFUD is run. I tried even changing ORGPD to 0. It still does not work.
Kind Regards,
Sheenam Singla
Hi,
I had got it resolved.
USer did not had access to “T” – Task in PD Profile. So entered record for that and it worked.
Hi Aninda,
Can you please suggest if there is any standard solution for accessing terminated employees in delimited Org Units?
We are using context authorizations, DFCON= 1. When employee is terminated, Org Unit value remains the same (e.g. 00000001). So when Org Unit is delimited, then it is not included in any PD profiles. As a result HR is not able to re-hire employees in delimited Org Units.
Earlier we had DFCON= 4, but it was allowing HR users to access also employees out of their area of responsibility, which was not acceptable.
Many thanks.
Tima
Hi Tima,
If a HR Administrator has access to an Org Unit, and I believe they still do after terminating the person, they shouldn’t be facing a authorization problem for re-hiring. This might be a configuration problem with the re-hire action rather than security but again I might not be getting the complete picture via your comment. Note that its the person’s record that gets delimited and not the org unit itself. If the org unit itself is delimited, it really is no longer a part of your org hierarchy and no one should be able to hire into it.
Also not a solution to your problem but configuration option that I have encountered in multiple installations is to put all terminated employees into a org unit specifically built for terminated employees. All HR administrators are set up with access to this org unit.
Thanks,
Aninda
Hello Aninda,
Thanks for response. HR Admins are not trying to hire employee into a delimited Org Unit (e.g. 00000001), but Re-hire them into a new valid Org Unit (00000002).
They run Re-hiring for employee who currently belongs to delimited Org Unit. The authorization check fails, because DFCON 1 evaluates Org unit (00000001) and rejects authorization (since delimited Org Unit from last IT0001 record of employee is not included in any HR user’s PD profiles). As a workaround we create a separate PD profile for delimited Org Unit 00000001 and assign it to user, so that he could run a re-entry for employees belonging to delimited Org Units.
But for some reason I think there should be a better approach to solve this.
Thanks again 🙂
Tima
How to download the topics?
At this point you will have to visit the website to read the posts
Hi Aninda,
I know this is a old topic but I was wondering if you can help me with this. I am a SAP HR guy and not a security guy FYI but I have not got much of a help from the security folks which is why I am researching this myself
My question is How do we limit access on the default position employees or employees without a Org unit? We have tried various combinations of the T77S0 switches without much luck. We either end up taking away all access or giving full access to these employees
Here is the issue:
ALL our users are able to see the following
Employees that were in default position (9999999) OR Employees that DONT have a Org Unit (0000000)
This is our T77S0 set up currently
AUTSW DFCON 3 HR: Default Position (Context)
AUTSW INCON 1 HR: Master Data (Context)
AUTSW NNCON 0 HR:Customer-Specific Authorization Check (Context)
AUTSW NNNNN 0 HR: Customer-Specific Authorization Check
AUTSW ORGIN 0 HR: Master Data
AUTSW ORGPD 1 HR: Structural Authorization Check
AUTSW ORGXX 0 HR: Master Data – Extended Check
AUTSW PERNR 1 HR: Master Data – Personnel Number Check
Here is P_ORGINCON on one of our display roles
HR: Master Data with Context
Authorization level M, R
Infotype 0000-9999
Personnel Area US01
Employee Group *
Employee Subgroup *
Authorization Profile ALL
Subtype *
Organizational Key *
And here is how our ALL profile is set up
Auth.profile Sequence number Plan Version Object Type Object ID Evaluation Path Status vec. Display depth Sign Maintenance Period Function module
ALL 000 ** * 00000000 0 X
This is controlled by the different values of the DFCON and ORGPD switches. This post talks about all the different behaviors that can be achieved. Please read through them to understand what each of the values do. However, for people on the default position without an org unit in PA0001, you can only either give access or deny access through the standard security. If you need finer control, one option might be to move different groups of people into different orgs in PA0001. Also, I would suggest changing ORGPD to 0 as you seem to be using the context solution. For context solution, DFCON switch is sufficient to control access to people on default position.