模拟其他用户时发生灾难性故障 [英] Catastrophic failure when Impersonate other user

问题描述

我正在使用与WCF集成的企业库验证模块。当我使用WIN32 API LogonUser和WindowsIdentity模拟其他用户时，它报告 System.Runtime.InteropServices.COMException（0x8000FFFF）：灾难性失败（HRESULT的异常：0x8000FFFF（E_UNEXPECTED）） 。模仿。似乎在获取有关加载配置的安全性证据时出了点问题。如果删除模拟的编码，它可以正常工作。这些是异常堆栈跟踪的一部分，希望您能提供一些帮助。

I'm use Enterprise library Validation block intergrated with WCF. It reports System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED)) when I impersonate some other user with WIN32 API LogonUser and WindowsIdentity.Impersonate. It seems there is something wrong when to get security evidence on loading configuration. If I remove the coding of impersonation, it works without any errors. These are the part of the exception stack trace, hope you give some helpers. thanks.

System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
   at System.Security.Policy.PEFileEvidenceFactory.GetLocationEvidence(SafePEFileHandle peFile, SecurityZone& zone, StringHandleOnStack retUrl)
   at System.Security.Policy.PEFileEvidenceFactory.GenerateLocationEvidence()
   at System.Security.Policy.PEFileEvidenceFactory.GenerateEvidence(Type evidenceType)
   at System.Security.Policy.AssemblyEvidenceFactory.GenerateEvidence(Type evidenceType)
   at System.Security.Policy.Evidence.GenerateHostEvidence(Type type, Boolean hostCanGenerate)
   at System.Security.Policy.Evidence.GetHostEvidenceNoLock(Type type)
   at System.Security.Policy.Evidence.GetHostEvidence(Type type, Boolean markDelayEvaluatedEvidenceUsed)
   at System.Security.Policy.AppDomainEvidenceFactory.GenerateEvidence(Type evidenceType)
   at System.Security.Policy.Evidence.GenerateHostEvidence(Type type, Boolean hostCanGenerate)
   at System.Security.Policy.Evidence.GetHostEvidenceNoLock(Type type)
   at System.Security.Policy.Evidence.RawEvidenceEnumerator.MoveNext()
   at System.Security.Policy.Evidence.EvidenceEnumerator.MoveNext()
   at System.Configuration.ClientConfigPaths.GetEvidenceInfo(AppDomain appDomain, String exePath, String& typeName)
   at System.Configuration.ClientConfigPaths.GetTypeAndHashSuffix(AppDomain appDomain, String exePath)
   at System.Configuration.ClientConfigPaths..ctor(String exePath, Boolean includeUserConfig)
   at System.Configuration.ClientConfigPaths.GetPaths(String exePath, Boolean includeUserConfig)
   at System.Configuration.ClientConfigurationHost.CreateConfigurationContext(String configPath, String locationSubPath)
   at System.Configuration.Internal.DelegatingConfigHost.CreateConfigurationContext(String configPath, String locationSubPath)
   at System.Configuration.BaseConfigurationRecord.get_ConfigContext()

推荐答案

在我看来，问题在于System.Configuration在加载app.config时会模仿自己。我可以通过运行

It looks to me like the problem is that System.Configuration does impersonation itself when loading app.config. I was able to work around this issue by running

ConfigurationManager.GetSection("system.xml/xmlReader");

而不假冒。这样做会导致以后的模拟成功。

while not impersonating. Doing so caused the later impersonation to succeed.

编辑：稍微澄清一下，我相信这样做会导致app.config被加载并缓存到内存中，因此代码导致问题的路径仅使用原始凭证执行一次。

To clarify slightly, I believe that doing this causes app.config to be loaded and cached into memory, so the code path which causes the problem is executed only once and with the original credentials.

这篇关于模拟其他用户时发生灾难性故障的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！