Hi -

I have a web service which needs to use a C++ COM component. The ws runs
under an NT service account and allows impersonation. The directory security
allows anonymous access using the NT service account.

The ws uses the COM component to carry out some processing. When I try and
use the COM component inside the ws the call enters the component correctly
but has issues when I try and access network resources (it needs to load the
configuration from the network).

A file that I know exists on a network UNC path reports that it doesn't
exist (GetFileAttributes returns -1 (aka INVALID_FILE_ATTRIBUTES)). The
account has rights to the specified network directory and file.

If I write a simple C# application to call the same method in a C# console
application it works both when run under my NT account and also the NT
service account (using RUNAS).

Calling GetUserName inside the COM component reports ASPNET even though: i)
the service is run under the NT service account, ii) I've allowed
impersonation, iii) I've tweaked settings inside of DCOMCNFG to force the
COM component to run under the NT service account both under "COM+
applications\IIS in-process applications" and also in "DCOM config"
(although I cannot see why I'd need to do this; I know Word automation
requires this but that's another story).

Someone mentioned that threads could cause an issue but there is no
threading evident: the COM component implements a method and the ws calls it
using Interop.

Any help or other ides to try would be greatly appreciated?

TIA

- Andy

Talking to a colleague this issue could be caused by the unmanaged COM
component being loaded from a managed component which then needs to spin up
a SVCHOST and as that is outside of the managed environment it takes on the
base security being the ASPNET account.

Sounds reasonable but aside from:

1. Passing security credentials into the COM component and impersonating a
user.

2. Getting my hands mucky in the Interop code and instantiating the
component myself (probably as a DCOM component which would then allow me to
use DCOMCNFG to configure the security).

Is there any alternatives anyone can think of?

TIA

- Andy

"Andy Bates" <andy (AT) ussdev (DOT) com> wrote

Talking to a colleague this issue could be caused by the unmanaged COM
component being loaded from a managed component which then needs to spin up
a SVCHOST and as that is outside of the managed environment it takes on the
base security being the ASPNET account.

Sounds reasonable but aside from:

1. Passing security credentials into the COM component and impersonating a
user.

2. Getting my hands mucky in the Interop code and instantiating the
component myself (probably as a DCOM component which would then allow me to
use DCOMCNFG to configure the security).

Is there any alternatives anyone can think of?

TIA

- Andy

"Andy Bates" <andy (AT) ussdev (DOT) com> wrote