Una de las principales tareas con las que lidiamos en nuestro día a día es dar soporte a equipos que explotan nuestras bases de datos. A veces (lamentablemente muchas ) el equipo no nos facilita el mensaje de error concreto y nos comenta o nos envía un correo indicando “no puedo lanzar una select o un update sobre una tabla”
Para confirmar que en realidad está intentando realizar esa operación y no otra, o para confirmar que está lanzando esa query sobre una tabla y no sobre otra (puede que sea en otro esquema), podemos usar la sentencia EXECUTE AS :
https://docs.microsoft.com/en-us/sql/t-sql/statements/execute-as-transact-sql
De esta forma el contexto de seguridad cambia y nos impersonalizamos en otro login/usuario.
Vamos a realizar un laboratorio sobre esta sentencia:
1.Creamos un usuario en el gestor:
USE [master]
GO
CREATE LOGIN [login_test] WITH PASSWORD='login_test', DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
2.Creamos el Usuario en nuestra base de datos de prueba:
USE [DBA]
GO
CREATE USER [login_test] FOR LOGIN [login_test]
GO
3. En la base de datos “DBA” tenemos estas 2 tablas:
Vamos asignarle permisos de lectura sobre el esquema ‘casa’:
use [DBA]
GO
GRANT SELECT ON SCHEMA::[casa] TO [login_test]
GO
Ya creado nuestro pequeño laboratorio, vamos a ponernos en la situación de que el aplicativo que usa el usuario login_test nos indican que están teniendo “problemas” con la base de datos y que creen que es un tema de permiso. Con la ayuda del EXECUTE AS, sin la necesidad de saber la password, vamos a investigar que puede estar ocurriendo:
EXECUTE AS USER = 'login_test'
GO
Y lanzamos la query sobre la tabla en la que sí que tiene permisos:
Devuelve resultados y, cómo veis en la captura, la función SUSER_NAME devuelve el usuario con el que estamos lanzando la query y la función ORIGINAL_LOGIN devuelve el login original:
¿Y si lanzamos la query sobre la tabla Personas del esquema trabajo?
Nos devuelve el error que nos ayudará a solucionar el problema, simplemente con darle SELECT sobre la tabla o esquema en concreto.
Para revertir esta impersonalización, lanzamos un REVERT y volvemos a ser nosotros:
Me habéis salvado el culo con la entrada.
¡GRACIAS FAMILIA DBA!
Funcionaría si el run as lo hacemos a un usuario de dominio? Y si no existe como tal pero si un grupo?
Buena pregunta
¿Si cierro el SSMS también se produce un REVERT?
Si, al abrir una nueva sesión (una nueva ventana en SSMS) se pierden todos los cambios que realizaste en la sesión.