sql-server - usuario - quitar autenticación de windows en sql server

¿Cómo obtengo ms-access para conectarme a ms-sql como un usuario diferente?

Question

¿Cómo obtengo ms-access para conectar (a través de ODBC) a una base de datos ms-sql como un usuario diferente de su ID de Active Directory?

No quiero especificar una cuenta en la conexión ODBC, quiero hacerlo en el lado de acceso ms para ocultarlo a mis usuarios. Hacerlo en la conexión ODBC me devolvería a la situación original que trato de evitar.

Sí, esto se relaciona con una pregunta anterior: http://www.stackoverflow.com/questions/50164/

Answer 1

Creo que tendrías que iniciar el proceso de MS Access en la cuenta que deseas usar para conectarte. Hay varias herramientas que le permiten hacer esto, como CPAU . Esta herramienta también te permitirá encriptar la contraseña.

Answer 2

Admitimos aquí que está utilizando una conexión ODBC a su base de datos con Integrated Security activado, por lo que no tiene / no quiere escribir un nombre de usuario / contraseña en la cadena de conexión (que, según yo, es la elección correcta).

En este caso, afortunadamente no hay forma de "simular" a otro usuario cuando se conecta a los datos. ¡Admita conmigo que ser capaz de hacer tal cosa sería un gran salto en seguridad integrada!

Entendí por su publicación anterior que quería que los usuarios pudieran actualizar los datos o no, dependiendo de la interfaz del cliente que utilizan. Según mi opinión, la idea sería crear para cada tabla una vista vinculada ''no actualizable''. Digamos que para cada tabla llamada Table_Blablabla crea una vista (= consulta en Access) llamada View_Table_Blablabla ...).

Al usar Access, puede decidir en tiempo de ejecución si desea abrir la tabla actualizable o la vista de solo lectura. Esto se puede hacer, por ejemplo, en tiempo de ejecución, en el evento form_Open , estableciendo el origen del formulario en la tabla o en la vista.

Answer 3

@Philippe
Supongo que está usando la palabra admitir como algo equivalente a entender o tal vez estar de acuerdo ; en oposición al opuesto de negar .

Entiendo las implicaciones de hacer que todos los usuarios inicien sesión en la base de datos usando una identificación y contraseña (y que se almacenen en la aplicación). Eso para mí es un riesgo menor que el problema que estoy enfrentando en este momento.
@apagado

Algunos antecedentes más sobre el problema: Tengo conexiones ODBC configuradas en cada una de las estaciones de trabajo de los usuarios que utilizan la autenticación Windwos NT. La mayoría de las veces los usuarios se conectan utilizando una configuración MDE para usar esa conexión ODBC, en este caso SIEMPRE tienen la capacidad de agregar / actualizar / eliminar datos.

El problema es que algunos de los usuarios están lo suficientemente informados sobre MS-Access para crear un nuevo mdb y vincularlo al servidor MS-SQL. Luego pueden editar los datos directamente dentro de las tablas en lugar de pasar por la aplicación, que realiza una cierta cantidad de validación y retención manual. Y les gusta hacer esto, pero a veces lo arruinan y me causan problemas.

Answer 4

Lo que esperaba hacer (con el que experimenté) fue actualizar los enlaces a la base de datos, algo como esto para cada tabla (Nota: Cambié la conexión ODCB a la autenticación de SQL Server para este experimento y agregué las cuentas a el servidor SQL también: de solo lectura , que no puede actualizarse, y readwrite , que tiene privilegios completos en la tabla).

myTable.Connect = _
"ODBC;" & _
"DATABASE=" & "MyTestDB" & ";" & _
"UID=readonly;" & _
"PWD=readonly_password;" & _
"DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

esto les impide editar, pero no puedo hacer que una lectura posterior funcione

myTable.Connect = _
"ODBC;" & _
"DATABASE=" & "MyTestDB" & ";" & _
"UID=readwrite;" & _
"PWD=readwrite_password;" & _
"DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

Parece que cualquiera que sea el permiso con el que me conecto primero, se queda permanentemente. Si comencé a leer y luego a leer solo, la tabla permanece con los privilegios de lectura y escritura

Answer 5

Creo que puede hacer que esto funcione de la manera que desee si utiliza una "conexión ODBC DSN-LESS"

Si es necesario, mantenga sus DSN de ODBC en las máquinas de sus usuarios mediante la autenticación de Windows. Ofrezca a sus usuarios acceso de solo lectura a su base de datos. (Si crean un nuevo archivo mdb y vinculan las tablas, solo podrán leer los datos).

Cree un inicio de sesión SQL que tenga permiso de lectura / escritura para su base de datos.

Escriba una rutina VBA que pase por las tablas vinculadas y restablezca la conexión para usar su inicio de sesión SQL, pero asegúrese de utilizar la sintaxis "DSN-Less".

"ODBC;Driver={SQL Native Client};" &
"Server=MyServerName;" & _
"Database=myDatabaseName;" & _
"Uid=myUsername;" & _
"Pwd=myPassword"

Llame a esta rutina como parte de su código de inicio.

Un par de notas sobre este enfoque:

• El acceso parece tener un problema con la información de conexión una vez que cambia de Lectura / Escritura a Solo lectura e intenta volver a Lectura / Escritura sin cerrar y volver a abrir el archivo de la base de datos (mde / mdb). Si puede cambiar esto una vez al inicio para leer / escribir y no cambiarlo durante la sesión, esta solución debería funcionar.

• Al usar una conexión DSN - Menos, puede ocultar las credenciales del usuario en el código (suponiendo que le está dando un archivo mde, debería estar bien). Normalmente, las cadenas de conexión difíciles de codificar no son una buena idea, pero dado que se trata de una aplicación interna, debería estar bien con este enfoque.

Answer 6

Por qué no usar la seguridad integrada / windows. Puede otorgar a un grupo de directorio activo los derechos que desea que tengan los usuarios y luego agregar las cuentas de los usuarios a ese grupo. Creo que también puede usar la función de roles del servidor SQL además de esto para limitar la funcionalidad en función de la aplicación cliente que se esté utilizando.