Office Automation and IIS

  • Article

Every once in a while, I see users asking about how to automate Office applications on the server, either to create a Word document, an Excel spreadsheet, or Powerpoint slidedeck. I understand the noble intentions to re-leverage the functionality of Office and make it web accessible to many simultaneous clients/co-workers. However, there are many caveats to this approach, including the fact that Office is meant to run Interactively and not meant to be simultaneously used...

Question:

everyone,

I have a ASP.NET 2.0 application that is creating powerpoint documents on the fly using powerpoint com objects that are installed on the server. I am having some issues with security

It is currently working, but the website is running as administrator and I would like to tighten up those permissions.

The website is a stand alone site. I created its own AppPool called PowerpointAppPool

The website is loaded into that pool. If I set the identity to my own personal Administrator Account everything works fine.

What I tried to do:

1. I created a Domain User account called PPT ACCESS
2. I set the Identity on the PowerpointAppPool to PPT ACCESS with the password i set
3. then I went to AdminTools->Component Services->DCOM Config and set the PPT ACCESS user to full launch/access/config privilidges on Microsoft Powerpoint Presentation

I thought that would do it, but no good.

1. Is this what I should be doing?
2. Is there another service in DCOM that needs to be enabled (eg. a global MS Office App)?
3. Is there a way to debug where the access failure is coming from?

Answer:

Unfortunately, your questions actually have little to do with IIS/ASP.Net and everything to do with Office Automation. Specifically, you are asking about using Office Automation interface as an automated server-side application instead of end-user client-side automation.

I suggest first researching the permissions (DCOMCNFG) and privileges (secpol.msc) needed by the Office Automation COM objects, and then make sure that the user account executing code on your behalf on IIS has those permissions.

  • This blog entry describes how IIS and ASP.Net determine the user identity used to execute code on your behalf. You must tune privileges and related ACLs to this user identity. You also need to remember that depending on the authentication protocol and server configuration, you may not be able to use that user identity to hop off the server as a remote-authenticated user for security reasons - while an interactive user would not have such a "double-hop" restriction.
  • KB 257757 does a great job laying out the general problem of Office Automation and common issues. For example, it points out that Office has major problems when running with a user token that does NOT have the Interactive SID. For security reasons, IIS6 creates all user tokens WITHOUT the Interactive SID. Unfortunately, there is no way to get IIS6 to create user tokens with the Interactive SID, and there is no way to make Office work without the Interactive SID... so YMMV.

Now, before you naysayers snicker about how Microsoft is "not making its software work better together", I suggest you take a reality pill. Office is a UI application designed for single end-user Interactive use. Meanwhile, IIS and ASP.Net are server-side platforms designed for multi-user remote access. The two environments are about as polar as it gets. One should be amazed that the two cooperate to automate at all.

At this point, I can only wish you good luck on this endeavor to reduce the necessary privileges to execute Office Automation Objects.

//David