Reply from SAPAUSSEC on Aug 25 at 3:14 AM Agree
Is this proposing developers administer security and define access
| | | ---------------Original Message---------------
From: Sachin Nawale
Sent: Sunday, August 24, 2014 8:02 AM
Subject: Tables USOBT_C & USOBX_C
Hi,
The SAP standard Tables USOBT & USOBX are filled initially by SAP Developer
at the SAP installation.
SAP Developer has run the trace to identify what authorizations (Objects,
Fields & Values) are necessary to run a transaction.
These are always linked with the transactions in SU22.
Tables USOBT & USOBX are filled based on SU22 at the start of SAP
installation.
Table USOBT contains the list of transactions along with authorization
objects with Check Indicator "Check" & Proposal Status "Yes"/"Yes without
Values".
Table USOBX contains the list of transactions along with those
authorizations objects from USOBT & in front of it the values maintained
under SU22 will be appearing.
SU22, USOBT & USOBX are SAP standard.
SU24, USOBT_C & USOBX_C are customer Tables.
Customer Tables are filled with SAP standard tables at the start of SAP
installation.
Later as per the need, we could change the check indicator/proposal status
of transactions for authorizations in SU24 which directly after saving
reflects inn USOBT_C & USOBX_C.
During an SAP version upgrade or EHP Upgrade, though we have to run SU25
steps to complete Security upgrade.
*Step 2A:- *
Compares tables SU22, USOBT & USOBX with SU24, USOBT_C &
USOBX_C & fills the customer Tables for any SAP Check indicator/Proposal
status as per version/EHP release.
The t-codes that were not changed by Customer SAP
Security Consultant for check indicator/proposal status in SU34 during
support are compared & customer tables SU24, USOBT_C & USOBX_C are filled
with SAP proposal status for the release or EHP we are upgrading to.
The t-codes changed by Customer SAP Security Consultant
for Check indicators/proposal status during SAP support are compared for
new SAP proposals for the version or EHP we are upgrading to but SAP
doesn't fill customer tables SU24, USOBT_C & USOBX_C customer tables with
SAP proposals for upgrade.
Customer SAP Security consultant himself need to take
care of such t-codes build in SU24.
*Step 2B:-*
This step displays the list of transactions
needed to be maintained by Customer SAP Security Consultants inn SU24b for
Check Indicators and/or Proposal Status.
The Customer SAP Security Consultant has to maintain
Check indicator/Proposal status for the t-codes not filled in customer
tables Su24, USOBT_C & USOBX_C during 2A comparisons as explained earlier
above.
The reason is that these-codes were changed for Check
indicator/Proposal status in SU24 in earlier SAP release by Customer SAP
Security Consultant to meet the customer need while that t-code was not
working with SAP proposals in that release.
Complete this build & Save in a Workbench Transport.
*Step 2C:-*
This step displays the list of roles affected for new SAP
proposals for applications (transactions) in the Menu of the roles.
After 2B build, Run 2C step, which will display the list of
roles that need profile generation again because of new SAP proposals/check
indicators in t-codes in menu of role.
The authorizations with value for Check indicator = "CHECK"
& proposal status = "Yes" will be coming under the authorizations Tab under
PFCG of those profiles which contains the t-code in their MENU. These
authorizations will come as "STANDARD" with field values coming from SU24
for the fields which are already having SAP values coming from SU24 & for
the fields that come blank values, need maintenance as per customer need.
Authorizations won't be coming under Authorizations tab
of the profile under PFCG if the t-code is added in profile manually
through S_TCODE.
The authorizations with check indicator = "CHECK" &
proposal Status = "Yes without Values" would be coming under authorization
tab of the profile as "STANDARD" with the field values blank, SAP Security
consultant need to maintain these blank values as per customer need.
The authorizations with check indicator = "CHECK" &
proposal status = "No" won't be coming under the authorization tab of the
profile under PFCG but such authorizations are needed for background or
ABAP checks when the t-code is run. They are not needed to be under the
profile of user to make user able to run the t-code.
The authorizations with Check indicator = "DO NOT CHECK" are
never checked in the background during the run of that transaction.
*Step 2D:-*
This step displays the list of applications (transactions)
that are replaced by the applications (transactions) in new SAP version/
EHP version.
It doesn't mean that the replaced t-code couldn't be used, it
could be used in new release too but the advanced features won't be
available.
Therefore the replacing t-codes could be of better experience.
*3A. Transport Customer Tables:-*
This step is run to transport the Customer Tables SU24, USOBT_C &
USOBX_C & couple of more to higher customer landscapes.
The customer tables are filled after 2A & 2B steps build id complete with
the values proposed by SAP for new SAP versions in the SAP box where we
have run SU25 steps (Mostly Development we call), we should *never* run the
SU25 steps in Upgraded Pre-production, Production boxes
Rather we would transport two things:-
1.
Customer Tables using this step that were filled after 2A & 2B steps
build is complete through a Workbench Transport.
2.
Profiles that are generated through step 2C build through a customizing
Transport
Thus the upgraded Pre-Production & Production boxes are up-to-date with new
SAP version/EHP package, Customer Tables with new SAP proposals, Profiles
that are generated for new SAP proposals.
JJ
Regards,
Sachin |
| Reply to this email to post your response. __.____._ |   _.____.__ |
