Structural Authorization failed

[Former Member]

Hi All,

Need your help on a case which I've been handling. I've been working as a SAP HCM Authorization consultant.

I was assigned with a case, in which a group of user's are not able to view Forms via a custom transaction, and FYI in our system Structural authorization is being implemented. When I was checking on one of the group members, I took SU53 screen shot for him, and it says 'Failed HR Structure Authorizations - with details like date, plan version, Object type as P,its object ID and Action as DISP'. But what is weird is that none of those team members are assigned with pd profiles in both the speed tables (T77UA & T77UU). What I couldn't understand is that without any pd profile assigned to them, why are they getting error as Structural Authorization failed. They are facing this issue since last week, so I checked for the change log of the users and I couldn't find anything. Also one of the team member who was also facing the issue, but now it is resolved for her alone, again there has been no change made to her role. I'd even checked the change log of all the roles which is assigned to them. Can anyone help me on this situation please ! Thanks a lot in advance

[Former Member]

Users that are not explicitly added to the t77UA receive the same treatment as the SAP* user. Table T77UU is for users whom structural authorization data should be permanently stored in SAP Memory.

So check the assigned profiles to user SAP* in T77UA. Standard this will be profile ALL.

[Former Member]

Hi Bruno,

Thanks for the reply ! I did checked SAP* user in T77UA and it is assigned with profile ALL.

[Former Member]

Hello,

If I understood correctly: a user with no structural profile assigned in T77UA is getting failed structural authorization checks while the entry SAP* ALL in T77UA is unmodified (checked the dates and exclusion flag?)

This would indicate that the system either finds a valid structural profile for the user or fails to throw the proper exception when not finding it.

Possible causes could be:

- Active implementation of BAdI HRBAS00_GET_PROFL (either finding and assigning another profile or not throwing the proper exception when none are found)

- Active implementation of BadI HRBAS00_STRUAUTH

