Does anyone have a list of transactions that would be considered adequate for a basis administrator on a production system, which would allow them to do all the work they may need to without logging in with a sap_all id?
What is the best practice for access for basis in production?
You may use the SAP delivered standard roles and create a copy of the same according to your convenience. The roles in the standard system like:
SAP_BASIS_ADMIN Admin role for basis people
SAP_BC_BASIS_ADMIN System Administrator
SAP_BC_AUTH_DATA_ADMIN Authorization Data Manager
SAP_BC_AUTH_PROFILE_ADMIN Authorization Profile Administrator
SAP_BC_BATCH_ADMIN Background Processing Administrator
SAP_BC_BDC_ADMIN Batch Input Administrator
and more can be used to suit your requirements.
I can understand where are you coming from :). You needed the list of all possible basis tcodes in production environment rather adopting strenuous task of deriving and identifying all required functionality from SAP Standard role template for basis. Not an issue
You can refer the tcodes listed below in production environment. It includes all required for regular support, monitoring & performance analysis.
SSO2 Workplace Single Sign-On Admin.
STRUSTSSO2 Trust Manager for Logon Ticket
BD82 Generate Partner Profiles
SMT2 Trusting systems (Display <->Maint.)
SPAU Display Modified DE Objects
SDCCN Service Data Control Center
SLG1 Application Log: Display Logs
SGEN SAP Load Generator
STMS_MONI TMS Import Monitor
STMS Transport Management System
SCOOL COOL Repository
PFUD User Master Data Reconciliation
SMMS Message Server Monitor
SICK Installation Check
SMICM ICM Monitor
SE38 ABAP Editor
AL04 Monitor call distribution
AL08 Users Logged On
AL11 Display SAP Directories
AL12 Display table buffer (Exp. session)
AL13 Display Shared Memory (Expert mode)
AL15 Customize SAPOSCOL destination
AL16 Local Alert Monitor for Operat.Syst.
BD21 Select change pointer
BD50 Activate Change Ptrs for Mess. Type
BD51 Maintain function modules (inbound)
BD52 Activ.change pointer per chng.doc.it
BD54 Maintaining Logical Systems
BD64 Maintenance of Distribution Model
BD97 Assign RFC dest. to Logical Systems
CK11 Create Product Cost Estimate
DB01 Analyze exclusive lockwaits
DB02 Tables and Indexes Monitor
DB03 Parameter changes in database
DB12 DBA Backup Logs
DB6BACKHIST DB6: DBA Planning Calendar
DB6CLP DB6: Command Line Processor
DB6COCKPIT DB6: DBA Cockpit
DB6EXL DB6: Analyze Exclusive Lock Waits
DB6PERF DB6: DB2 UDB Cockpit Performance
DB6SPACE DB6: Space Analysis
FTXP Maintain Tax Code
KOSRLIST_PR Projects/Nets: Coll. Displ.SettRules
LBWE LO Data Ext.: Customizing Cockpit
LSMW Legacy System Migration Workbench
OS01 LAN check with ping
OS03 O/S Parameter changes
OS04 Local System Configuration
OS05 Remote System Cconfiguration
OS06 Local Operating System Activity
OS07 Remote Operating System Activity
OSS1 Logon to SAPNet
OY05 Factory calendar
RBDMIDOC Variant for RBDMIDOC
RSA7 BW Delta Queue Monitor
RZ01 Job Scheduling Monitor
RZ03 Presentation, Control SAP Instances
RZ04 Maintain SAP Instances
RZ10 Maintain Profile Parameters
RZ11 Profile Parameter Maintenance
RZ12 Maintain RFC Server Group Assignment
RZ20 CCMS Monitoring
SA38 ABAP Reporting
SAINT Add-On Installation Tool
SALE Display ALE Customizing
SASAPIMG Call Up Project IMG
SBIW BIW in IMG for OLTP
SCON SAPconnect - Administration
SCOOLTOOL COOL Tools
SCOT SAPconnect - Administration
SCU0 Customizing Cross-System Viewer
SCU3 Table History
SE03 Transport Organizer Tools
SE06 Set Up Transport Organizer
SE12 ABAP/4 Dictionary Display
SE13 Maintain Technical Settings (Tables)
SE15 ABAP/4 Repository Information System
SE18 Business Add-Ins: Definitions
SE37 ABAP Function Modules
S_TABU_DIS Display Tables (customize it to ztcode)
SCC4 (customize it to ztcode)
SE63 Translation: Initial Screen
SE11 ABAP Dictionary
SE11_OLD ABAP/4 Dictionary Maintenance
SE80 Object Navigator
SE81 Application Hierarchy
SE82 Application Hierarchy
SE84 R/3 Repository Information System
SE93 Maintain Transaction Codes
SESSION_MANAGER Session Manager Menu Tree Display
SICF HTTP Service Hierarchy Maintenance
SM01 Lock Transactions
SM02 System Messages
SM04 User List
SM12 Display and Delete Locks
SM13 Administrate Update Records
SM14 Update Program Administration
SM20 Security Audit Log Assessment
SM21 Online System Log Analysis
SM28 Installation Check
SM35 Batch Input Monitoring
SM36 Schedule Background Job
SM37 Overview of job selection
SM37C Flexible version of job selection
SM38 Queue Maintenance Transaction
SM49 Execute external OS commands
SM50 Work Process Overview
SM51 List of SAP Systems
SM56 Number Range Buffer
SM58 Asynchronous RFC Error Log
SM59 RFC Destinations (Display/Maintain)
SM61 Backgroup control objects monitor
SM63 Display/Maintain Operating Mode Sets
SM64 Trigger an Event
SM65 Background Processing Analysis Tool
SM66 Systemwide Work Process Overview
SM69 Maintain External OS Commands
SMEN Session Manager Menu Tree Display
SMGW Gateway Monitor
SMLG Maint.Assign. Logon Grp to Instance
SMLT Language Management
SMQ1 qRFC Monitor (Outbound Queue)
SMQ2 qRFC Monitor (Inbound Queue)
SMQR Registration of Inbound Queues
SMQS Registration of Destinations
SMT1 Trusted Systems (Display <-> Maint.)
SMX Display Own Jobs
SNL1 Display NLS (character set, lang.)
SNOTE Note Assistant
SNRO Number Range Objects
SNUM Number Range Driver
SO00 SAPoffice: Short Message
SO01 SAPoffice: Inbox
SO02 SAPoffice: Outbox
SO03 SAPoffice: Private Folders
SO04 SAPoffice: Shared Folders
SO05 SAPoffice: Private Trash
SO07 SAPoffice: Resubmission
SO23 SAPoffice: Distribution Lists
SO50 Rules for inbound distribution
SO99 Put Information System
SOST Overview transmission requests
SP01 Output Controller
SP12 TemSe Administration
SPAD Spool Administration
SPAM Support Package Manager
ST01 System Trace
ST02 Setups/Tune Buffers
ST03 Performance,SAP Statistics, Workload
ST03N R/3 Workload and Perf. Statistics
ST04 DB Performance Monitor
ST05 Performance trace
ST06 Operating System Monitor
ST07 Application monitor
ST10 Table Call Statistics
ST11 Display Developer Traces
ST14 Application Analysis
ST22 ABAP dump analysis
STAD Statistics display for all systems
STAT Local Transaction Statistics
SU01D User Display
SU03 Maintain Authorizations
SU51 Maintain Own User Address
SU52 Maintain Own User Parameters
SU53 Evaluate Authorization Check
SU55 Call the Session Manager menus
SU56 Analyze User Buffer
SUIM User Information System
S_BCE_68001285 Transaction S_BCE_68001285
S_BCE_68001402 With Unsuccessful Logons
S_BCE_68001418 Act. Grps According to Complex Crit.
S_BCE_68001420 Act. Grps According to Complex Crit.
S_BCE_68001429 Transactions for User
TU02 Parameter changes
USMM Customer measurement
WE02 Display IDoc
WE05 IDoc Lists
WE07 IDoc statistics
WE08 Status File Interface
WE09 Search for IDoc in Database
WE20 Partner Profiles
WE21 Port definition
WE30 Development IDoc Type
WE46 IDoc administration
WE60 Documentation for IDoc types
WE61 Documentation for IDoc record types
I think idea here should be to understand the process more than giving actual values for such kind of posts. If, Lee were to make a role directly based on these tcodes what would be his justification as a security consultant for having provided these values.
Every company would have its own unique policy for authorizing Basis consultants.
Some may want the consultants to be authorized with relevant tasks like system admin or database admin or security admin or user admin seperately.
While some may want these tasks to combined by one group of consultants.
I would also want to provide the display access to all functional tcodes to the security roles as it may be needed more often or not to solve the authorization issues.
I would rather stick to the security policy of my company and the job rrequirements of the consultant when designing these roles.
> I would rather stick to the security policy of my company and the job rrequirements of the consultant when designing these roles.
I couldn't agree more. Unfortunately OP doesn't want to go through the design process and there happened to be a spoonfeeder around....... Oh, well, some companies will get the quality they deserve.
@Ashok: Please do not spoonfeed in this forum.
@Lee: As far as basis roles are concerned, my basis admins will only be authorized to do their work if they can specify what they need. That makes creating the basis roles an ongoing design and build process for a few months with a tailormade result.
The process of trial and error does make them mad at occasions but the worst thing I've ever had to do was threaten them to tell their boss they cannot tell me what their job is about. Worked like a charm
Thanks for the responses. Actually, I'm a basis guy and I have seen such a different discrepency with Basis roles in every company, I just wanted to get some feedback from all of you to see your thoughts on security for Basis. Many companies I go to just take the sap_all profile and take away the authorities they don't want basis people to have and other companies start with a limited transaction set and make the basis guys tell them what other access they need (which can be frustrating). I just wanted to keep a good list so that when I get asked that question at various clients I can give them a good answer.
Can I chime in on this topic?
When I started late on my current project the entire Basis team had sap_all. They were well into realization and experiencing a lot of problems with system stability, data corruption and people stepping on each other's toes by making changes.
I fought like heck to remove sap_all from every Basis member. We had pretty good Basis roles set up by our SI. Yes there were transactions missing but the deal I offered was simple:
I''m taking sap_all away effective immediately. You will never see it again. However, I'm going to give you these roles and promise you that if and when you find a transaction missing, I will immediately add it. Day, night, on vacation whatever, I will stop what I am doing and make sure you have what you need.
It frustrated some of our Basis admins to the point of insanity but we now have rock solid, position and task based roles. Oh yeah, most of our problems have gone away now. Personally I thought it was only fair to make myself available for immediate assistance since I was removing their crutch - that's all sap_all was for us.
I think well designed Basis roles work better than just giving out sap_all like Halloween candy. By removing sap_all and assigning them true Basis roles we have also eliminated potential audit issues with SoDs. No longer can our lead Basis guru create users at will. The deal again is that if a user is needed (system, service etc) that I am available via phone for emergencies.
My personal opinion is that if you are going to take away sap_all be willing to go the extra mile to ensure the team does have the tools they need.
> Can I chime in on this topic?
Thanks for chiming in, even although the thread is closed.
I enjoyed reading your post and agree with you - if nothing else has been done, then you need to support the transision to a based-on-need-role as a "tool", otherwise it will fail.
Other very usefull tools are:
- Provide a password vault and/or Single-Sign-On solution --> these folks often has many systems and clients to administrate, and their authority might be less of an immediate risk than the way they manage their passwords.
- Give them an emergency user procedure (as this ball typically ends up in basis's court to solve) --> long before Virsa FireFighter there were ways of doing this. If you know what you are doing, you can implement one on your own in only a few days with about 30 lines of code in the right place, and a bit of carefull config. Carefull config should be in place anyway.
From my experiences, if you provide security solutions and explain the risks which are being mitigated, only unreasonable or unknowledgable people will resist.
Thanks again for adding your insight!
Edited by: Julius Bussche on Jan 12, 2009 12:54 AM
Thanks for the start!
And while yes, my companies needs are probably different. I prefer to start as close to correct as possible and remove and add access as needed. My company can't wait on me to do weeks of analysis for 6 users for them to get started. So boo hoo to the "spoon feed" comments.
The only implementation I have been security architect on is HCM. Our GBS team has to put together process documents before we do implementation testing. I looked through the Process documents for each transaction used and derived what object values to use based on the text of the process. We have several cycles of testing which of course found some missing object values and reports not previously on their process documents.(Not many ) So in essence for the end user roles I started with 0 and added as needed. However, I had close to 6 months to do this process.
I am now being asked to find a way to reduce Basis's access for all systems and if I could have it done yesterday. Which is why I was looking through here to see if someone had a more efficient way of doing this. Specifically for Basis, I would rather take broad approach and remove slowly instead of taking a narrow approach and add as requested. (This is for their FireFighter access anyway.)
I don't recall who the poster was - maybe third from the top - gave a list of many, many transactions but,
you don't need all of them. There are many you do need. As a Basis Admin. in my shop, we don't have authority for the IDOC transactions ie. WExx and I haven't needed them. Applications support and Developers use them here. Also, your security team should be the ones controling what transactions a given role has authority to. Some have given you links within the SAP site(s). Stick with SAP recommendations and not third party links. A while back our security team was trying to be more SOX compliant and took some transactions away but we demonstrated the need for them so we got them back. Good luck.