User Group org unit

[Former Member]

Hi guys,

I have an issue with user group (S_USER_GRP) when I create role in my dev system with SU01 or any other security T-codes that brings authorization object S_USER_GRP but some reason it doesn't show up as an org unit in my organization list inside the role. However, it is working fine in QA environment.  I'm not sure what causes this issue in Dev.

I thought someone delete the org field (CLASS) from the configuration but I can' find any place in SPRO where this field has been configured because it is standard org unit, it is not like company code or plant.

My manager runs create org program  to create org fields as a new org level field as an org unit but this one is already there by standard because you assign different user groups to maintain user master record.

Please direct me to the right direction to look for any resolution for this issue. I also checked my Basis team to find out if there is any difference in SPs between DEV and QA but it is same.   I think something delete or changed in the system that's the reason the User group doesn't show up as an  org level. Since this is standard org unit, I can't create this one again through the org field program.

Any help will be appreciated. Thanks in advance

Regards,

Faisal

[former_member384109]

hi mukhtar,

Please Check table USVAR regarding  org level.

Regards,

Ankit Patel

[Colleen]

USGRP is not an org value by default.

It sounds like someone ran PFCG_ORG_FIELD_CREATE (or PROMOTE) via SE38 directly in QA system

Your options are to either promote it in DEV and then fix the roles and transport or to run the deletion version in QA to reset it back to an standard auth field and then transport your roles from DEV

Search for the program and you'll find heaps of information

Regards

Colleen

[Former Member]

Thanks for the response, I know my manager runs this program very often to bring some fields into the org level but I already tried to promote this field (CLASS) to org level in DEV but it gives me this error "CLASS is already exist as an org unit" and when I tried to delete it, it says you can't delete this org field because it is standard field.

Is there any other ideas I can try.

Regards,

Faisal

[Former Member]

Colleen,

I also checked my another instance and it shows up there as an org level, it makes more sense for SAP to have this as an org level because if you have more than 20 company code and each company has their own security administrator they will manage their users administration by user group, being the org level field you can mange this by one role 20 derived roles.You know what I mean.

Regards,

Faisal

[Former Member]

