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. CoCreateInstance(clsid,NULL,CLSCTX_LOCAL_SERVER,IID_BAPP,(LPVOID*)&pBAppAccess); 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.

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.

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

Accepted answer

Cheong00 3,471 Reputation points

2021-03-04T10:09:53.52+00:00

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.
Please sign in to rate this answer.
Ji Shirley 181 Reputation points

2021-03-05T02:31:28.323+00:00

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.

Cheong00 3,471 Reputation points

2021-03-05T03:07:24.397+00:00

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.

Ji Shirley 181 Reputation points

2021-03-05T03:19:36.347+00:00

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

Cheong00 3,471 Reputation points

2021-03-05T03:42:16.397+00:00

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.

Cheong00 3,471 Reputation points

2021-03-05T03:51:16.163+00:00

See here for step-by-step guide to do so.

Ji Shirley 181 Reputation points

2021-03-05T05:02:28.377+00:00

Thanks for your nice answer, if I choose Network Service account to start a DCOM component, then what should I do in my C++ System Service( or DCOM component) ?
I set C++ System Service to logon as Network Service account. so if it starts DCOM component, then the DCOM application will logon as Network Service account, but I can't start the DCOM app because CoCreateInstance return access denied.
The DCOM component is not registered as System Service because it doesn't need to start automatically.
Sorry I'm new in DCOM/COM, so many questions here.

Cheong00 3,471 Reputation points

2021-03-05T05:44:45.857+00:00

This StackOverflow answer explains it clearly.

[quote]
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).
[/quote]

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.

Ji Shirley 181 Reputation points

2021-03-05T06:36:03.457+00:00

Thanks a lot. I solve the problem now. Thank you for your patience.
Sign in to comment

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

0 additional answers