我有一个经典的ASP编写的web服务。 在这个Web服务中,它试图通过DCOM在另一台服务器上创build一个VirtualServer.Application对象。 这与权限被拒绝失败。 不过,我有另一个组件在相同的远程服务器上的这个相同的web服务实例化,创build没有问题。 这个组件是一个定制的内部组件。
webservice从一个独立的EXE程序调用,它通过WinHTTP调用它。 已经证实,WinHTTP正在使用Kerberos对web服务进行身份validation。 用户身份validation到Web服务是pipe理员用户。 EXE到webserviceauthentication步骤是成功的,并与Kerberos。
我用DCOMCNFGvalidation了远程计算机上的DCOM权限。 默认限制允许pipe理员本地和远程激活,本地和远程访问,以及本地和远程启动。 默认组件权限允许相同。 这已经被validation。 工作组件的单个组件权限被设置为默认值。 VirtualServer.Application组件的单个组件权限也被设置为默认值。 基于这些设置,web服务应该能够实例化并访问远程计算机上的组件。
在运行这两个testing的同时设置Wireshark跟踪,一个与工作组件一起,另一个与VirtualServer.Application组件一起显示一个intresting行为。 当web服务正在实例化工作,定制,组件时,我可以看到RPCSS端点映射器上的请求首先执行TCP连接序列。 然后我看到它执行绑定请求与适当的安全包,在这种情况下kerberos。 在获得正在运行的DCOM组件的端点后,它通过Kerberos再次连接到DCOM端点进行身份validation,并成功地实例化和通信。
在失败的VirtualServer.Application组件上,我再次看到具有Kerberos的绑定请求成功转到RPCC端点映射器。 但是,当它尝试连接到虚拟服务器进程中的端点时,它将无法连接,因为它只尝试使用NTLM进行身份validation,NTLM最终失败,因为Web服务无权访问凭据以执行NTLM哈希。
为什么它试图通过NTLM进行身份validation?
附加信息:
任何人都有任何想法,为什么试图在远程服务器上创build一个VirtualServer.Application对象回落到NTLM身份validation导致它失败,并获得权限被拒绝?
附加信息:当以下代码在web服务的上下文中运行时,直接通过仅testing的,刚刚开发的COM组件运行,它在具有拒绝访问的指定行上失败。
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;
我也注意到,在Wireshark Traces中,我看到连接到服务进程组件的尝试只请求 NTLMSSP身份validation,它甚至不会使用Kerberos。 这表明,由于某种原因,Web服务认为它不能使用Kerberos …
NTLM身份validation回退是一个症状。 真正的问题是Kerberos失败的原因。
这听起来像是获得的模拟级别的经典案例不足以执行所请求的活动。 如果使用Kerberos委托,如果模拟的机器或进程没有“模拟”令牌,而是使用较低的令牌(如“身份”),则请求使用其他身份的Kerberos身份validation访问资源将失败。
有四种types的模拟令牌:
匿名
身分
模拟
代表团
“模拟”允许模拟访问执行模拟的进程所在的同一台计算机上的资源。 如果执行模拟的进程正在访问与正在执行模拟的计算机不同的计算机上的资源,则需要“委派”令牌。 这通常需要TCB权限(作为操作系统的一部分)。
TokenImpersonationLevel枚举
http://msdn.microsoft.com/en-us/library/system.security.principal.tokenimpersonationlevel%28v=vs.80%29.aspx
请注意,Windows XP / Server 2003中的DCOM默认模拟级别是“Identity”。 这意味着该进程可能无法访问资源,同时冒充另一个身份。 您可能想要试用整个机器级别或进程级别的安全性configuration,以查找哪些方法可行。 您可能会发现需要启用encryption才能连接到某些资源。 configuration一个相同的服务可能不是苹果 – 苹果的比较。
连接不同的操作系统
http://msdn.microsoft.com/en-us/library/aa389284%28v=vs.85%29.aspx
使用DCOMCNFG设置系统范围的安全性
http://msdn.microsoft.com/en-us/library/ms680051%28v=vs.85%29.aspx
使用C ++设置默认进程安全级别
http://msdn.microsoft.com/en-us/library/aa393617%28v=vs.85%29.aspx