- SAP Community
- Groups
- Interest Groups
- Application Development
- Discussions
- Unlock SM69 By SM01
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Unlock SM69 By SM01
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-19-2010 2:15 PM
Hi,
I am a FI consultant and have a program in SAP to call the external command to execute the unixt script on unix server. My basis team has the authorization to create the external command by SM69 in our QA system. But in production, they give me a screenshot said "Transaction SM69 is locked ( in transaction SM01)" and they are requesting to unlock SM69 by SM01. I have access SM01 in DEV to test how the t-codes works. And as I don't have authorization to access SM01 in prd, I just check the table TSTC but I am confused about the information there.
Could you please help me which table shall I check for the locked t-code? Which field indicates the t-code is locked or not?
Is there any risk that I unlock the SM69 by SM01. Any table will be logged as changed?
Thank you very much.
Emma
- SAP Managed Tags:
- Security
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-19-2010 2:52 PM
You can check the Lock/Unlock status of T.code in t.code SM01. This is genearlly used to lock and
unlock transaction in SAP. SM01 in production is very risky for Functional guys as this locks
the transaction in SAP for all users. This should be used as a firefighter access and should be
given to basis guy only in case of requiredment.
SOD won't allow access of SM01 to functional team.
Hope this helps
- SAP Managed Tags:
- Security
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-19-2010 5:07 PM
>
> SOD won't allow access of SM01 to functional team.
Hi,
This has nothing to do with SOD. It is purely from a risk approach that it is recommended not to give to funkies.
I would go so far to say that if there is a requirement to lock transactions (other than on a one-off basis) then security is not built properly.
Cheers
Alex
- SAP Managed Tags:
- Security
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-19-2010 5:21 PM
Here it gives the same meaning. SM01 is admin transaction and should be with security or basis team as this team is specific for administration of access for users. And can be given to off basis team during non-availability of admin guys and can be use with care under guidance if this is new thing for one doing the task.
- SAP Managed Tags:
- Security
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-19-2010 5:42 PM
I disagree, it is not the same meaning, an SOD is different to a risky transaction. A risky transaction is one that is inherently risky due to it's nature while an SOD is a risk introduced through a combination of two or more conflicting transactions.
- SAP Managed Tags:
- Security
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-19-2010 3:00 PM
Hello,
Please check with your security team and request them to unlock the transaction. Also there would be a policy on who should unlock/lock transactions and who needs to approve for the same. Please check with responsible before you try to modify.
Regards,
Gowrinadh
- SAP Managed Tags:
- Security
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-19-2010 5:46 PM
> I just check the table TSTC but I am confused about the information there.
Good...
But if you have the correct authorizations (see Alex's post) then your should not be able to use SM69 functionality. It has nothing to do with a tcode. Perhaps display access to SM69 is what you want, or only to execute a very specific logical command? That can be done.
Try SM37, SE37 or SA38 as alternatives. They will achieve the same use of functionality regardless of locking SM69.
Cheers,
Julius
Edited by: Julius Bussche on Jan 19, 2010 9:00 PM
- SAP Managed Tags:
- Security
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-20-2010 8:03 AM
Thnak you guys. It is really inspiring.
Here is what I do...may be a little complex to you.
1. As my host vendor has no authorization to SM01, I apply a SUPERID to host vendor.
2. Under my monitor, I give SUPERID to host vendor and ask them to unlock SM69 by SM01 and give me screenshot of the unlock action.
3. Log off from SUPERID.
4. Host vendor log on PRD and create external command by his id.
5. Host vendor log on PRD by SUPERID and lock SM69.
6. Close SUPERID.
I have gone through serveral approval processes. Trust me, the backgroud work is more these 6 steps.
Thank you again.
Emma
- SAP Managed Tags:
- Security
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-20-2010 8:12 AM
Sorry to be the one to tell you this, but that is stupid security design.
If he or she can run logical system commands and access the OS as SIDADM, then placing a locked S_TCODE = SM69 in their way is a joke. They will be able to (and most likely will because of all the screenshots they have to email around) hose your security very soon.
Sorry, but that is a very weak solution for someone who knows how to actually use SM69, etc.
Cheers,
Julius
- SAP Managed Tags:
- Security
