JiShirley-1989 avatar image
0 Votes"
JiShirley-1989 asked ·

A Network Service Log on app can't start another application with C++

I create a C++-based service(registered in Registry, and we call it A app) and log in as Network Service.
Then I call CoCreateInstance with CLSCTX_LOCAL_SERVER in A app to launch another application(not registered, and we call it B app which has been configured with Network Service access permission).
However, the B app doesn't start.

And CoCreateInstance return E_ACCESSDENIED.

If I change the log in as System then B app can be started.
A and B apps are in the same folder which has been configured with Network Service access permissions.

I don't know why this happen.
Any suggestions? Thanks.

· 3
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

You can use Process Monitor to observe the operation of the program and determine what security configuration causes the program to fail to start.

0 Votes 0 ·

Thanks, after I use XXX -RegServer in Win7 cmd , the Service application can start the B application with Network Service account.
However this doesn't work in Win10. I don't know why?

0 Votes 0 ·

I can't build the project to reproduce your problem. You can use the Process Monitor tool to debug and check the difference between Win7 and Win10 programs to find the problem.

0 Votes 0 ·

1 Answer

cheong00 avatar image
0 Votes"
cheong00 answered ·

If you check the Event Viewer, you should be able to see lots of EventID 1006 with EventSource "Microsoft-Windows-DistributedCOM".

Look and identify the component you want to start, then go to "Component Service" mmc snap-in and grant "LocalActivation" permission for "NetworkService" to it.

· 8 ·
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks, but my issue is a System Service use CoCreateInstance( CLSCTX_LOCAL_SERVER) to start a console application with DCOM/COM settings(but not a System Service).
When the System Service use Network Service to logon, it can't start the console application which return access denied 0x8007005.
I think it is COM Security problem. If I add Network Service account into My Computer COM Security list, then it can start the console application, but it not a good solution.
Maybe I should add some security setting to the console application, but I don't know how.

0 Votes 0 ·

The most simple idea is that, "Network Service" account is created for service which needs minimum access to local resources only. The fact that you cannot start a DCOM component that you also think allowing activation from "Network Service" account means you should perhaps create a local service account (I mean a "local account" created for running the service, not the "Local Service" one because your choice of "Network Service" account means you might need to do something using the computer's credential).

And on Win7+/Win2008R2+ there exists feature named group managed service account that is convenient to manage and is designed for exactly this scenario. (The group managed one is good replacement for "Network Service") It's much like the "IIS Virutal Account" you see on Win7+ for application pools, but with domain credential.

0 Votes 0 ·

so you mean "Network Service" account is not a good account to start a DCOM component, right?

0 Votes 0 ·
cheong00 avatar image cheong00 JiShirley-1989 ·

There is a number of component that could be started with "Network Service". Say, the "Hotspot Auth Module", so it's okay to allow activation of DCOM components for "Network Service" as long as you decide it's justified to allow it.

If you think it's not right to allow activation with "Network Service" account for the component you try to use, then it's high probability that you probably choose to run the service with "Network Service" in the first place, (Remember, by choosing to run with "Network Service" account you implies the service is designed to run with minimal access to local resources), or the scope of your service expanded and outgrows what it's originally designed to do.

In that cause you had better change to to run under "Service Account", which allows you to start with "the same minimal access" as ground and add access to other service/component/file-system etc. resources as required.

0 Votes 0 ·
Show more comments

This StackOverflow answer explains it clearly.

When a COM client attempts to access COM server, COM subsystem checks client side credentials against these access lists and decides whether to allow access to server, and if server is not yet started, whether to allow its start. Hence, the two lists - for regular access and for new server launch (should it be necessary).

If you want to use that DCOM application in your service running in "Network Service" account, either grant the account the right to launch it, or run your service in different account that have right to launch it.

There is third option to impersonate another user that has right while you are using the DCOM only, but you should be very careful to do it right when going this route.

0 Votes 0 ·

Thanks a lot. I solve the problem now. Thank you for your patience.

0 Votes 0 ·