1. SU24 Workshop Maintaining Assignment of Authorization Objects to Transactions Steve Quinn Black & Decker Session Code: 807 as of: May 21, 2003

2. 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

3. 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)

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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”

12. 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

13. 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) USE THIS

14. Slide 14 Walk thru: new role for VA02 add VA02 NOTE: LIGHTS, STANDARD STATUSES, HIERARCHY Light Hierarchy: Red overrides … Yellow overrides… Green 1 Red = top Red

15. Slide 15 VA02 role: Org Levels filled in No red lights All still Standard

16. Slide 16 VA02 role: focus on SD objs

17. Slide 17 VA02 role: fill in open field Yellow goes Green up tree new status; trumps old next to go

18. Slide 18 VA02 role: change existing field (remove archiving access) all gone new status; trumps old (again)

19. Slide 19 VA02 role: add object Manually add with either

20. Slide 20 VA02 role: add object Manually (cont.) new status; trumps old (yet again) Filling in has no affect

21. 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?)

22. 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

23. Slide 23 Biggest Benefit? Removal (VA02) Start from last (this>) Go to Menu Remove VA02 (only tcode) Return yields … THIS! NOT EMPTY!

24. 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

25. Slide 25 Related Tcodes: Nice & Neat? RESULT: note statuses archiving removed field maintained custom object/auth added manually

26. 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

27. Slide 27 Related Tcodes: a neater solution? Same action (remove VA01/02) : but from an SU24-based role

28. 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

29. Slide 29 How I Did It: SU24 Check/maintain (CM) causes these objects to appear w/ VA02 in PFCG

30. Slide 30 SU24: Change Default Field Values (do same for VA01) CM setting allows default field value editing fields default vals into PFCG blank org level variables removed archiving activities change!

31. 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”?)

32. Slide 32 SU24: Add Custom Object (VA02 only)

33. 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

34. Slide 34 SU24: Back to Field Values new object w/ CM comes in blank set value(s) if desired

35. Slide 35 Related tcodes: Complete Rebuild VA01-05 after using SU24: Archiving activities never offered Custom object included with default value next to go

36. Slide 36 Related tcodes: Clean-up Maintain open fields Deactivate others (empty activities here) ALL GREEN

37. 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)

38. 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

39. Slide 39 Overview Info (per object) no activities or doc types VA02: activities, no doc types It’s VA05’s fault!

40. 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)

41. Slide 41 Another view: SU24 Values List TIP: generic “import text” button … great for loading “a mess ‘o tcodes” (i.e., a lot)

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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

49. Slide 49 Credit Where Credit is Due … In addition to personal experience and experimenting, the following SAP Note was a valuable reference: 113290

50. 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?

51. 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?

52. 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.

53. 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.

54. 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/ 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 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).

55. 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).

56. Thank you for attending! Please remember to complete and return your evaluation form following this session. Session Code: 807 steve.quinn@bdk.com