Michel Fournier from the Universal Thread posted a question regarding a failure that occurs in a Web Connection server when users log in via Basic Authentication. Basically he has a problem where the site runs fine with no one logged in but fails with Access Denied errors on the COM server.

Behind the scenes this works like this: IIS fires the request into the ISAPI extension and impersonates the Web User. Usually this is the IUSR_ or anonymous account. So while IIS runs usually under SYSTEM or NETWORK SERVICE (in IIS 6 it’s configurable with an Application Pool) before IIS passes the request forward the thread the request comes into the ISAPI extension runs under the user’s impersonation. If somebody logs on with Basic Authentication or Windows Authentication IIS impersonates that particular account for the ISAPI thread. The end result is that inside the ISAPI extension the login environment can vary.

This is so that ISAPI extensions can use the impersonation information and figure out who’s logged in and run under this security environment which can be useful at times to elevate rights – for example SYSTEM or NETWORK SERVICE generally don’t have rights to access resources on a network. In Web Connection however this shouldn’t be a problem – internally there are only a few Admin tasks that require anything but anymous access – mainly to copy update files and read configuration files. SYSTEM generally has access to the whole machine so this should not be a problem.

I’ve never really given this much thought, but for Web Connection Impersonation at the ISAPI level is really a useless feature. Web Connection runs either using a File Based mode in which case the application is completely disconnected from the ISAPI request and gets login information only from data passed as part of the Server Variables, or in COM mode in which case the COM EXE picks up the impersonation configured in the DCOM Config settings.

For Michel’s scenario the problem here is that the each user that is authenticated must have rights to the COM EXE in order to be able to execute the object. The solution here is to make sure that the users are added to the DCOM launch and access permissions either individually (not a good idea) or as a group. As a quickfix you could also use the Everyone group which is basically any logged in user. This will solve Michel’s problem.

But this got me thinking. It really doesn’t make much sense for Web Connection to be impersonating a specific account. It would make much more sense to let Web Connection RevertToSelf() which basically reverts back to the underlying account that IIS runs under – SYSTEM or NETWORK SERVICE or what’s configured for the IIS Application Pool.

This would vastly simplify the configuration story for Web Connection COM servers, because now only SYSTEM or NETWORK SERVICE or whatever account IIS or the IIS Pool runs under needs to be configured.

This could also break a few not very common user scenarios. It was previously possible for Web Connection applications in COM mode to pick up the up the logged in user IF you were running the COM server configured with permissions set to the ‘Launching User’. In this case the launching user would be the logged in user or IUSR_. I don’t think many people did this because this is very insecure (you have to assign IUSR_ rights to every file it uses), but it did allow for impersonated functionality. It can possible break scenarios where the ISAPI DLL needs to read files that don’t sit on the local machine. For example, UpdateFile and EXEFile keys in wc.ini would have to be local files.

Other than that I don’t see any issues. I think I will implement this with a new INI switch and default the switch to turn Impersonation off.

Thoughts?