Thursday, November 11, 2010

Using Microsoft Office 2007 with DCOM on a webserver in a safe way

It's been a while since I've written anything on the blog, but I think that I have something interesting for some people now.

These past weeks I have been battling our webservers and application to get DCOM calls from IIS to Microsoft Office 2007 working. After several high hopes and nervous breakdowns I have found solutions to all the catches I have found.

I'll first describe our environment a bit.
We have Windows server 2008 R2 servers (that means it's running x64mode) with Office 2007 (that's 32 bit) installed on it. The Webserver needs to be able to make a snapshot of a certain page in an uploaded Office document and show it on the website.

To be able to open Office from IIS you need to change DCOM security for the Office applications.

So the first problem that can happen is that after installing Office you don't find the objects in the Component Services MMC, normally they should be under "Component Services"/"Computers"/"My Computer"/"DCOM Config".
If you can't find them, open the Component Services MMC in 32 bit mode by opening a run box (-R) and typing "mmc -32" (without the quotes). Then add the Component Services Snap-in using "File"/"Add/Remove Snap-in" then select "Component Services" and click on "Add".
Now the office applications should be visible under "Component Services"/"Computers"/"My Computer"/"DCOM Config".
(this solution is described on many blogs over the Internet, I just repeat it here to have a more complete solution in one place)

The next problem is that IIS 7.5 by default runs under the Account "IIS AppPool\DefaultAppPool", people often change this to "network Service" or even "local System" (YUCK!!!! Really people.... Never run IIS under "local system"!!! this means that if a hacker can exploit IIS he will be GOD on your system)
This is a security feature from Microsoft that I don't want to turn off lightly... So I don't!!!

I just give the user "IIS AppPool\DefaultAppPool" the rights on the locations it needs.. (including DCOM activation)
However this user cannot run Office by himself, so we will have to create a proxy user which I'll call sa_DCOM for now (sa meaning Service Account) This user needs to be in the users group and have write rights to the location where office will need to write the files)

So open the Component services MMC.
A lot of sites tell you to change the default security on "Component Services"/"Computers"/"My Computer"/"DCOM Config" itself. But this is not best practice as that way you'll open up all the DCOM applications on your server to be exploited by hackers.
so navigate to the path "Component Services"/"Computers"/"My Computer"/"DCOM Config" and then open up the properties to "Microsoft (Office) Word 97 - 2003 Document" (the Office depends on the version of office you have. In 2010 it's no longer there)
now do the following settings:

Security/ Launch and Activation Permissions Customize -> Selected,
Edit
Add: IIS AppPool\DefaultAppPool with local launch and activation rights

Security/ Access Permissions Customize -> Selected
Edit
Add: IIS AppPool\DefaultAppPool with local Access rights

Security/ Configuration Permissions Customize -> Selected
Edit
Add: IIS AppPool\DefaultAppPool with read rights

Identity -> This user-> Selected, User = \sa_DCOM.

This way Office and IIS will allways run with the lowest permission needed.

Now we would think that we're there...
Alas not!

Microsoft Office Word needs the user that runs the application to have it's registry keys loaded.
The problem is that, as soon as the user sa_DCOM is logged off, its hive unloaded. So we'll have to find a way to keep the profile loaded. My solution for this is that I have created a dummy service which does absolutely nothing and let that service run as sa_DCOM. As soon as the service starts the profile is loaded and Word will run without problems. (so set the service to start automatically).

The settings for Word that I have done above can be done for Powerpoint and Excel also. And other programs also I would think, however I have only tested these three...

I hope that some of you guys will be spared (any more) hear tearing and crying by reading this post.

Here are some of the DCOM Errors I have solved with the above solution:
Error Exception from HRESULT: 0x800A03EC
Exception from HRESULT: 0x800AC472
and of course the access denied error 0x80004005

5 comments:

Andrey said...

Good article.
I already tried this method... but not successful...
The problem remains. Microsoft Word dcom application does not work correctly when i set identity to this user and select sa_DCOM. result = starts 2 processes winword.exe under sa_DCOM and they do nothing and live forever...
i set rights to dcom, to folder with word documents (for read and write), create dummy service and run it under sa_DCOM...
I can correctly run Word application only with "The interactive user" identity, but when log off = same result...

What i'm doing wrong? Can you help?

os = windows server 2008 r2
office = 2007

schprit said...
This comment has been removed by the author.
schprit said...

Some things, you can do to troubleshoot this:

When the Dummy Service is started, does the registry key for your DCOM user exist on the server? If not then something is wrong with the way your service is loaded.

If you run procmon (a sysinternals tool, that you can find on the Microsoft site) do you see any places where you get access denied as a result? if so then probably that is where you'll have to look for the error.

And also make sure that your code doesn't try to do things that require more elevated priviliges than your DCOM user has... To find out if this could be the case give the DCOM user administrator rights (JUST FOR THE TIME OF THE TEST!!!) and reboot the server.

Please let me know if you find out anything...

Andrey said...

Thanks for quick reply, but problem remains...

When dummy service start - registry keys for sa_DCOM exist (S-1-5-21-... and S-1-5-21-..._Classes).

In procmon for winword.exe i don't see any access denied as result.

Also i give sa_DCOM administrator rights and reboot server... nothing changed

Should sa_DCOM exist in the list Users in Task Manager? I see there only myself

I think - problem is caused by difference between identity options for word dcom application "The interactive user" and "This user". I set myself (local administrator at server) as "This user" and try again... same error - iis application can't launch word application (process winword.exe runs, but 2 instances!!!)

Do you have any ideas that may help?

Tech blog said...

Thanks for a good explanation.
I got one doubt, On the server side Does office software should be installed or not?
Do we really need to spend one license for this ?