How to Fix DCOM Access Denied Error

I’ve recently facing some persistent problem regarding the implementation of the DCOM architecture of one of my applications.

I already have the prototype that runs successfully when placed on the same machine, and I think it is only a matter of time before I can successfully placed the same application so that it can activates certain method remotely by using DCOM methodology.

For doing this, I’ve performed necessary modifications to the existing prototype and adding the authentication information so that it can be passed to CoCreateInstanceEx COM function and execute the method remotely from client machine.

I never thought that by only moving it to remote machine will involved vastly different aspect and different settings in order that this configuration can be worked out.

I’ve solving each of the symptom one by one, leaving just one symptom that persistently defies any configuration methods I’ve found either from surfing the web, or from official documentation.

This persistent symptom, is that, I can successfully create the remote DCOM object but I got 0x80070005 or Access Denied Error when try to call any one of the methods for the created object.

After exhausting any of the conventional methods, it is time to exert more focus on this one.

Upon performing more detailed examination on the server side, it is found that the client error is caused by the returned error code of 0x8009030c or SEC_E_LOGON_DENIED from AcceptSecurityContext API function of secur32.dll.

This happens inside the AcceptThirdLeg method rpcrt4.dll’s security context class. I remembered that this scenario involved the NTLM authentication process that requires three times passing through of communication between the client and server, hence the term of Third Leg implies.

In this scenario, the client is supposed to provide the authentication information using InitializeSecurityContext API call. This is indeed happens again inside the client’s rpcrt4.dll’s third leg failed initialization.

As you can see from the official documentation of the API, the client is supposed to send the credential data to the server for identity verification.

This raises the question of how the RPC infrastructure knows the credential since I haven’t changed one, so I supposed that because the credential information is not supplied, the RPC infrastructure obtained it from existing active or logged-on ID on the client (which is my ID) to be sent to the server.

This would certainly causes the Access Denied Error because my server has different ID assigned to activate the DCOM objects.

So, the solutions proves to be rather simple, i.e. how to assigned different credential to the created interface proxy from the CoCreateInstanceEx that is accepted on server side.

And it is only a matter of time before I found that there is one function that is neatly fit to the picture, i.e. the CoSetProxyBlanket API function. This function can assigned the correct credential for each interface proxy so that each method call that’s related to this object can be executed successfully without generating 0x80070005 error.

By adding this function, I can move on to another task that’s related to this project 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: