2009-08-12 13 views
8

Tenemos una aplicación que mapea mediante programación las unidades de red. En Vista con UAC activado, obtenemos algunos problemas extraños.Vista UAC - Unidades de red de localización de fallas

Nuestra aplicación mapea el disco no elevado, por lo que si el usuario navega por el explorador y hace doble clic para ejecutar un exe, solicita UAC. Entonces, cuando lo aprueban, solicita un nombre de usuario/contraseña para compartir ... Extraño ya que las credenciales se guardan.

Resulta que un proceso elevado no puede acceder a una unidad asignada que se asignó a un proceso no elevado.

Para ver este tema en la acción, hacer los pasos siguientes:

  • Ejecutar cmd.exe sin UAC
  • Ejecutar "uso neto w: \ yourhostname \ yourShare/user: yourUser YourPassword/persistente: sí "
  • ejecutar cmd.exe como Administrador
  • tipo 'w', y ver el mensaje de error

En este punto se puede ejecutar sin formato" red use "y vea que la conexión en el cmd elevado no está disponible, pero el otro cmd no elevado lo ve como OK.

¿Alguien conoce una solución para solucionar este problema? o tal vez una forma de asignar una unidad de red a "Todos los usuarios"?

+0

Esta pregunta puede pertenecer a serverfault. –

+0

No, es una pregunta sobre programación: necesitan heredar privilegios a través de la elevación. Aunque no sé la respuesta :) – bdonlan

+0

Esta es definitivamente una pregunta de programación, usamos WNetAddConnection2 y WNetCancelConnection2 desde nuestra aplicación, pero esto es análogo al comando "net use". – jonathanpeppers

Respuesta

2

Salida este enlace: Regedit Link

describen una clave de registro que permite a los usuarios elevados para acceder a las unidades asignadas y viceversa. Esto resuelve todos mis problemas y era exactamente lo que estaba buscando.

EDIT:

El enlace está muerto, pero aquí está el texto copiado de los 24 Ene, 2009 instantánea en www.archive.org:


Si están encontrando que no tiene acceso a las unidades mapeadas desde su token de administrador intente lo siguiente. Cuando se ejecuta como administrador protegido, tiene dos tokens y esta clave mantendrá la conexión para ambos tokes (eso es lo que entiendo de todos modos). También puede ayudar a resolver problemas con los scripts de inicio de sesión.

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Policies \ System EnableLinkedConnections = (DWORD) 1

también de uso es el "'Secuencias de comandos de directiva de grupo pueden fallar debido a Control de cuentas de usuario" de este documento .

http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true

Voy a publicar más información sobre esto pronto.

+0

Esto debería haber sido la configuración predeterminada en el registro. A menos que brinde una forma para que los usuarios con privilegios bajos accedan a acciones con privilegios únicos, lo que debería ser un problema manejado por separado. – Mordachai

+0

Esta solución está marcada por Microsoft como una solución no compatible que hace que su sistema no sea seguro. Úselo bajo su propio riesgo ... – Robert

+0

No estoy seguro de cómo no es seguro permitir un proceso elevado para acceder a un recurso compartido de red creado por un proceso no elevado. ¿Ya no hay un proceso elevado en la puerta? Todavía es un problema extraño, prefiero utilizar una solución no compatible para solucionarlo para la mayoría de las personas. – jonathanpeppers

2

Esto es por diseño.

Aunque la cuenta de usuario es la misma, con la versión elevada que tiene un token con membresía en el grupo de administradores y privilegios de adición, los tokens se crean independientemente y tienen diferentes LUID y parecen ser del usuario diferente inicios de sesión. Dado que son de inicios de sesión diferentes, las unidades asignadas no se comparten entre ellos.

http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx discute esto en detalle adicional.

+0

Entonces, si un usuario de Vista mapea una unidad de red, básicamente no puede ejecutar ningún exe desde una unidad mapeada. ¿Funcionaría solo si el nombre de usuario/contraseña de su cuenta de Windows coincide con el de la unidad mapeada? Esto parece una situación pobre "por diseño". – jonathanpeppers

+1

Aunque tienen el mismo nombre de usuario, los valores elevados frente a los no elevados siguen siendo usuarios distintos. ¿Debería un usuario normal mapear unidades en una cuenta de usuario administrador? ¿Podría esto causar un DOS si un usuario normal se pone en cuclillas en una asignación de unidad que necesita un administrador? ¿Podría causar un EOP si el usuario normal dirige la asignación de unidades a un lugar que el administrador no espera y hace que ejecute un binario diferente? – Michael

+0

Digo que Microsoft lo implementó mal. Elevated no debería ser un usuario diferente en cualquier forma o forma, parece que tomaron un atajo en mi opinión. ¿No hay una solución para una situación como esta? – jonathanpeppers

Cuestiones relacionadas