Q.

SAP Security T-codes

Frequently used security T-codes
SU01 - Create/ Change User SU01 Create/ Change User
PFCG - Maintain Roles
SU10 - Mass Changes
SU01D - Dislay User
SU!M - Reorts
ST01 - Trace
SU"# - $uthori%ation analysis

Q How to create users?
&'ecute transaction SU01 and (ill in all the (ield) *hen creating a ne+ user, you -ust enter an
initial ass+ord (or that user on the .ogon data ta/) $ll other data is otional)
Q What is the difference between USOBX! and USOBT!?
The ta/le US0123C de(ines +hich authori%ation chec4s are to /e er(or-ed +ithin a
transaction and +hich not 5desite authority- chec4 co--and rogra--ed 6) This ta/le also
deter-ines +hich authori%ation chec4s are -aintained in the Pro(ile Generator)
The ta/le US01T3C de(ines (or each transaction and (or each authori%ation o/7ect +hich
de(ault 8alues an authori%ation created (ro- the authori%ation o/7ect should ha8e in the Pro(ile
Generator)
Q What authori"ation are re#uired to create and $aintain user $aster records?
The (ollo+ing authori%ation o/7ects are required to create and -aintain user -aster records9
S3US&R3GRP9 User Master Maintenance9 $ssign user grous
S3US&R3PR09 User Master Maintenance9 $ssign authori%ation ro(ile
S3US&R3$UT9 User Master Maintenance9 Create and -aintain authori%ations
Q %ist &'( User Ty)es
Dialog users are used (or indi8idual user) Chec4 (or e'ired/initial ass+ords) Possi/le to
change your o+n ass+ord) Chec4 (or -ultile dialog logon
$ Ser8ice user - 0nly user ad-inistrators can change the ass+ord) :o chec4 (or e'ired/initial
ass+ords) Multile logon er-itted
Syste- users are not caa/le o( interaction and are used to er(or- certain syste- acti8ities,
such as /ac4ground rocessing, $.&, *or4(lo+, and so on)
$ Re(erence user is, li4e a Syste- user, a general, non-ersonally related, user) $dditional
authori%ations can /e assigned +ithin the syste- using a re(erence user) $ re(erence user (or
additional rights can /e assigned (or e8ery user in the Roles ta/)
Q What is a deri*ed ro+e?
Deri8ed roles re(er to roles that already e'ist) The deri8ed roles inherit the -enu structure and
the (unctions included 5transactions, reorts, *e/ lin4s, and so on6 (ro- the role re(erenced) $
role can only inherit -enus and (unctions i( no transaction codes ha8e /een assigned to it /e(ore)
The higher-le8el role asses on its authori%ations to the deri8ed role as de(ault 8alues +hich can
/e changed a(ter+ards)
0rgani%ational le8el de(initions are not assed on) They -ust /e created ane+ in the inheriting
role) User assign-ents are not assed on either)
Deri8ed roles are an elegant +ay o( -aintaining roles that do not di((er in their (unctionality
5identical -enus and identical
transactions6 /ut ha8e di((erent characteristics +ith regard to the organi%ational le8el) Follo+ this
lin4 (or -ore in(o
Q What is a co$)osite ro+e?
$ co-osite role is a container +hich can collect se8eral di((erent roles) For reasons o( clarity, it
does not -a4e sense and is
there(ore not allo+ed to add co-osite roles to co-osite roles) Co-osite roles are also called
roles)
Co-osite roles do not contain authori%ation data) !( you +ant to change the authori%ations 5that
are reresented /y a co-osite role6, you -ust -aintain the data (or each role o( the co-osite
role)
Creating co-osite roles -a4es sense i( so-e o( your e-loyees need authori%ations (ro-
se8eral roles) !nstead o( adding each user searately to each role required, you can set u a
co-osite role and assign the users to that grou)
The users assigned to a co-osite role are auto-atically assigned to the corresonding
5ele-entary6 roles during co-arison)
Q What does user co$)are do?
!( you are also using the role to generate authori%ation ro(iles, then you should note that the
generated ro(ile is not entered in the user -aster record until the user -aster records ha8e /een
co-ared) ;ou can auto-ate this /y scheduling reort
PFCG3T!M&3D&P&:D&:C; on a daily)
What is ,-.!-, in authori"ation /rou)s
Access to specific tables and reports can be restricted using authorization groups. For
example, if we consider that user 'JOHN' has access browse table using transaction !"#
but as user administrator, $ou want to restrict the access to onl$ "% specific tables. &n A',
these "% tables can be assigned to one authorization group (let's sa$ the authorization
group 'A)*+',. -hen $ou create the role to be assigned to JOHN, $ou assign .alue 'A)*+' in
the authorization group field for authorization ob/ects 01A)20+& and 01A)20*3&. 1his
will ensure that JOHN can browse onl$ these "% tables which belong to authorization group
'A)*+'.
1he same concept applies to reports as well. 1able 14+&4 stores the authorization groups
for all tables while table 1++A1 stores the authorization groups for all reports in A'.
5ou ma$ notice that some tables ha.e no authorization groups 6 which basicall$ means that
an$ user with authorizations to browse tables can browse these tables. 1he user does not
need an$ authorization group in her profile to browse these tables.
5ou ma$ also notice that some tables ha.e an authorization group '7N*7'. '7N*7' is slightl$
better from ha.ing a )3AN8 authorization group since onl$ users with an$ authorization
groups in their profile can access these tables. o, it doesn't matter what authorization
group is specified in the user's profile 6 as long as there is an authorization group in the user
profile, the user can access tables assigned to authorization group '7N*7'.
0irefi/hter Strate/y
The Fire(ighter alication allo+s ersonnel to ta4e resonsi/ility (or tas4s outside their
nor-al 7o/ (unction) Fire(ighting is a ter- descri/ing the a/ility to er(or- tas4s in
e-ergency situations)
Fire(ighter ena/les users to er(or- duties not included in the roles or ro(iles assigned to
their user ids) Fire(ighter ro8ides this e'tended caa/ility to users +hile creating an
auditing layer to -onitor and record Fire(ighter usage)
Fire(ighter is an $1$P/ased and +e//ased alication that auto-ates all acti8ities
related to (ire(ighting, including de(ining o( Fire(ighter !Ds and Fire(ighters, assign-ent
o( Fire(ighter !D 0+ners and Controllers, and the logging o( all transactions e'ecuted
during (ire(ighting)
Fire(ighter ro8ides a solution (or syste-atic handling o( e-ergency situations and at the
sa-e ti-e -anaging the ris4 (or the secial access necessary to resol8e the issue) The
logging o( transactions during the rocess ro8ides the caa/ility to re8ie+ acti8ities
used during an e-ergency situation)
0irefi/hter &o+es'User
To access Fire(ighter user -ust /e assigned a Fire(ighter role)
Ad$inistrator
o Fire(ighter $d-inistrators ha8e co-lete access to the Fire(ighter rogra-)
$d-inistrators are the only Fire(ighter user that can create Fire(ighter !D
ass+ords)
Owner
o 0+ners can assign Fire(ighter !Ds to Fire(ighters < Controllers) *hen accessing
the Fire(ighter rogra- 0+ners only see Fire(ighter !Ds assigned to the- /y the
Fire(ighter $d-inistrator) 0+ners can not assign Fire(ighter !Ds to the-sel8es
in the (ire(ighters ta/le to er(or- (ire(ighting tas4s, another o+ner needs to
assign the-)
0irefi/hter
o Fire(ighters ha8e access to the Fire(ighter !Ds assigned to the- and can use the
Fire(ighter !Ds to er(or- any tas4s er-issi/le /y the Fire(ighter !D roles)
!ontro++ers
o Controllers are resonsi/le (or auditing the usage o( Fire(ighter !Ds /y 8ie+ing
the Fire(ighter .og reort and recei8ing e-ail noti(ication o( Fire(ighter !D
logins)