I'm trying to set something up which works in one configuration but not in
another, so I'm hoping someone will recognise these symptoms and tell me
what's up.

I'm calling a C++ DCOM server (running as a service) from an ASP.NET page,
and these and the client web browser are all authenticated in the same
domain. A method, called from the ASP.NET page, calls CoQueryClientBlanket
in order to find out the identitiy of the user logged into the web browser.
I've set <identity impersonate="true" /> for the website to enable this.

If the website and the service are installed on the same server, the pPrivs
out parameter gets set to the string form of the domain and username of the
user running the client - this is great, although I don't know why it's a
string as it's supposed to be a handle. This is the same as what happens if
I use an app to call the service, rather than a webpage.

But if the website and the service are installed on different servers, the
pPrivs out parameter points to some structure whose identity I can't tell,
but it starts with 0 trying to assume it's a string gives an empty string.

In these two cases, all the other out params from CoQueryClientBlanket are
the same (except the encryption level) so it's not like they're using
different services that give different types of structures in the pPrivs
param - at least, not that I can tell.

So, does anyone know why there's a difference in behaviour depending on
whether the service and website are together or not? Is there a different
way I can inteprpret the pPrivs param, and if so, can I tell how I should be
interpreting it?

Is there a better way to find the identitiy of the client connecting to a
website, from within a DCOM method called from the site (I don't want to
find the client identity from the website and pass it in the method, as that
would be insecure).

I'm assuming this is an ASP.NET related issue, but if not, is there
somewhere better I should post this question?

Thanks,
Oliver