How to Configure Process Identity for a COM(+) Server App

This is an extension of How To Chose an Indentity for a Daemon, which discussed some general strategies for picking server process identities. COM+ server apps have a large number of options for identity, as you can see from Figure 57.1.

Figure 57.1 COM+ server identity in Windows Server 2003

The only choice that's really unique to a COM+ server is the ability to run the server in the interactive user's logon session. The reason this feature exists is for debugging. Remember how window stations work (WhatIsAnAccessControlList). Daemons normally run in noninteractive window stations, which aren't bound to hardware. If a daemon pops up a modal dialog box (perhaps because of an ASSERT statement in a debug build), it's catastrophic because nobody can see it, and the daemon's thread will hang waiting for someone to dismiss this invisible dialog, so sometimes it makes sense to run in the interactive window station while debugging. In a production environment, the drawbacks to running as the interactive user are clear enough: If nobody happens to be logged in to the server console interactively, all activation requests to the COM+ server will fail. Conversely if someone does happen to be logged on and the COM+ server starts up, when that person logs off the COM+ server will be terminated along with all the other processes in the interactive logon session. So use this setting for debugging in the lab, and if possible have someone log in to the server box interactively using the daemon account under which the COM+ server normally runs. Of course, if you normally run the server under one of the built-in logins such as Network Service, Local Service, or SYSTEM¹, this won't be possible. If you need to debug your service and have it run interactively, the best you can do is log in with a temporary user account that has the same privileges and permissions as the built-in logon you'll be using during production. Of course, if your COM+ server is configured as a service running as SYSTEM, you can force it into the interactive window station by configuring the service to "interact with the desktop," but make sure to turn this off when you deploy the production system to avoid luring attacks (What Is a Lurning Attack, How to Display a User Interface from a Daemon).

If you're configuring a base COM server, you have one other option: You can run the server as "The launching user" (Figure 57.2). This is also known as "As Activator Activation." Many interactive programs, like Microsoft Excel, are designed with OLE automation interfaces, which makes them COM servers. These apps weren't designed to serve multiple clients in a distributed system as COM+ servers normally do. They were designed to service the interactive user running a script or macro from another process (perhaps from Windows Scripting Host or another COM-enabled application like Microsoft Word). Ironically, these applications should never be configured to run as "The interactive user"! Instead, they should be configured using the default identity for base COM servers, which is to activate as the launching user. Why? Well, in the normal usage scenario the interactive user will be the one launching the server, so there's really no difference. But in an attack scenario, imagine a bad guy who wishes to use a scriptable app like Microsoft Excel to attack the interactive user on some machine on the network. If Excel were configured to run as the interactive user, and if the attacker were able to launch it (this would require getting past COM launch and access permissions), he'd be running code in the interactive user's logon session immediately and could use Excel to do whatever he wanted with the interactive user's credentials. This would be a horrible situation. By configuring these OLE automation servers to run as the launching user, we avoid this. If the attacker is able to launch Excel on some unwitting person's machine, Excel will run with whatever credentials the attacker happens to be using. If the attacker can't be authenticated, the activation request will fail. The moral of the story here is to run those OLE automation servers as the launching user.

Figure 57.2 Base COM identity options

For COM servers that service many different clients in a distributed system, running as the launching user doesn't work very well. For one thing, you'll end up launching a distinct process for each unique authenticated user, which won't scale well at all (you'll be lucky if you can service over 50 clients this way). Second, you won't be able to service anonymous clients, which you may want to do in some cases. Finally, your process won't have any network credentials because you'll be running in a network logon for a remote client. It just doesn't make sense to configure a distributed server this way, which is why the COM+ identity GUI doesn't even offer this option.

To conclude, run macro-driven local OLE automation servers as the launching user, which is the default for all base COM servers. Run debug builds of your COM+ server as the interactive user in the lab if you want to see any errant dialogs that might pop up, and in production pick a least-privilege daemon account (How To Choose an Identity for a Daemon) for your server and run it noninteractively.

¹ Note that to run as SYSTEM you'll need to configure the COM+ server application to be an NT service, which can be done in Windows Server 2003 by checking a box on the Activation tab. And, of course, if you do decide to run a COM+ app as SYSTEM keep it very small, review its design and implementation carefully, and restrict who can call it. Your best bet is to allow only trusted callers from the local machine: It's terribly dangerous to allow untrusted input to be sent to a process running as SYSTEM!

PortedBy Ari Glaizel