Fallo catastrófico al suplantar a otro usuario

Uso biblioteca de empresa Bloque de validación integrado con WCF. Informa System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED)) cuando me hago pasar por otro usuario con WIN32 API LogonUser y WindowsIdentity.Impersonate. Parece que hay algo mal cuando obtener evidencia de seguridad al cargar la configuración. Si elimino la codificación de suplantación, funciona sin ningún error. Estas son la parte del seguimiento de la pila de excepción, espero que le des algunos ayudantes. Gracias.Fallo catastrófico al suplantar a otro usuario

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()

Fuente

2012-10-09 Leo Wong

fyi - similar: https://stackoverflow.com/a/23650343/717732 – quetzalcoatl

-2

Véase mi respuesta a esto en este hilo en los foros MS:

http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataproviders/thread/b5b7a179-3737-4380-b6cf-843f3e71b317/

Este es el título del hilo: Agrupación de conexiones al azar lanzar excepciones COM.

Puede buscar el texto en la página de LogonUser.

Fuente

2013-05-27 16:23:45 Brannon

parece no tener relación. Lo único común es "algún problema con la suplantación". El hilo que señaló se centra en el manejo de LogonUser y maneja. No tenemos nada de eso aquí. Aquí tenemos algún problema con ConfigurationManager tratando de hacer la suplantación bajo el capó justo antes de leer el archivo y fallar en él, probablemente porque el proceso no tiene privilegios para hacer la suplantación en absoluto debido a que se ejecutó como, no sé, limitado -usuario, no interactivo, etc. – quetzalcoatl

Me parece que el problema es que System.Configuration hace la suplantación al cargar app.config. Pude evitar este problema ejecutando

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

sin pasar por alto. Al hacerlo, la posterior suplantación tuvo éxito.

EDITAR: Creo que al hacer esto, se carga y almacena en memoria caché app.config, por lo que la ruta del código que causa el problema se ejecuta solo una vez y con las credenciales originales.

Fuente

2014-04-03 18:49:00

Gracias, esto me arregló las cosas. Esto debe ser un error en .NET 4.x ... al menos en 4.5.1. No sucede con .NET 2.0. Me sale el problema al intentar establecer un valor de propiedad XmlElement. Sin embargo, si creo un nuevo XmlDocument(). CreateElement ("Test"), establezco la propiedad en ese valor, luego lo configuro para que lo configure, funciona. Muy raro. –

Después de una larga batalla y muchas capturas de ProcMon, he descubierto que bajo ciertas condiciones, hay una falla al verificar las Zonas de Seguridad durante la interoperabilidad y mientras se hace pasar por otra. Está relacionado con este KB:

https://support.microsoft.com/en-us/kb/945701?wa=wsignin1.0

Si marca el final donde se añaden un nodo de registro y clave, en lugar de añadir w3wp.exe como se indica, agrega el nombre del archivo de su propio ejecutable. Esto funcionó para mí, YMMV.

Fuente

2015-04-30 14:19:56 Cork

Fallo catastrófico al suplantar a otro usuario

Respuesta

Cuestiones relacionadas