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

steve.quinn@bdk.com