In a better world you would not have any org. levels, but rather application tools to cascade authorization values with a link to role variables. That is also what org. levels set out to do, but had the nasty consequence with derived roles and objects sharing the same field types that it sends them everywhere and you cannot have combined instances of authorizations such as display all but change only some within the same role. So you are forced to have more and smaller roles. Then you start using composite roles to put it together so that the customer can still make sense of thousands of roles and then you are lost (or you leave the project and it is the customer's problem).

CLASS was "accidentally" promoted to an org. level in the standard but it is not at all appropriate for an org. level. The GRC Add-on software packages did that by sending USORG values for it into systems but not adjusting roles and Su24 in the way it should be done. This is not delivered anymore by SAP and there is a SAP note and correction tools in Su25 to degrade it again and undo the damage done. Search for USORG and CLASS on OSS.

Your system appears to have inconsistencies in this customizing caused by importing the GRC client system side add-on packages, or someone maintained the USORG table directly.

You should undo this and keep it as a normal field.

Promoting a field to an org.level is only sensible if it is a real org. element from the SPRO perspective, which CLASS is not. BUKRS is for example. KOART in F_BKPF_KOA is also and a big pain in the *** because of it. Other fields with TYPE and GROUPS are tempting to promote, but resist the temptation! They are shared by multiple objects and have the consequence that you cannot have multiple authorization instances anymore. You quickly reach the limits of the UST12 field lengths and end up with thousands of roles instead of only 50. Even without promoting the fields you can still end up with thousands of roles if you do not maintain Su24 and want to build based on a design which only works in .ppt presentations.

The moment you have the temptation to use composite roles, alarm bells must go off that the underlying concept is not well thought out at single role level and org. fields are one of the main reasons for this. Another is silly project goals like roles must be completely SOD free based on all 4 million GRC rules, etc which have no relation to the customer scenario nor can they ever be implemented. They just make the roles kaput...

Cheers,

Julius

[Former Member]

See SAP Note 1739055 for the solution to this specific problem.

Cheers,

Julius

[Former Member]

Julius thanks for the details but as I'm thinking and researching more about this I found out that user group is promoted as an org unit in EHP 7 by SAP and We went live with SAP HANA plus with EHP 7 in April 2015 so I'm assuming that PFCG _ORGFIELD _CREATE program ran by my manager way before we upgrade to EHP 7 for user group what when SAP delivered this field as an org unit by standard I think it corrupted the system inn DEV because I know my manager never ran this program in any other environment that's way it is showing up in QA system but not in DEV.

Do you know this was promoted in EHP 7?

Regards,

Faisal

[Colleen]

Hi Faisal

if you want them to match it might be worth looking at the USVAR and USORG tables.  if you can't run the program it will be hard to fix this as the su24 and pfcg tables need to be corrected (usobt_C, usobx_C and agr_1251/agr_1252). You might be able to fix those tables via transports via su25 for su24 data and pfcg for impacted roles

are you wanting $CLASS to be an org value or not? This would determine how to approach it

if root cause is what Julius mentions (I notice his solutions are usually 99.0% on the mark) and the OSS note won't work then you might need to raise an incident with SAP for suggested solution

Regards

Colleen

[Colleen]

Hi Julius

KOART is such a strange one to have been made an org field. I haven't been to a client site where asterisks is not used as people can't lock it done properly and found it frustrating that you cannot demote it as it's standard.

I can understand why some people promote CLASS - if you have a user group that correlates to a company of site/plant then it can make sense. It's not like BEGRU (Auth group)

What confuses me is why SAP prevents you from changing standard delivered org values? IF the creation/deletion programs are meant to take care of SU24 and PFCG data and future support packs/notes consider customer setttings why is such a restriction required? Org values provided by SAP are inconsistent  HR module for example has very few. RESPAREA doesn't exist by standard yet KOSTL for cost centre is but PRCTR for profit centre isn't.

Cheers

Colleen

[Former Member]

Hello Collen,

Yes, I want user group to be a org unit because I have so many security admins who maintain users only for their user group each company/plant but I can't delete CLASS or create. I don't know what is the right approach?

Regards,

Faisal

[Former Member]

As I already mentioned, it was "accidentally" promoted by a GRC add-on transport which sent the record as table entries for USORG together with their packages. That is not allowed and the field is not appropriate as an org level. It is just a by-product of derived roles that one might not resist the temptation to promote everything to an org. level... 🙂

Your problem is that you are using derived roles, otherwise you could also simply maintain the field once in the role and it would be over.

BTW: If those decentral admins are only doing simple helpdesk tasks like resetting password and assigning roles after they have been approved, then you can also automate that via workflows and self-services. Then your problem is solved that way as well.

Cheers,

Julius

[Former Member]

Question on this:  Has anyone successfully demoted the account type field (KOART)?
We have a new SAP system and would like to do this from the start...

[Former Member]

There is no standard way to do it.

But if you look into the coding of how SAP undid the S_USER_GRP-CLASS field problem, you will see that it is just a "one liner" in one place as modification to get PFCG_ORGFIELD_DELETE to demote another field.

Not really a big thing at all but none the less a modification.

Cheers,

Julius

[Former Member]

Thanks Julius.  Your insights are as always appreciated.

I'll try to update this thread if we succeed.

[Former Member]

Feel free to also open a customer message with SAP and ask whether there could be some "switchable framework" instead of coding modifications which protect SAP fields from demotion.

I tried but was not successful.

Cheers,

Julius

[Former Member]

Hi Faisal,

It sounds like someone created the the ORG field in QA but not DEV or the PFCG ORG CREATE change got overwritten or as Julius pointed out GRC Add-On software is the culprit. 

Depending on your prefered resolution - Either,

1. Run PFCG_ORGFIELD_DELETE in QA on field CLASS

2. Run PFCG_ORGFIELD_CREATE in DEV on field CLASS

Both environments run PFCG_ORGFIELD_ROLES to synch.

Thanks,

Patrick