View
224
Download
2
Tags:
Embed Size (px)
Citation preview
SU24 WorkshopMaintaining Assignment of Authorization Objects to Transactions
Steve QuinnBlack & Decker
Session Code: 807
as of: May 21, 2003
Slide 2
POST-CONFERENCE NOTE:
This PowerPoint has been updated with notes from the discussion that followed this presentation.
(please see the last 5 slides before the final slide)
Thanks to Gretchen Lindquist of Halliburton for taking notes during the discussion. This allowed me to add these 5 slides of additional, useful information.
Thanks to everyone for attending and especially to those who offered feedback. Take care!
-- Steve
Slide 3
Format
• Primary Goal: Education through Audience Participation (users-helping-users, heart of ASUG)
• Shortened presentation– gives us common foundation for discussion– limited answers to questions along the way
(for sake of discussion time)
• Large Group discussion– LOTS of questions & group discussion (up to you)
• Discussion Notes to be taken & included in final version of presentation (to be posted)
Slide 4
Expectations (based on abstract)
• Beginners (some PFCG experience): exposure & advice– Lots of info at fast pace– Don’t try to absorb everything, just follow the
flow and get a sense of it (read in-depth later)
– Presentation should prep you for discussion
• Advanced: discover new tips– Presentation: you’ll know this (gain a few tips?)– Discussion: most to contribute, your best gain
• Intermediate: blend of above– likely learn much from presentation & discussion
Slide 5
Reference
• Based on: – R/3 security in v4.6C
(tested on Support Pack 41)
• Terminology:– roles = activity groups (true starting in 4.6C)
– auth = authorization (an auth object w/ settings)
– tcodes = transaction codes
Slide 6
Outline
• Poll Audience
• Intro SU24 / Why Use it?
• “Demo”/explain related PFCG areas (key)
• “Demo” multi-tcode scenario with & without SU24
• “Demo” SU24 use
• Wrap-up Presentation
• Start Discussion
Slide 7
What is SU24?
• a transaction (vs. a table, etc.)• used primarily to control (or just display) which
auth objects and field settings automatically enter the Role Authorizations area when any given transaction is added to the Menu area– or leave when a tcode is removed from the Menu
• can also be used to disable/enable authority checks
• the only place to create auth templates (4.6C)– v6.20 also allows templates from PFCG submenu
Slide 8
Who Uses It? Where?
• Who: Security Admins (role maintainers) only
• Where: – in R/3 systems (mostly)
• usable, but less so in less transaction-based systems (e.g., BW)
– DEV … will require a transport (workbench)• … assuming you transport security
– Why DEV? mostly affects PFCG only• mostly no “need” to transport … but …• … some actions can affect Production and
must be transported– e.g., enabling/disabling of auth checks
Slide 9
How It Works (brief background)
• SAP has default tables– USOBT, USOBX
• SU25 Step 1 (PFCG prep) populates custom tables (don’t repeat step w/o advanced knowledge)
– USOBT_C, USOBX_C
• Custom tables used to populate/depopulate Auths area for builds & standard changes – i.e., not used when using “Edit Old”
• If SU24 used, want SU24 settings (i.e. table data) preserved through upgrades, etc.– see SU25: out of scope here
Slide 10
My Path: Typical Steps to Avoiding SU24 … until now …
• Build role via Menu (initially), go to Auths– clean-up Auths the way you want it
• Make change via Menu, go back to Auths• Merge Chaos:
– yellow lights everywhere, deleted auths returned, changed auths re-asserted• “THIS IS NOT HOW I LEFT THIS!”
• Pull out hair (observe your presenter)
– vow never to do this again (as recommended to me)
• So from then on:– skip Menu, Edit Old, edit S_TCODE, Manual auths
Slide 11
Why Use SU24?
Can’t I live without it?Can’t I live without it? YES! But …– if PFCG used as interface for 100% manual
auths, all you get is:• prettier interface than SU02 (old profile maint.)
• auto-generate multiple profiles >150 auths• no use of other benefits contained in PFCG:
– have to manually find/add auth objs w/ tcode– have to manually remove auth objs w/ tcode– have little idea (over time) re: why certain
objects/auths are there
– if PFCG Menu used once and always “Edit Old”• get all above + Changed auths (discussed later)
• SAP standard editing = “Merge Chaos”
Slide 12
Why Use SU24? (cont.)
• Reasons FOR it (to become clearer later):
– Menu controls Authorizations “as intended”
– Lesser need for extra maint. in Auths area
– Tcode add/removes can be quicker & easier
– More reliable SUIM reports (sometimes)
– Allows use of SU25 features to help with upgrades
Slide 13
How to Use: Assumption …
• Almost always use Change mode– rarely Expert mode
• NOTE: Change mode auto-chooses maint type – OK, if PFCG/SU24 used “properly” (i.e., the SAP way)
USETHIS
Slide 14
Walk thru: new role for VA02
add VA02
NOTE: LIGHTS, STANDARD STATUSES, HIERARCHY
Light Hierarchy:
•Redoverrides …
•Yellowoverrides…
•Green
1 Red = top Red
Slide 15
VA02 role: Org Levels filled in
•No red lights
•All still Standard
Slide 16
VA02 role: focus on SD objs
Slide 17
VA02 role: fill in open field
Yellow goes
Greenup tree
new status;
trumps old
next to go
Slide 18
VA02 role: change existing field (remove archiving access)
all gone
new status;
trumps old(again)
Slide 19
VA02 role: add object Manually
add with either
Slide 20
VA02 role: add object Manually
(cont.)
new status;
trumps old(yet again)
Filling in has no affect
Slide 21
Obj. Maint. Statuses – The “Good”(in order of status “override power”)
• 1 - Standard– Recommended! Default for all default auths– Means: Authorization completely unchanged
• 2 - Maintained– Recommended!– Means: >=1 non-OrgLevel field originally empty
(yellow, not red) now filled in (green)
• TRIVIA NOTE: Can change back to Standard by clearing maintained fields.
IDEAL = ALL AUTHS HAVE THESE STATUSES (Utopia?)
Slide 22
Obj. Maint. Statuses – The “Bad”(in order of status “override power”)
• 3 - Changed– NOT recommended! (for SU24-type maintenance)
– Means: >=1 default value (originally green field) was changed OR >=1 OrgLevel field edited directly (not via Org Levels button)
– ALSO: Change status “permanent”. Once Changed, does NOT revert to previous status when reversed. Must redo auth by re-merging or re-creating auths.
• 4 - Manually– NOT recommended! (for SU24-type maintenance)
– Means: auth was added manually, not via tcode on Menu– no field editing alters this status
Slide 23
Biggest Benefit? Removal (VA02)
Start from last (this>)
•Go to Menu
•Remove VA02 (only tcode)
•Return yields …
THIS!
NOT EMPTY!
Slide 24
New Role of Related Tcodes: VA01/02/03/05 together
Initial auths, all from SU24
•Add custom object/auth
Want to …
•Remove archiving
•Delete auths w/ no Activities
Slide 25
Related Tcodes: Nice & Neat?
RESULT:
note statuses
archiving removed
field maintained
custom object/auth
added manually
Slide 26
READY FOR THIS?
Related Tcodes: remove VA01/02 from Menu and return
WHAT’S ALL THIS?
•01’s & 02’s still there!
•new objects!
•yellow lights!
(imagine doing lots of this!)
ACTION: remove VA01/02
from Menu
Slide 27
Related Tcodes: a neater solution?
Same action (remove
VA01/02): but from an SU24-based
role
Slide 28
PFCG IDEAL (when used w/ SU24)
• Add/Remove transactions in Roles ONLY from the Role Menu– never edit S_TCODE auth directly
• Adding tcodes: all required auth objects come prefilled with almost all correct settings for your business– very little extra for you to fill in
• Future tcode maintenance: very little auth editing– no merge chaos (“extra” yellow lights, etc.) after role
changes
• Removing tcodes: ALL and ONLY the necessary objects/field settings get removed– no painful sifting through or worrying about affecting
other related transactions
Slide 29
How I Did It: SU24
Check/maintain (CM) causes these objects to
appear w/ VA02 in PFCG
Slide 30
SU24: Change Default Field Values(do same for VA01)
CM setting allows default field value editing
fieldsdefault vals into PFCG
blank
org level variables
removed archiving activities
change!
Slide 31
SU24 Check Indicators
Per tcode, each object can have one of these:• CM = Check/maintain
– gets the object into PFCG Auths– allows field defaults to be set in SU24
• C = Check– preserves auth check but no PFCG or defaults
• N = No check– DISABLES AUTHORITY_CHECK CALLS to object– if you want this to work, you’ll need to transport
• U = Unmaintained– Mystery to me: no functional difference from
Check? (just indicating “not touched yet”?)
Slide 32
SU24: Add Custom Object(VA02 only)
Slide 33
SU24: Set Check/Maintain
New object added as Check:
won’t show in PFCG
click dot to change
Check/maintain:
now show in PFCG, can edit
default vals
Slide 34
SU24: Back to Field Values
new object w/
CM comes in
blank
set value(s) if desired
Slide 35
Related tcodes: Complete Rebuild
VA01-05 after using SU24:
•Archiving activities
never offered
•Custom object
included with default value
next to go
next to go
Slide 36
Related tcodes: Clean-up
Maintain open fields
Deactivate others (empty
activities here)
ALL GREEN
Slide 37
Related tcodes: Remove VA01/02
Remove VA01/02 after
SU24:
•No new unwanted
auths
•No yellow lights
•No VA01/02 settings
(+ custom object gone)
Slide 38
The Tcode-Auth Connection
Want to know which tcode brings
in an auth you don’t want?
Maybe considering SU24 to prevent it?
… use Overview button
Slide 39
Overview Info (per object)
no activities or doc types
VA02: activities,
no doc types
It’s VA05’s fault!
Slide 40
Caution with SU24: VA05 example
• Possible Solution: Use SU24 to remove V_VBAK_ATT from VA05 defaults– by changing “Check/maintain” to just “Check”
• This would stop unwanted auth and lingering “Inactiv” auth, BUT …
• … what happens when you want VA05 in a role without its “siblings”?
• You might prevent a required auth from being added to PFCG … causing problems
• SU24 changes can affect all roles w/ tcode– upon editing each role (can appear unintended)
Slide 41
Another view: SU24 Values List
TIP:generic “import text”
button … great for loading “a mess ‘o tcodes” (i.e., a lot)
Slide 42
Another view: SU24 Values List (cont.)
display all together
display/change 1 selected
tcode
good for printing & searching:
get all check
indicators and field
values all in one place
find all tcodes bringing this object
into PFCG
Slide 43
SU24 settings by object
“Other” SU24 Option:
•See all check indicators for 1 object
•Change many indicators & field values at once for 1 object
Slide 44
Change multiple tcodes
by:
•checking boxes
SU24 settings by object (cont.)
click dots to change object’s indicators for each tcode
Change multiple tcodes
by:
•checking boxes then…
•clicking these dots
Slide 45
SU24 settings by object (cont.)
All changed
to CM
… AND this button
appears (only upon setting CM)
… which lets you set same default field vals for all
tcodes selected
Slide 46
Other things I do …
• Document the “why” of my SU24 changes in an Access database …
– Allows me to compare old reasoning to new ideas …
– instead of accidentally undoing a forgotten intention
Slide 47
More Advice …
• SU24 can be used for custom tcodes– bring in custom objects & default settings
• “Changed” and “Manual” not always “bad”– Roles based on SAP_ALL/templates = Manual– Any role more auth-oriented than tcode-oriented– Any “exception” to your normal use of a tcode
• AVOID:– Trashing deactivated auths– Editing S_TCODE (use Menu instead): find edited
S_TCODEs w/ program PFCG_AGRS_WITH_MANUAL_S_TCODE
Slide 48
SU24 Summary:Customizing ahead of PFCG
• SU24 allows intended use of PFCG via Menu and less Authorization area maintenance– a “life saver” regarding tcode removals
• Strive for all Standard & Maintained auths
• SU24 changes can impact same tcode in all roles– be careful– think about tcode use & potential impact
Slide 49
Credit Where Credit is Due …
In addition to personal experience and experimenting, the following SAP Note was a valuable reference:
113290
Slide 50
Discussion Starters
• Questions about the presentation content?
• How will I convert from non-SU24 use?
• What about existing roles after an SU24 change?
• How should I handle “combined” transactions?– those without xx01/02/03 versions (e.g., MIGO)
• Disabled auths: leave vs. trash vs. fix in SU24
• Merging auths: effect on PFCG w/ SU24?
• How to manage many uses of same tcode in different roles with only 1 set of SU24 defaults?
Slide 51
Discussion Notes 1
• Change History (i.e., “Change Documents”) for SU24 can be found on an SU24 “top-bar” menu at the Check Indicator and Field Values screens inside SU24.– No action seems to be required for these SU24 changes to
be recorded.• When many roles have the same tcode and you don’t
want SU24 to make them the same everywhere (which would force Changed auths), make those variable fields blank in SU24 to allow any value in PFCG. This makes it flexible under any circumstances and prevents those Changed auths.
• When obtaining an SU53, always get the tcode the user was attempting. This allows you to edit SU24 as part of your solution, if desired.– Wouldn’t it be nice if SU53s had the “tcode attempted” built
in? Possible DRQ?
Slide 52
Discussion Notes 2
• You can convert any field to/from an Org Level via standard SAP tools, such as program PFCG_ORGFIELD_CREATE(?). SAP no longer recommends transaction SUPO.
• If SAP is currently NOT calling a given auth object for a tcode, updating Check Indicators (e.g., to Check or Check/Maintain) does NOT cause SAP to start checking that object.– Such calls are made from AUTHORITY CHECK statements in
the ABAP itself. This is the only way to get a new object checked. Only then can SU24 affect anything, via “No Check” to DISBALE this check, if desired.
• If running any program via tcodes, S_PROGRAM can be added to those tcodes with the correct Authorization Group pre-filled (in SU24).– As opposed to adding S_PROGRAM manually when you want
to grant the access but also avoid giving SA38/SE38.
Slide 53
Discussion Notes 3
• SU24 will reportedly PREVENT you from selecting “No Check” on all auth objects starting with “S” (Basis) and “P” (HR).
• Watch out! Support Packs can cause new objects to be included or existing objects to be newly checked from the ABAP. These will NOT appear in your customized SU24 by default, but will appear in the SAP Defaults option offered in SU24.– Running SU25 after Support Packs could help
catch these proactively, even though Support Packs are not usually considered an “upgrade” per se.
Slide 54
Discussion Notes 4
• If you have a role with an auth object with an Org Level (e.g., Plant), AND you want >1 auth (instance of the auth object) with DIFFERENT plant codes in each … (e.g., 03/* and 02/<plant> together) … what to do? What to put in the Org Levels? If to be kept together in one role, a Changed object with the Org Level field directly edited may be necessary. Recommend adding the <plant> to the Org Level screen (affecting all other Plant fields) and directly changing the “odd” or less frequently used field (and documenting it).– The given example could be handled with separate display
and update roles, but there are potentially other examples where the split is not between display and change, but something else (like change and delete, etc.).
• Copying an existing auth should preserve the link back to the same tcode (unless the auth is made Changed).
Slide 55
Discussion Notes 5
• When a tcode is removed from the Menu and Changed auths originally from that tcode are left over, the Overview button for those auths should produce nothing (i.e., no longer showing a connection to the original tcode).
Thank you for attending!Please remember to complete and return your evaluation form following this session.
Session Code: 807