Question:
Hi,
I am trying to maintain tables using auth groups. I know that we can use S_TABU_DIS for maintaining client dependant tables and S_TABU_CLI is used in conjunction with S_TABU_DIS for client independant tables. However I have following doubts.
1)Is presence of MANDT (Client) column in the table, the only way to determine whether a table is client dependant or cross client. Does the presence of this column in the table ensure that the table is cross client?Is there any other way of determining this?
2)I am thinking that TDDAT table is client dependant because we assign client dependant tables to auth groups in this table. Is TDDAT client dependant?
3)If TDDAT is client dependant then while maintianing cross client tables using auth groups, is there a possibility that I can assign the same cross client table to diffrent auth groups in different clients.
4) Whats difference between TPGP and TPGPT tables.
I am really confused and any help will be greatly appreciated.
Thanks
Kris
Answer:
If the table has MANDT as the first field in the table and the data Element is MANDT then the chances are it is client DEPENDENT so each client has different data.
THe TDDAT table is cleint INDEPENDANT . You assign auth groups to BOTH client dependent and client independant tables in TDDAT using SUCU or SE54 and there is only ONE valid authorization value for all clients.
TPGP and TPGPT tables are the authorization groups for REPORTS not tables and are loaded from the attributs of the programs seen in SE38 using a report the escape by memry at present. The TPGP is the auth group TPGPT is the text description
Answer:
Thankyou very much John. That really helped. I have been having this doubt for a long time.
When I was trying to change something in transaction SCC4 it warned me saying that "careful the table is cross client table", but when I pressed help key and saw the description I saw that the table that was being used is T000 and this table has MANDT column. Why does a client independent table has this column. Whats the most reliable way of determining whether a table is client dependant or independant. Can you throw some light into it.
Again why am i seeing different number of entries in TPGP and TPGPT tables. Can you suggest me some document where I can see detailed description of what tables correspond to what auth groups (i.e. programs, reports, tables etc.)
Answer:
T000 is THE client definition table and it is the only CLIENT Independent table with a MANDT field that is. all other table will warn you that it is independent when you maintain it.
Answer:
Hi,
Your conversation has been useful to me as i have had a confusion regarding the same issue.
You see, i have a client independant customer table with just two columns. The values in this table are entered by the end users and are used as search help in another infotype of HR. Now, our Basis team conducted an activity removing the authorization object TABU_CLI from all users as it was deemed a sensitive object. Now i have two alternates, either change the table definition and add MANDT field or give authorization to the end user at the tcode level for the relevant authorization group.
My questions are:
1. Will the user get authorization to maintain all tables to which this authorization group is assinged or only to the table being accessed via the tcode?
2.Is it ok to change the table definition in the production environment. Table obviously contains some data.
3. Is it a SAP recommended practice to give table maintenance access (only specified customer tables) to end users through parameter tcodes (calling SM30) or is it recommended to write a program that adds/deletes/changes table entries?
Would really appreciate your comments.
Thanks and reagrds,
Zubair
_________________
Thank you,
Regards,
Zubair
Answer:
Acces to S_TABU_CLI is not all the sensitive and ifi it is needed it should be given. If the user does NOT have the corresponding S_TABU_DIS to go with the S_TABU_CLI then S_TABU_CLI has no meaning. A wholesale removal of S_TABU_CLI and the refusal of givining it "because it is sensitive" is Wrong. If you need it you need it.
My questions are:
1. Will the user get authorization to maintain all tables to which this authorization group is assinged or only to the table being accessed via the tcode? THe user will need S_TABU_DIS of the table tied to a tcode but technically they have access to ALL tables in that auth group. There are several ways to get to these tables and you do not need SM30 ot a tcode tied to the table. SO assign a unique auth group to the table in SUCU and then that will help limit table access to other tables
2.Is it ok to change the table definition in the production environment. Table obviously contains some data. SAP supplied tcode SUCU or SE54 to change table authorization groups, but the production system setting will require you to change it in development and transport.
3. Is it a SAP recommended practice to give table maintenance access (only specified customer tables) to end users through parameter tcodes (calling SM30) or is it recommended to write a program that adds/deletes/changes table entries? Yes...
It matters not how you design maintenance, SM30 , custom application, in you case of a two column table SM30 is appropriate if you do not need a huge amount of validation.
Answer:
Hi John thankyou once agian for your valuable information. I got follow up questions for you.
In SE54 when we create an auth group the table view thats shown is from tables TBRG and TBRGT (These are client dependant tables).
Its weird that TDDAT table where we see the association of tables with auth groups being client independant. how does one make sure that there is consistency while assigning tables to auth groups.
This is the scenario that happened.
1) When I created auth group named LERA in client 170 and i was prompted to transport it, i didnt.
2) I logged into client 100 and ran SUCU transaction but i coudnt find the auth group LERA (obviously because i didnt transport the table from client 170)
Would you think it could have made more sense if SAP made TBRT & TBRGT tables client independant. Are there any specific reasons for this kind of design
Answer:
it's only really a problem if you want to see the groups in a picklist. As BRGRU is a free form 4 char field I don't think SAP were too worried about it.
You can maintain consistency by having a naming convention you adhere to. If it is important you are likely to have it documented anyway.
Answer:
Working as designed.
SAP allows you to create roles in any client and therefore the auth groups you use may be specific for those client. In practice though all roles should be centrally maintianed in ONE source client so there is never a need to "look elsewhere" for the "correct values"
Futher if SAP asks you to transport, chances are you should. The transport paths should include "into all clients or specified ones" in the source system to ensure coonsistency. I beleive ther is also a "transport" option in SCC4 (sp? it may be 2 or 1 or 3 or something) that allows you to "import" the values into a client using your transport as a copy source. The transpor tis not actually released or imported but used a s table entry copy source.
Answer:
Or SCC1
Answer:
The table TBRG and TBRGT are maintained seperately in each client, so that you do indeed have to make sure your group assignment is in that client, as it will not go there automatically without settings such as John mentioned. The reason this is so confusing is the way TDDAT and TBRG are used together. Your documentation on explaining this concept will be as hard to find as the documentation on why the user master comparison does not work as expected. One old note on the Client dependency of TDDAT might be the kind of thing you are looking for.
Try reading SAP NOTE 6938.
If anyone else knows of others like this one, let us know.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
Hi Gary,
Try reading SAP NOTE 6938.
I got between 0 and 231 hits on TDDAT and other terms related to this, but "note 6938 is not released".
Is there a typo?
Thanx,
Tarr
Answer:
Not sure why it is missing, try leading zeros maybe. Here is a copy I kept just in case I could not find it on SAP's site again. Good thing I did I guess.
SAP Note No. 6938 22.04.2004 Page 1
________________________________________________________________________
Number 6938
Version 4 from 02.01.1997
Status Released for Customer
Set on 01.01.1997
Language EN
Master language DE
Short text Table authorization client-independent ?
Responsible SAP AG
Component BC-SEC-USR-ADM
Users and Authorization administration
________________________________________________________________________
Long text
Symptom
Query: The table authorizations stored in TDDAT are client-independent.
How can one achieve an independent authorization assignment in the
different clients?
Additional key words
Cause and prerequisites
Conflict: what can/must be client-independent and what clientspecific?
Solution
The authorization classes for tables in TDDAT are understood as tables
from the data model perspective, and therefore from a fully client-
independent view. This is meant to simplify authorization assignment for
table authorizations, since relatively few classes correspond to over
5000 individual tables.
If we had not opted for this approach employing table authorization
groups, it would have been necessary to list all the tables (approx.
5000) explicitly in the authorizations of the authorization profiles.
This would have represented an unacceptable workload for the
authorization administrator. In this case, identifiers for
client-independent objects, i.e. tables, would still have been contained
in the client-specific authorizations (authorization object S_TABU_DIS).
Therefore, we solved this problem by setting up a group concept which
facilitates the procedure for assigning authorizations: the table
authorizations are maintained in table TBRG (with text table TBRGT). The
authorization groups are defined separately for each client. This
ensures that they are consistent with the authorization system, which is
also client-specific. It is easier to establish and analyze missing
assignments for new tables or new authorization groups by analyzing
tables TBRG and TDDAT than it would be with the other procedure by
analyzing the S_TABU_DIS authorizations in the authorization profiles.
Source code corrections
________________________________________________________________________
Page 2
Valid releases
Software Component Release
from to
SAP_APPL SAP Application
300 - 30F
22A - 22J X
________________________________________________________________________
Note attributes
00121A R3STD 0006938
old release 00121B R3STD 0006938
00121C R3STD 0006938
old release 00121D R3STD 0006938
00121E R3STD 0006938
old release 00121F R3STD 0006938
00121G R3STD 0006938
old release 00121H R3STD 0006938
00121I R3STD 0006938
old release 00121J R3STD 0006938
00121K R3STD 0006938
old release 00121L R3STD 0006938
00121M R3STD 0006938
old release 00121N R3STD 0006938
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
Thanks Gary!
To be sure I understand this confusing topic which I seem to have misunderstood: TBRG is client dependent as are the authorizations of the users, but the user can access the client independent tables for which they have S_TABU_DIS authorization group access as per TBRG groups for the client they are logged onto? Alternately, if there is no entry in TBRG of another client for a self-developed table - no access is conventionally possible?
I believe there is an ASUG meeting next week... it wouldn't suprize me if an "Informatix Complexity Racoon" arrived unannounced and demonstrated with "Keep it Simple" banners at the meeting.
Tarr