| Giles Middleton 2006-08-23, 1:26 pm |
| I shall try to avoid describing our components until the end...
Basically our system ran fine with IIS6.0, Windows 2000 server. And with the
advent of the NETWORK SERVICE user we cannot run our code.
We have asp.net code which calls a dcom component exe, which is configured
to run as the launching user. On windows 2000, this is ASPNET, on Windows
2003 Enterprise Edition Sp1 this is NETWORK SERVICE.
We can configure the component to use the interactive user, and it works
fine, however, that user has to be logged in! Which isn't great. And we can
configure it to use a different user, but only if that user is a member of
the Administrator group (unacceptable).
Before someone shouts that we're trying to access files/registry keys that
are admin only, we're not (on purpose). But we are using a code base which is
shared between our GUI and DCOM components. This code basically serves up
nice diagrams to the web site.
The code fails in particular when it attempts to use the VS MFC/C++ call
::LoadMenu. GetLastError() tells us ERROR_ACCESS_DENIED (5),
However, Loading string, icon, and bitmaps work fine. And we can even load
the resource through LoadResource LockResource for the same menu!) and when
it attempts to register a windows hook it also fails. (AfxHookWindowCreate
fails on ::SetWindowsHookEx) with the same code.
We know we MIGHT fix our problem with a complete re-write to not use the
Doc/View architecture and perform all functions with memory Device contexts,
but time constraints currently prevent that course of action.
Is there a way (like services) to specify that the dcom component can
interact with the desktop or get access to gui components, or that IIS can be
configured to launch calls to our exe component where it has appropriate
rights to create windows hooks.
We want to avoid making the whole of the IIS site elevated though, of course!
We wondered if the ERROR_ACCESS_DENIED was something to do with the
WindowStation/Desktop DACL, that IIS creates when it calls CreateProcess for
our DCOM server.
We have examined the resulting DACL of these when running as NETWORK SERVICE
and Administrator, and noticed that the effective rights of
DESKTOP_CREATEMENU and DESKTOP_CREATEHOOK are unavailable in NETWORK SERVICE.
But I'm not sure if this is related, as I've not managed to prove that
programmatically removing these rights from a current desktop had any effect.
It could be the IIS call to CreateProcessAsUser is not giving us adequate
winstations, or can we configure a SAFE user to have specific rights to the
GUI?
This seems to be the one missing area, in windows config tools, how to
configure rights to the desktop services for a user?
Am I on the right track or can we use a different user account with good
security, but just the ability to be slightly gui 'interactive'?
Regards
Giles Middleton
|