1

I have a webservice that is written in Classic ASP. In this web service it attempts to create a VirtualServer.Application object on another server via DCOM. This fails with Permission Denied. However I have another component instantiated in this same webservice on the same remote server, that is created without problems. This component is a custom-in house component.

The webservice is called from a standalone EXE program that calls it via WinHTTP. It has been verified that WinHTTP is authenticating with Kerberos to the webservice successfully. The user authenticated to the webservice is the Administrator user. The EXE to webservice authentication step is successful and with kerberos.

I have verified the DCOM permissions on the remote computer with DCOMCNFG. The default limits allow administrators both local and remote activation, both local and remote access, and both local and remote launch. The default component permissions allow the same. This has been verified. The individual component permissions for the working component are set to defaults. The individual component permissions for the VirtualServer.Application component are also set to defaults. Based upon these settings, the webservice should be able to instantiate and access the components on the remote computer.

Setting up a Wireshark trace while running both tests, one with the working component and one with the VirtualServer.Application component reveals an intresting behavior. When the webservice is instantiating the working, custom, component, I can see the request on the wire to the RPCSS endpoint mapper first perform the TCP connect sequence. Then I see it perform the bind request with the appropriate security package, in this case kerberos. After it obtains the endpoint for the working DCOM component, it connects to the DCOM endpoint authenticating again via Kerberos, and it successfully is able to instantiate and communicate.

On the failing VirtualServer.Application component, I again see the bind request with kerberos go to the RPCC endpoing mapper successfully. However, when it then attempts to connect to the endpoint in the Virtual Server process, it fails to connect because it only attempts to authenticate with NTLM, which ultimately fails, because the webservice does not have access to the credentials to perform the NTLM hash.

Why is it attempting to authenticate via NTLM?

Additional Information:

  • Both components run on the same server via DCOM
  • Both components run as Local System on the server
  • Both components are Win32 Service components
  • Both components have the exact same launch/access/activation DCOM permissions
  • Both Win32 Services are set to run as Local System
  • The permission denied is not a permissions issue as far as I can tell, it is an authentication issue. Permission is denied because NTLM authentication is used with a NULL username instead of Kerberos Delegation
  • Constrained delegation is setup on the server hosting the webservice.
  • The server hosting the webservice is allowed to delegate to rpcss/dcom-server-name
  • The server hosting the webservice is allowed to delegate to vssvc/dcom-server-name
  • The dcom server is allowed to delegate to rpcss/webservice-server
  • The SPN's registered on the dcom server include rpcss/dcom-server-name and vssvc/dcom-server-name as well as the HOST/dcom-server-name related SPNs
  • The SPN's registered on the webservice-server include rpcss/webservice-server and the HOST/webservice-server related SPNs

Anybody have any Ideas why the attempt to create a VirtualServer.Application object on a remote server is falling back to NTLM authentication causing it to fail and get permission denied?

Additional information: When the following code is run in the context of the webservice, directly via a testing-only, just-developed COM component, it fails on the specified line with Access Denied.

COSERVERINFO csi;
csi.dwReserved1=0;
csi.pwszName=L"terahnee.rivin.net";
csi.pAuthInfo=NULL;
csi.dwReserved2=NULL;
hr=CoGetClassObject(CLSID_VirtualServer, CLSCTX_ALL, &csi, IID_IClassFactory, (void **) &pClsFact);
if(FAILED( hr )) goto error1;

// Fails here with HRESULT_FROM_WIN32(ERROR_ACCESS_DENIED)
hr=pClsFact->CreateInstance(NULL, IID_IUnknown, (void **) &pUnk);
if(FAILED( hr )) goto error2;

Ive also noticed that in the Wireshark Traces, i see the attempt to connect to the service process component only requests NTLMSSP authentication, it doesnt even attmept to use kerberos. This suggests that for some reason the webservice thinks it cant use kerberos...

Improve this question

1 Answer 1

Reset to default
1

The NTLM authentication fallback is a symptom. The real problem is why is Kerberos failing.

This sounds like a classic case of the impersonation level that is obtained is insufficient to perform the requested activity. Using delegation with Kerberos, if the machine or process that is impersonating does not have an "Impersonation" token, but instead a lower token such as "Identity", requesting Kerberos authentication to access resources on using another identity will fail.

There are four types of impersonation tokens:

Anonymous
Identity
Impersonation
Delegation

"Impersonation" allows impersonation to access resources on the same machine where the process performing the impersonation is located. In cases where the process performing the impersonation is accessing resources on a different computer than where the impersonation is being performed, a "Delegation" token is required. This typically requires the TCB privilege (Act as part of the operating system).

TokenImpersonationLevel Enumeration
http://msdn.microsoft.com/en-us/library/system.security.principal.tokenimpersonationlevel%28v=vs.80%29.aspx

Note that DCOM in Windows XP/Server 2003 the Default Impersonation Level is "Identity". This means the process may not be able access resources while impersonating another identity. You may want to experiment with the machine-wide or process level security configuration to find what works. You may find that you need to enable encryption to connect to some resources. Configuring one service the same as the other may not be an apples - apples comparison.

Connecting Between Different Operating Systems
http://msdn.microsoft.com/en-us/library/aa389284%28v=vs.85%29.aspx

Setting System-Wide Security Using DCOMCNFG
http://msdn.microsoft.com/en-us/library/ms680051%28v=vs.85%29.aspx

Setting the Default Process Security Level Using C++
http://msdn.microsoft.com/en-us/library/aa393617%28v=vs.85%29.aspx

Improve this answer
5
  • I have checked this setting and set it to delegate. There was no effect. The original working component still works, and the VirtualServer.Application component is still nonfunctional, returns Permission Denied.
    – Asa Yeamans
    Apr 29, 2011 at 22:24
  • Have you tested with unconstrained delegation to determine if that works?
    – Greg Askew
    Apr 30, 2011 at 12:51
  • I have tried setting both servers to allow unconstrained delegation, this too has no effect. From what I can tell based upon network traces, it doesnt even attempt kerberos authentication when attempting to connect to the component's service endpoints. I dont see a kerberos failure at all. I am thinking that the webservice doesnt "think" it can delegate, but it can else where. I am happy to provide traces or configuration dumps if nessecary.
    – Asa Yeamans
    Apr 30, 2011 at 20:39
  • The application exhibiting the symptom - is this the internal application or a third party application? I would speculate that the client application may be detecting that something is unfit for establishing Kerberos authentication.
    – Greg Askew
    May 2, 2011 at 1:42
  • Three basic components: + Webservice (I wrote in ASP) (on webservice-server) + Virtual Server COM components (Don't work) (on app-server) + The working DCOM component (Works) (I wrote in C++) (on app-server) There is no "third party" code, just my code and microsoft code. The only security-related code in my service is: hr=CoInitializeSecurity((PSECURITY_DESCRIPTOR) &APPID_TelevisionManager, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_CONNECT, RPC_C_IMP_LEVEL_DELEGATE, NULL, EOAC_APPID, NULL); Id assume VirtServ does something like this because they support constrained delegation over DCOM.
    – Asa Yeamans
    May 4, 2011 at 16:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .