2011-07-25 13 views
8

Implementamos nuestras aplicaciones .NET colocándolas en la LAN y permitiendo que los usuarios se ejecuten desde allí. Somos parte de una organización muy grande y no tenemos derechos de administrador para las computadoras individuales, los servidores ni el dominio. Ni siquiera tenemos derechos de administrador para nuestras máquinas de desarrollo.Excepción de seguridad .NET en un recurso compartido de red

Cuando un usuario ejecuta una aplicación Dot-Net desde un recurso compartido de red, falla debido a una excepción de seguridad. En el pasado, hemos utilizado CASPOL (nivel de usuario) para confiar en el servidor de archivos, pero esto es un dolor de cabeza. Desarrollamos código personalizado para copiar el ensamblaje a la unidad local antes de su ejecución, eludiendo el problema de confianza. Ninguna de las soluciones es una buena respuesta. Entiendo que Dot Net 3.5 eliminará el problema.

Cuando abordamos el tema con nuestra sección de TI, nos dieron miradas en blanco cuando preguntamos sobre la configuración de confianza en máquina o servidor.

Un Microsoft site dice

Si usted es desarrollador o editor de código, es posible que también digitalmente firmarlo y luego modificar la política de seguridad para conceder más permisos a código que lleva esa firma.

Una de nuestras personas de TI me está preguntando qué necesitamos con respecto a la clave criptográfica. Quiero asegurarme de que mis suposiciones son correctas antes de responder.

  • Asunción Uno: Una clave genereated por el SN.EXE tool se puede confiar de alguna manera, ya sea en un dominio o ámbito de la empresa.
  • Supuesto Dos: Una vez que se confía en esa clave, y firmamos nuestro código con ella, se confiará que los ensamblados se ejecutarán fuera de un recurso compartido de red.
  • Assumption Three: La "confianza" es una acción de la parte de los administradores de administración/administración de dominio y sería global para el dominio/empresa. Supongo que lo agregarían al almacén de claves de la empresa/dominio a través de una magia de directorio activo.

¿Son correctas mis suposiciones o estoy fuera de la base? Una última pregunta, ¿se podría usar esta misma clave para firmar macros vba?

+1

Sólo un hilar fino, pero en realidad .net4 que eliminará este problema, no 3.5 ya que usa el tiempo de ejecución 2.0 – aL3891

+0

Estaba leyendo en varias publicaciones de StackOverflow antes de publicar esta pregunta, y la mayoría dijo que 3.5 eliminó la política de seguridad. Investigaré más. –

+1

@ aL3891: .NET 3.5 SP1 concede plena confianza a la intranet local de forma predeterminada (http://blogs.msdn.com/b/shawnfa/archive/2008/05/12/fulltrust-on-the-localintranet.aspx) . .NET 4.0 elimina la evaluación de la política CAS por parte del núcleo CLR (http://blogs.msdn.com/b/shawnfa/archive/2010/02/24/so-is-cas-dead-in-net-4- or-what.aspx). –

Respuesta

3

También he tenido este problema en el pasado, sin embargo no lo solucionamos firmando los ensamblajes, sino otorgando el conjunto de preinstalación de caspol "LocalIntranet" plena confianza (done with caspol o .net 2.0 sdk) y agregando nuestros servidores de archivos al sitios locales de Intranet en Windows.

De esta manera usted no tiene que caspol cada carpeta que desea ejecutar código fuera de, y usted no tiene que firmar todos los conjuntos y tratar con el envío de claves en torno a TI

Cuestiones relacionadas