User type reference not always taken into account
We are all aware that different type of user types exists in the SAP system (http://help.sap.com/saphelp_nw04/helpdata/en/3d/3272396ace5534e10000000a11405a/content.htm).
I find the use of reference users a bit “tricky” and my experience is that this user type is not always investigated properly during an authorization analysis.
What are reference users:
Reference user type ‘L’
Authorization enhancement
No logon possible.
Reference users are used for authorization assignment to other users.
Usage: Internet users with identical authorizations
Using reference users has it benefits, if a user is assigned to a reference user, it inherits the authorizations from this reference user. This can be helpful with Employee Self Service users for example.
However, the link to the reference user isnot always in your SAP report (via SUIM or table agr_users).
There are some reports in SUIM that will give you the link between a user ID and the reference user (like users by complex selection criteria (S_BCE_68001400)
Please be aware that not all SUIM reports will make the link to the reference user
Also bare in mind that the table AGR_USERS will not show the user with the authorizations from a reference user will (therefore you won’t see what roles are assigned to the user via this reference user).
How to search for the usage of reference users (this action can be part of your periodic authorization review)
1. Check if reference users are existing in your system (like SE16->URS02 usertpe L)
2. If they do exist.
2a.Check the assignment of authorizations to this reference user
2b.Check the assignment of users to this reference users (via S_BCE_68001400)
I have found two valuable uses for reference users and both rely on your User Administrations to adhere to security design and administration procedures
Non-Production - Reference users as the bulk access for Group (Security, Basis, Development, Configuration, Business End User)
Production: Single default permission role for common access all users receive. This is helpful to reduce overhead when PFUD executes in writing change documents to each user if there are changes to the role such as new profile generated.
You are correct when you run SUIM reports you need to take care that Reference user is considered as it looks for the USREFUS table to get the connection. If I'm investigating a single user, SU56 will show if they have inherited authorisations from the reference user.
With assigning reference user you can look at PRGN_CUST parameter so only defined reference users are assigned:
Regards
Colleen
IMO the mechanism and reporting is fine, it is just the default options which are not always ideal and if you have the habit (or tools) which download SAP tables and then misinterpret single fields of them or the data model is changed and they become obsolete, then you don't have to be surprised if you get incorrect results as the reporting logic is outside of SAP.
Another classic example is downloading USR02 instead of using report RSUSR200. Extremely error prone anaylsis method as the download does not consider system parameters and some other "salted" things which only the SAP kernel knows about within the system.
There are many very nifty uses for the reference user case, not only limited to performance improvements and central changes to common functions. For example, I use it in an application which forces testers to select a reference user to be able to execute test scripts. The ref user has the role which needs to be tested as well. This means that users test while only the role to be tested is assigned at the same time and you can react to or simulate what would have gone wrong if the user only had that role -> roles need to be able to survive on their own as well.
Downsides are that you only have one you can assign at a single point in time and it attracts misuse by naughty developers as it is a fairly simple table to make a direct hit against the DB or the buffer. One line of code is enough, which makes it an attractive vector but on the other hand one line of rogue code can do plenty of other havoc as well if you let it in - delete the DB, reformat the OS, etc...
But back in 46C there were a few "backdoors" from the initial implementation (no change docs, SAP* does not exist, etc).
Cheers,
Julius
Thanks for your feedback Julius and Coleen!
just an addition to
"Extremely error prone anaylsis method as the download does not consider system parameters and some other "salted" things which only the SAP kernel knows about within the system."
I totally agree USR02 does not take the system parameters and such into account, but I would recommend to go to the system parameter settingitself to get the complete overview instead of only looking at the ones in RSUSR2002. Off course, the ones in the RSUSR200 report are a good start, but these are not all the relevant ones for the security setting.
Cheers, Meta
Hi Julius
Interesting idea for reference user and testing. I'm probably missing the obvious here but I'll ask the question anyway.....How do you "force" the tester to use it - do you have a custom application you use for testing security?
Regards
Colleen
Yep, we created our own testing and substitution management app for it.
User must switch between the reference users to be able to perform the test scripts. This also switches the role being tested and removes the previous one automatically so that at the end you can say that the roles have been tested and not just the test scripts....
Anything that goes wrong is automatically corrected so that testing is nodeless and uninterupted from the perspective of the user.
From the perspective of the security admin, a "to do" worklist is the result at the end of the tests.
Works like a charm, thanks to the reference user concept... 🙂
Cheers,
Julius
I assume the testing user's account (without reference) has minimal rights, so that if an auth-check is passed, it's due to the role being tested, not the user's own roles?
Exactly. Only a common role for end users and one which stsrts the requests and workflows for the test scripts (which pulls in the correct role via the reference user and documents what failed (or would have failed if you simulate whether the role is fully functional on it's own).
Very simple. Very powerful 🙂
Very clever.
Thanks - sounds like a less-complex approach to obtaining security build requirements and appropriate testing of security permissions without granting too much access.
Sounds like a very good use for the reference user concept Julius!
Hi
Has anyone made indirect assignment of Analysis authorization through a reference user. I tried this concept but the user did not get access to analysis authorization and still had missing access to analysis auth
Regards
Nipun
Hi Nipun,
I tried it and it worked for me.
Regards,
Dinesh
Perhaps you assigned the AA's directly to the reference user in RSECADMIN and not via a role using S_RS_AUTH?
Yes,I assigned the analysis auth manually in RSU01 for reference id.
Cost center hierarchy is extracted from ECC to BI via a extraction process , which gets converted to analysis authorization in BI, so i need to test if AA (assigned manually/generated automatically) gets indirectly assigned through a ref user or not and not via role
That won't work. The reference user concept is built for checks based on the AUTHORITY-CHECK statement and looks in authorization objects for the values. Directly assigned Analysis Authorizations don't user the AUTHORITY-CHECK statement.
Cheers,
Julius
Hi guys,
Is the reference user considered during SOD analysis?
Thank you,
Gustavo
Hi Gustavo,
Yes absolutely. <Remove Advertising>.
Roles, composite roles, single roles, profiles, composite profiles, users, reference users.... all is taken into account.
<edit by moderator>