Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to switch a whole SAP system to be Display ONLY

Former Member
0 Kudos

In a couple of months one of our SAP environments will need to be DISPLAY only.

All data, users etc… is slowly being replicated in a brand new SAP system. As the responsible of the SAP Security accesses, the business is asking me to make a plan on how we could turn the (switch OFF) to display only.

Honestly I have no idea except trying to find all roles with display access only, assigning them and hope that will do the job. There are +1000 roles in Prod and I don’t want to start changing the roles because that will require people to test all changes.

They need to be able to access the data (But I don’t know what exactly). Does somebody know or have an idea on what I could propose as match plan.

All ideas are welcome

Thanks Nancy

1 ACCEPTED SOLUTION

Former Member


Thanks All for sharing your knowledge. I am really amaized

Many THANKS !!

33 REPLIES 33

Former Member
0 Kudos

Hi Nancy,

there is no system parameter you can set to restrict system access to display only. I am afraid that you will have to do it via authorizations.

Best regards

Stefan

Colleen
Advisor
Advisor
0 Kudos

Hi Nancy

It's already been said that there is no switch/parameter to do this

It comes back to clearly defining a decommission plan that goes through each process area to determine what is required. At a starting point you could look at:

  • Identity the group of users who really need the access (your business might identify a central team instead of everyone having access - much easier to stop users forgetting they are on a new system and simplify data access and training).
    • Less people with access is also easier to remind them not to press save or post (if for some reason they still have update permissions).
  • Work the the process areas to identify what needs to be access and how frequently (what didn't get migrated, what is required for historical checks and what needs to be accessible if auditors/other areas ask for evidence). This break down will also determine who actually needs the access.
  • Display/reporting role for each process area (and if you need to cut down to specific enterprise areas)
  • Build a support role type level that provides table access (if you need to)
  • Consider if there is a need to export data to a business warehouse or similar if historical reports are necessary
  • Some access can be limited through config/data settings - for example close all posting periods to prevent someone from accidentally posting a transaction. Talk with your functional experts for these options.
  • Talk with the tech team (Basis, etc) to see what periodic jobs needs to be scheduled and even system/setup performance/hardware reductions to save a bit on cost.... though this might already be covered in your project.

Depending on your system requirements, access to the legacy data shouldn't need to be. Therefore, if you have an authorisation error on the display access (better to be too restrictive) then you should have the time to fix the role

Do not attempt to build a SAP_ALL display role or you will risks inadvertently providing change access.

A large part of this is around the change management and figuring out what actual legacy data access is required as part of day-to-day versus occasionally checking or compliance (must retain data for x number of years type deal).

On a positive - you have a few months to sort this out. Many places get a few weeks/days out from go live before they have this realisation.

Regards

Colleen

Former Member
0 Kudos

I have a little trick which is only a partial solution and not very practical, but it work as far as single testing is concerned for me once before.

Let the user logon to the system on a secondary application server. Once logged on, shut down the central instance. This takes the enque server down with it and all applications which need a lock to create or set a lock to change / delete don't work anymore, regardless of your authorizations, you can only display (in all clients of the whole system).

If you can ensure that you have message server based load balancing and remove all the dialog processes from the central instance so that no one can logon to it or better still use the logon restrictions as instance parameters described in SAP note 1891583 to prevent logons to it to access the enque process for all those not meant to make changes, then you can stop the enque server in SM12 which should make the same effect. If super users must make a change for some reason which is respected by the enque process, then just kick everyone out and temporarily start it again.

Having said this, there might be some applications which do not work properly anymore (eg downloading a role in PFCG will not work anymore either even although it is display activity) and some changes will still be recorded (eg. when you logon in display mode, the logon date and time and potentially new password is still changed in USR02).

Disclaimer: I take no responsibility for using this advice (you mentioned any ideas) as although it appeared to work for me once before, I do not know which other side effects this might have.

Cheers,

Julius

0 Kudos

Hi Julius

I see you are being creative here and placed your disclaimer. However, isn't this solution assuming that you know when the user wants to access the system so you can shut the central instance down?

Regards

Colleen

0 Kudos

What I had used once before was to shut the entire CI instance down. In that case the user must already be logged on and they must be on a remote instance.

But a variant of it would be to block only the enque server itself from ever setting any locks. Then the CI can be kept up and running and users can logon / logoff as they wish, in display mode.

However it will leave at least 2 gaps -> applications which change the database directly without setting a lock (eg. debugging of tables) and files written / deleted from the application server file directory (e.g. security audit log).

Cheers,

Julius

0 Kudos

if you do this how is usr02 table updated for last logon and passwords? How can they perform user admin?

0 Kudos

Events such logon date and timestamps are not subject to locks. Writing of security audit log or system log is not either.

Yes, user admin and roles and customizing and master data and application data subject to locks will all be switched to display only, regardless of your authorizations.

Cheers,

Julius

0 Kudos

okay, that's good to know...

I only raised this as I was on a customer site during an upgrade and we had issues with PFUD/logging on.

Quite a large number of users had a "all users role assigned", however, due to dual development stream the the new version of the role had a different profile Id. Therefore, when PFUD ran it had to do a heap of read/writes/inserts/deletes to remove the old profile from the user and add the new one. PFUD placed a enqueue lock on the user and did not release the lock until after the COMMIT (makes sense). However, it means all users were "locked" until that one role was finished.

Whilst this happened, users would attempt to logon but could not. We had suspected it was due to the enqueu lock and need user login sequence updating USR02 (unless it was refreshing USRBF* buffer tables).

As a result, I assumed the login sequence to SAP had a lock statement for the user tables.

Regards

Colleen

0 Kudos

No, that sounds like an old lock problem on role assignments in CUA. It was fixed a few years ago to only lock the user locally.

GRC noise might also get in the way in future, but currently it does not respect locks. Also a way of dealing with the problem as a best guess approach.

Cheers,

Julius

Former Member
0 Kudos

Thanks all for your replies, I am working for a really huge company and I really do not want to try anything unusual! like Julius suggested.

I will follow my first ideas... same as Colleen.

Thank You Nancy

Former Member
0 Kudos

Nancy,

Another safeguard you could consider is locking the update transactions. A company I worked for previously had a reporting instance that was a copy of production, refreshed nightly via a synchronization job. After the nightly refresh, another job was run that relocked all the update tcodes. That way, even if you accidently grant an update authorization, the users won't be able to get into update transactions.

Regards,

Gretchen

0 Kudos

Hmmm... that sounds like a rather flawed idea to me...

Is executing a report in the foreground or background job an "update transaction" or not? Or SBWP - update or not?

Cheers,

Julius

0 Kudos

As safeguard ok, but not a final solution.

How do we lock updated transaction ?

0 Kudos

Julius,

It has been a while since I worked there, but my recollection is that when in doubt, they locked it. Since the intention was to have a reporting instance with production data of <24 hours old so that long running reporting transactions would be run there so as to not slow down the regular production client, report transactions were not locked. It may sound like a flawed plan, but it seemed to work for that large SAP shop of 50K+ users.

Gretchen

0 Kudos

Nancy,

My recollection is that the job run by Basis locked them all, then unlocked the specified display/ reporting transactions. You had to go through a review and approval process to have another tcode added the unlock routine.

Gretchen

0 Kudos

And don't forget transactions line ME23N that start as display transactions but can switch to change mode without needing access to transaction ME22N. You do still need change authorisation, but you can make changes from the display transaction.

If I had to do this, I'd do both. Change the authorisations and lock the transactions. Belt and braces. Less likely that something will slip through.

May I ask, what's the point of keeping the read-only system? Just for reference? It isn't a continuously updated read-only, but rather a frozen copy. Is that right? How important is it that the system doesn't change at all?

If I was really paranoid, if it really mattered that this system existed and couldn't be changed, I'd do the above, and also build in a nightly restore from backup (or equivalent) to wipe out any changes that slipped through anyway. With modern storage systems rolling back a system takes all of a few minutes if it is done right., and can be automated. Ask your Basis people!

Steve.

0 Kudos

Locking all tcodes and then unlocking only some reporting. Yes, that would probably work to create a reporting only daily copy of a SAP system. Nice idea actually!

Whether that fits the shoe of a production system which is to be frozen against changes might be challenged by the tcodes which are multi activity capable and not reporting.

Thanks for the background and sharing the idea - will keep it in my sleave for a rainy day 🙂

Cheers,

Julius

0 Kudos

What do you mean by if you were paranoid? 😉

Yes, good point about navigation and switching modes...

But for pure reporting only, I think Gretchen's solution wpukd work for the usual reporting requirements in display only produced lists.

Cheers,

Julius

0 Kudos

What you could additionally do is close the FI and CO periods in OB52 and OKP1. That will bring quite a lot to a stand still...

Cheers,

Julius

0 Kudos

We want to keep the system for reference only, also for auditor., We are in Canada and they tranfer all SAP systems oversea.

0 Kudos

Auditors like certainties. In general "we think it is read only, but we can't be sure" doesn't cut it. Especially if external accounts are at stake. For internal reference I'd go for the "change all the profiles and lock transactions" approach, but also take a backup that I'd restore before auditors needed access.

I guess if people ask for proof that nothing has changed you can suggest they look at the change document tables. There shouldn't be any since the system was frozen, except maybe for users/roles/profiles.

Steve.

Former Member
0 Kudos

This message was moderated.

Former Member


Thanks All for sharing your knowledge. I am really amaized

Many THANKS !!

Former Member
0 Kudos

Hi,

You can create a sap_all display role. How? You create a role on PFCG like Z:Sap_all_display. Then import standart sap_all role in to it.. And save and execute it. Then download the role to computer. Open it with notepath and change all activty=03. And upload it to sap.

Regards.

O.K.

0 Kudos

I have lost count of how often this has been suggested and then flamed...

Try going to CS01 and you can create a cost center. You can.

Try going to MM03 and displaying change documents. You cannot.

Try going to SM36 and scheduling a job which is only protected by S_PROGRAM and it will delete your customizing or shut the system down.

Etc...

Cheers,

Julius

0 Kudos

Hi Julius,

You are right but you can change some authorizations while saving the new role. You can export some t-code authorization from s_tcode object. Am I wrong?

Regards,

O.K.

0 Kudos

Yes, your could exclude some tcodes and also add other values and fields which have an activity type of control but are not ACTVT.

Which ones do your suggest?


😉

Cheers,

Julius

0 Kudos

I choose creating new role from sap_all. Because of there aren't more time to change all roles (+1000). And no more people to test new roles. Also if you can not change some tcodes authorizations you can exclude them. And you are right you add some new objects, but only you know that users don't. 🙂

Regards

O.K.

0 Kudos

Hi O.K

I had mentioned do not create a SAP All display up in my comments.

Julius is correct - you will have a bunch of people either roll their eyes and dismiss your comment or jump in with examples such as the comments in this blog (there was another blog that had a heap more activity and then the author removed it)

From a practicality point of view I do build a form of display all for non production systems. I do copy SAP_All and then I got through each object to remove a heap of access. I used to think I could build this once and then add to my kit bag for future use, however, system versions and component activation impacts this. It takes ages to build as you have to go through each object. And even then I can't guarantee it's 100% (risk point of view, it's non production)

However, recommending this for Production is not a good idea. The whole goal is here to prevent change not take a stab at it.

Already, the approach you recommended is only a small slice of restricting access. The other blog that was removed had a heap more examples. One of my comments was ACTVT =  03 is not the only display (you have 08, 09 etc) and ACTVT is not the only field that controls activity levels. As well as that some objects are for modify only and some transactions/programs/function modules/etc were never designed to be display on.

I take the assumption if SAP could build such a role and guarantee it to be display all without risk of liability if the role doesn't restrict, then they would have build and deployed it already. End of the day, they know a heap of customers make this attempt.

Regards

Colleen

0 Kudos

the other bit to consider here - back to the business requirement and this being a production system

If you create a display all role based on SAP_ALL and assign to end users then you risk providing them with unauthorised access. The user may be restricted to certain organisational data for certain modules. You could be exposing sensitive data to unauthorised users.

I wouldn't use time as the justification.

0 Kudos

Hi Colleen,

I totally agree that buidling a display role as equivalent for SAP_ALL does not work. I know this, because I tried and completely failed (see your linked post).

But in my opinion it also depends a little bit on the approach and what you really need. One must ask oneself if SAP_ALL with display restrictions is really needed, who requested it and what was the intention. Maybe it would be sufficient to provide a role containing all real display transactions of the SAP system.

If you are able to build a role based on transactions that are designed and known as display transactions, then this role would be acceptable. Otherwise SAP would have a big security problem with all its display transactions.

Maybe this role does not give you display access for the whole system, but from a business view most parts should be covered by it. It all depends on the chosen transaction set and the painful job to restrict all authorizations to display or set them to inactive if not possible.

Best regards

Stefan

0 Kudos

Hi Stefan

I saw Bernand reply to you and my attempts at putting the case forward for Non-Prod wasn't successful either

For production, I agree  role should be built and driven via the role menu with SU24 integration. You are explicit in the access you allow. Non-Production, I"m trying to protect the system whilst being more implicit in the access for Developers/etc.

This thread is all about Production so display all doesn't seem appropriate.

Regards

Colleen

Former Member
0 Kudos

I managed to solve this same problem yesterday on a project, perhaps if the parameters are the same for you them it can help.

Old system A -> new system B

Old users on old system A are already converted to the new authorization concept from system B in their own system before the migration. Roles from system B are always "leading" and some manual S_TCODE entries are tolerated for compatibility. System B will always need display roles for job functions anyway.

Users are switched to the new role on the old system A before being migrated to system B. No testing required (or integration testing can be done with real roles and not SAP_ALL and still fine tuned if need be).

Go-Live is then just switching the system ID to new system B and the roles are the same as on system A which they were already using since a few weeks.

Users on system A are then switched to the display roles from system B (so they do not continue working there or make changes).

-> If the roles for system B are well thought out and designed and SU24 is maintained and "back ported" to system A in case changes are needed there which force a merge, and you have tools to "watchdog" the roles and do "coverage analysis" of changes before making them, then you can do it in 1 day.

I did that yesterday. Worked like a charm.

Cheers,

Julius

ps: regarding locking transactions -> this does not apply to webservices, BSPs, RFCs, webdynpro apps, native apps, batch jobs, system jobs, etc etc. Locking transactions is a fluffy thing which I would not rely on, but the basis folks typically anticipate this and stop all the jobs, block SCOT, deactivate services, remove RFCs, etc so that the fluffy things don't cause trouble. You might want to check that with tem, but if they are good then they will have thought of it.