I don't know the specific of your situation, so this first idea may not be feasible but I thought I'd put it out there as an idea in case you hadn't thought of it.
Could you do the reports in ASP.Net or SQL Server Reporting Services, and have the Windows app either open the reports via a System.Diagnostoc.Process call or by having one of the forms have a WebBrowser control?
One of the apps I did gave the end users great flexibility in modifying the report criteria. In that situation, they wanted all of the repots to look the same, but report based on different criteria, I wound up giving them a form in the Win App to build the criteria on their own, much like using the Query Designer for SQL Server.
The SQL Server Reporting Services also gives some nice flexibility to the end users. There's some training involved, but if they're building reports now, I don't think the learning curve is very steep.
On a completely different tack, more closely to what you asked, one of the quick and dirty workarounds we came up to a similar situation was to have the reports saved on a web server somewhere so that regular users would open them via http, meaning they couldn't save them to the server. Report editors, on the other hand, were given rights to the repots on the web server via a file share. They could open that share up and edit the reports, then save them in the share. The next time a user opens the report, whether via the http or the shared method, they were getting the latest version.