Estoy familiarizado con los ODBC por sistema (DSN del sistema) y los ODBC por usuario (DNS del usuario). Quiero tener ODBC por aplicación. Quiero limitar las conexiones ODBC disponibles para una aplicación específica, GP 2010. Tengo varias aplicaciones GP instaladas en un servidor de terminal (múltiples directorios GP dentro de Archivos de programa que almacenan múltiples aplicaciones Dynamics.exe) y tengo varios ODBC a los que conectarme. del GP de 2010.
Quiero aplicar una regla por la cual sólo aplicaciones específicas de GP 2010 (Dynamics.exe) puedan iniciarse y conectarse a ODBC específicos. En otras palabras, quiero imponer una regla que cree una relación 1:1 entre:
- una aplicación GP 2010 (Dynamics.exe), y
- un ODBC (una instancia de SQL que admite GP)
Información del entorno:
- Windows Server 2012 estándar de 64 bits
- SQL 2008 R2 SP2
- GP 2010 SP3
Lo que he probado/aprendido hasta ahora:
He visto intentos en ciertos entornos de GP de usar una política de grupo para limitar los ODBC disponibles para los usuarios de Windows mediante el uso de DSN de usuario. Sin embargo, este enfoque no es útil cuando un usuario de Windows tiene acceso legítimo a múltiples aplicaciones de GP. Cuando inician una aplicación GP, pueden seleccionar cualquier ODBC disponible para su usuario de Windows.
He experimentado con el uso de GP 2010.macros de inicio de sesiónpara intentar resolver este problema. Sin embargo, este método es inseguro y no escala. En primer lugar, se supone que el administrador conocerá el nombre de usuario y la contraseña y, por lo general, no se modificarán. Si este es el caso, las credenciales, junto con el ODBC, se pueden incrustar en una macro de inicio de sesión (que se almacena en texto plano en algún lugar). Aún así, para poder utilizarlas, las macros de inicio de sesión deben pasarse al acceso directo de GP 2010 que inician los usuarios. Para poder especificar una ruta de destino genérica para cada aplicación GP, la macro de inicio de sesión para cada usuario deberá almacenarse en una ubicación común para cada usuario (por ejemplo, en el escritorio de su usuario). Dado que esto debe configurarse por usuario, esta sobrecarga administrativa limita la escalabilidad.
Respuesta1
No creo que tengas mucha suerte para conseguir lo que quieres, porque lo que intentas hacer no concuerda con el funcionamiento del modelo de seguridad de Windows.
Los DSN de ODBC se almacenan en el registro (ya sea HKEY_LOCAL_MACHINE, para DSN del sistema, o HKEY_CURRENT_USER, para DSN de usuario). Se pueden establecer permisos en el registro que hagan referencia a entidades principales de seguridad (Usuarios o Grupos), pero no que hagan referencia al software de aplicación (ya que el software de aplicación no es una entidad principal de seguridad). Asimismo, las API utilizadas para acceder al registro no tienen funcionalidad para implementar permisos según la aplicación que realiza el acceso. La seguridad se basa en los usuarios y su pertenencia a grupos, no en la aplicación que ejecutan.
Eliminar el acceso de los usuarios a los DSN de ODBC en realidad no impedirá que los usuarios accedan a la base de datos back-end si tienen acceso. Simplemente estás "ocultando" el acceso al ocultar el DSN, sin asegurar nada en realidad. La seguridad por oscuridad no es realmente seguridad.
No tengo experiencia con Great Plains, pero dado que su almacenamiento de back-end parece estar basado en SQL Server, creo que la forma correcta de limitar el acceso de los usuarios a la base de datos de back-end sería la seguridad de SQL Server. Un usuario que acceda a la instancia de SQL Server que aloja los datos de Great Plains, suponiendo que esté utilizando la autenticación de Windows en el DSN de ODBC, será "visto" por SQL Server con su contexto de usuario de Windows. Puede crear "Inicios de sesión" de SQL Server correspondientes a los usuarios (o, mejor aún, grupos de los que los usuarios son miembros) y limitar su acceso utilizando la funcionalidad integrada de SQL Server. Esto parece unlotemejor lugar para limitar el acceso de los usuarios, especialmente porque la propia base de datos impondrá el acceso.
(No haber usado Great Plains antes y aceptar que es posible e incluso probable que el software use cosas desagradables como la autenticación nativa de SQL Server. Si ese es el caso, entonces simplemente tienes un lío).
Respuesta2
No, pero si es tan importante, simplemente ejecute cada aplicación en sus propias máquinas virtuales en Hyper-V.