- Old index data in table INDX (in case the user used to be in T77UU but the program to update the index table hasn't ran since he/she got removed)

I suggest you run program RHAUTH00 (tcode RE_RHAUTH00) for this user to have a look at what's in their structural authorization buffer and where it is coming from.

Kind regards,

Brent

[Former Member]

Hi Brent,

I had checked like you'd suggested and there are no active implementations for the BADi, also we had scheduled the report RHBAUS00 & RHBAUS02 four times a day, so even if there is any old data it should have been removed already, and I tried the program RHAUTH00 for the user and I could only ALL profile in the buffer for the user.

Is there anything else which possibly might cause this issue ?

[Former Member]

what is the message the user(s) receive when executing the Z-transaction?

are the assigned roles complete?

assignment of the user in OM?

have you run a trace?

...

[Former Member]

Hi Bruno,

The roles are assigned and is valid, and the users are not facing any error message but the data which should be visible in not available for them. Also I tried trace and in which I found return code 4 for object P_PERNR (no profile contained in user buffer).

[pmuschick]

I guess they are not trying to access their own records, don't they?

The error message in SU53 indicates that this is a structural auth. issue. Nevertheless ALL should contain the required objects. Did you check the listed objects of SU53 in the output of RHAUTH00? (leave the field profile empty!)

A next step for me would be to recap and double check T77UU / INDX. Did you run RHBAUS01?

[Former Member]

I agree with Peter. P_PERNR is not relevant for this case.

If you don't mind, would you be so kind as to provide screenshots of fhe following:

- The SU53 screenshot for that user (the structural authorizations part)

- Transaction HRAUTH - overview tab (that's probably 2 screenshots to show all the data)

- Transaction HRAUTH - User specific tab for that user (section "HR Authorization objects")

This should give all the required information.

Thanks & kind regards,

Brent

[Former Member]

Hi Peter,

Thanks ! I forgot to mention that RHBAUS01 was also scheduled to run four times a day, so it wont be a problem, and to check in RHAUTH00, meaning I have to check the object ID in SU53 ?

[Former Member]

Hi Brent,

Below is the SU53 screen shot, and unfortunately I don't have access to HRAUTH, so could you please let me know what are all the details you need in that, so that I can try providing you with that, and FYI : RHPROFL0, RHBAUS02, RHBAUS01 & RHBAUS00 has been scheduled and is running as well.

[Former Member]

Hello,

Without HRAUTH it'll be a great many more screenshots:

• Overview of all BaDI implementations of:
  • HRPAD00AUTH_CHECK
  • HRPAD00AUTH_TIME
  • HRBAS00_STRUAUTH
  • HRBAS00_RHBAUS00
  • HRBAS00_GET_PROFL
• Overview of all Authorization switch settings
• All entries in T77UA for that user
• All entries in T77UU for that user
• Output of report RHAUTH00 for that user
• All entries in table INDX for that user
• Status of last execution of jobs with ABAP step:

  • RHPROFL0

  • RHBAUS00

  • RHBAUS01

  • RHBAUS02

• All entries for structural profile ALL (I never tried changing it but I suppose it's possible)

On a side note, would the structural authorization failure be for the users own PERNR?

Thanks & kind regards,

Brent

[Former Member]

that is the only line in SU53 for the user?

As Brent suggested: for whom does the user wants to display the form? Itself? If so, check the object P_PERNR to make sure all infotypes required to display the form are Included.

[Former Member]

Hi Brent,

I managed to get the screen shots from HRAUTH

User specific

and I could see that the last executed date in not very recent, so I had manually ran those reports now. Even after that it is not getting updated in this also in user specific, when I ran for the user, I couldn't find any structural profile for the user. Also the user is not trying to see her own data, which is some one else's data which she was able to view before. Can you help on this !

[Former Member]

Hi Bruno,

The user is trying to view data of a different user, which she was able to view before. Also I don't think this has anything to do with standard authorization (roles & objects) as when I tested the same in lower environments with a test user id with same roles which the user has, there is no issue.

[Former Member]

can you explain value 9 for switch DFCON? If I'm not mistaken only values from 1 to 4 are possible.

Evaluate org. unit/reject authorization per default:              1

Evaluate org. unit/allow authorization per default:               3

Never evaluate org. unit/reject authorization per default:     2

Never evaluate org. unit/allow authorization per default:      4

[pmuschick]

Just some questions:

• why did you disable P_ORGIN? (just for clarification) if the custom transaction was build before the switch off of P_ORGIN there may be custom coded authority check for this object but you may have switch to structural P_ORGINCON auth. after.
• Did you test to assign the user ALL directly and not through SAP* in T77UA?

[former_member74904]

are there any values in the PROFL fields in the respective P_ORGINCON objects of the assigned roles or are they all "*" for the group members?

[Former Member]

Hi Van,

It was the first thing I checked, but couldn't find any profiles added to any of the roles assigned to them

[former_member74904]

I'd also be interested in knowing why the value for the DFCON switch is set to "9".

can you let me know the position of the person the group member is tryijng to access?  is it not the default position?

[Former Member]

Hi Van,

The position of the person which the user is trying to access is not a default position, also I'm not sure why this was set to '9'. It was set as so a long time back, and ideally it should be 1 or 2 or 3 or 4. I'm not sure what would be the impact when it is set to '9' but I guess that is not the problem here because it was set as '9' a long time before and these group of users are facing this problem only since last week.

[pmuschick]

0 is also a possible value for this. As far as I remember this is the same as 1 with the difference, that you can access per.nr. which have never been integrated IF your P_ORGIN/XX/CON.PROFL value is *.

if the users are facing this issue since a few weeks and no change in authorizations have been done - then maybe this is a master data issue? have you checked the pernr they are trying to access. I think this might reach a point where we would need more details on the actual testing including data and auth roles.

[Former Member]

or error due to recent changes to the form?