2011-07-29 26 views
14

He logrado suplantar a un usuario con éxito. Uso de la Interoperabilidad del Usuario de Logon, p.ASP.NET se niega a respetar mi autoridad.

[DllImport("advapi32.dll", SetLastError = true)] 
    static extern bool LogonUser(
     string principal, 
     string authority, 
     string password, 
     LogonSessionType logonType, 
     LogonProvider logonProvider, 
     out IntPtr token); 

Esto funciona bien. Cuando voy a mi ventana inmediata e ingreso WindowsIdentity.GetCurrent().Name, el usuario suplantado aparece como mi Usuario actual. Cuando lanzo este usuario, vuelve a mi usuario real. No hay problemas aquí - Soy am imitando.

Sin embargo, cuando intento escribir un archivo en un recurso compartido de que el usuario tiene acceso a, me sale:

Access to the path [path name] denied..

He podido iniciar sesión en Windows manualmente, ya que el usuario me estoy personificando, navegando y escribiendo un archivo en el recurso compartido. El usuario definitivamente tiene privilegios administrativos para el directorio al que estoy apuntando.

Estoy permitiendo que el usuario final cargue un archivo y utilizando el objeto HttpPostedFileBase, escriba un archivo en este recurso compartido. Esencialmente, estoy restringiendo la suplantación al bloque de código para cargar el archivo. Una vez que haya finalizado, volverá al usuario LDAP autenticado original, p.

imp = Impersonation.ImpersonateUser("someuser","somepassword"); 
HttpPostedFileBase hpf = Request.Files[file] as HttpPostedFileBase; 
... 
hpf.SaveAs(path); 
Impersonation.StopImpersonating(imp); 

La ruta es correcta.

Cuando guardo el archivo utilizando el método SaveAs, ¿está respetando mi suplantación?

¿Está intentando escribir el archivo en otra cuenta de la que no tengo conocimiento? Y si es así, ¿cómo puedo cambiar esto?

Parece que no hay mucho control con el método SaveAs, ni una sola sobrecarga. ¿Hay alguna otra alternativa para usar este objeto que me daría un mayor control sobre mis credenciales?

+8

Has escrito authoritay wrong! ;) –

+1

¿Ha buscado en el registro de eventos de la máquina de destino para ver si hubo acceso denegado o errores de inicio de sesión? – NotMe

+0

¿Has investigado el doble salto como sugerí a continuación? – ironsam

Respuesta

3

Suena como un problema de autenticación de doble salto. ¿Has intentado obtener que el acceso compartido de red modifique el acceso al usuario IIS predeterminado de tu sitio (por ejemplo, ASPNET) y ejecute el POST/SaveAs sin el código de suplantación? Si eso falla, debe ver si las cosas están configuradas en IIS y pueden provocar problemas de autenticación del salto del servidor. Aquí podría ser un buen lugar para empezar:

http://weblogs.asp.net/owscott/archive/2008/08/22/iis-windows-authentication-and-the-double-hop-issue.aspx

+0

Suena como un salto doble para mí, cuando su aplicación está tratando de acceder a la máquina remota, es probable que esté usando la cuenta asignada a su AppPool. Mire los registros en el equipo remoto para ver si el inicio de sesión falló para confirmar la cuenta utilizada para el acceso remoto. – Zachary

+0

+1 - He visto este problema antes y fue debido al doble salto. – Fenton

0

Dice "escribir un archivo en este recurso compartido". Hay permisos separados para el recurso que para la carpeta en la computadora. ¿Has revisado los permisos de acciones?

+0

Inicié sesión como usuario, a través de la autenticación de usuario normal en Windows, navegué hasta el recurso compartido y pude escribir. Misma máquina que estoy ejecutando el código, que está intentando acceder al recurso compartido desde. –

Cuestiones relacionadas