Ir al contenido principal

Diferencia entre inicio de sesion y usuario!

En este capítulo se explica la diferencia entre Inicio de Sesión y Usuario de Base de Datos. Al contrario que en otros motores de base de datos, SQL Server tiene dos niveles de profundidad en la definición de sus Usuarios. Por un lado está el Inicio de Sesión (el usuario con el que nos conectamos, el de la password) y por otro lado está el Usuario de Base de Datos (se le asigna al Inicio de Sesión) que es sobre el que se asignan los permisos de acceso a los objetos de base de datos. Esta es una duda típica en quienes empiezan con SQL Server. También se explicá el SID y el UID, que son los usuarios huérfanos (orphaned users) y como repararlos (sp_change_users_login ), syslogins, sysusers, CREATE LOGIN, CREATE USER, sp_addlogin, sp_grantlogin, sp_adduser, sp_addsrvrolemember, sp_addrolemember, etc.

Un Inicio de Sesión (Login) representa la conexión a la Instancia de SQL Server. Dicha conexión debe validada por algún tipo de servidor de autenticación, de tal modo, que podemos encontrar Inicios de Sesión de Windows (la validación la realiza el Sistema Operativo, y representa al usuario contextual con el que hemos iniciado sesión en Windows) e Inicios de Sesión de SQL Server (la validación la realiza SQL Server, luego es el motor de base de datos quién debe almacenar la contraseña - o su hash - y quién debe validar al usuario).
En cualquier caso, un Inicio de Sesión definido en una Instancia puede pertenecer a determinadasFunciones de Servidor (Server Roles) de dicha Instancia, y cuya pertenencia suele conceder determinados privilegios en dicha Instancia de SQL Server (ej: pertenecer a BULKADMIN permite poder realizar cargas masivas en cualquier base de datos de la Instancia, siempre que además se tengan permisos sobre la tabla de destino, claro).
Por otro lado, ocurre que los objeto a los cuales habitualmente deseamos acceder (procedimientos almacenados, tablas, etc.), se encuentran en una u otra base de datos de la Instancia, es decir, no se encuentra definidos en la Instancia como tal. Por ello, en cada Base de Datos a la que tengamos que acceder deberemos de tener un Usuario. Aquí está la principal diferencia entre ambos conceptos: un Inicio de Sesión (Login) se define a nivel de Instancia mientras que un Usuario se define a nivel de Base de Datos.
Habitualmente, se crea un Inicio de Sesión para una persona (o aplicación) que necesite conectarse a SQL Server, y seguidamente se crea un Usuario para ese Inicio de Sesión sobre la base de datos a la que se desea conceder acceso, de tal modo, que si dicho Inicio de Sesión debe de poder acceder a varias bases de datos, deberá tener un Usuario en cada base de datos.
En las siguientes consultas se muestra como un Inicio de Sesión se almacena en la base de datos master (a nivel de la Instancia) y queda definido por su SID, mientras que los Usuarios se almacenan en cada Base de Datos particular y quedan definidos por su UID aunque tienen asignado el SID que les corresponda según el Inicio de Sesión al que pertenecen (este es el mapeo del que hablábamos).
-- *** Ver los Inicios de Sesión de la Instancia de SQL Server ***
select sid, name
from master..syslogins

-- *** Ver los Usuarios de la Base de Datos actual de SQL Server ***
select uid, name, sid
from sysusers
where islogin=1
A continuación se muestra la forma de crear Inicios de Sesión (Logins) y Usuarios (Users) en SQL Server 2000 y SQL Server 2005. En SQL Server 2005 se dispone de las nuevas sentenciasCREATE LOGIN y CREATE USER, aunque aún se mantiene compatibilidad con los procedimientos almacenados sp_addloginsp_grantlogin y sp_adduser de versiones anteriores del producto.
-- *** Crear Inicio de Sesión de SQL Server en SQL Server 2000, ***
-- *** hacerlo miembro de dbcreator, y darle permisos de lectura y escritura en Northwind ***
EXEC sp_addlogin 'MyNewLogin', 'P@ssw0rd', 'Northwind'
EXEC sp_addsrvrolemember 'MyNewLogin', 'dbcreator'
USE Northwind
EXEC sp_adduser 'MyNewLogin', 'MyNewUser'
EXEC sp_addrolemember 'db_datareader', 'MyNewUser'
EXEC sp_addrolemember 'db_datawriter', 'MyNewUser'

-- *** Crear Inicio de Sesión de SQL Server en SQL Server 2005, ***
-- *** hacerlo miembro de dbcreator, y darle permisos de lectura y escritura en Northwind ***
CREATE LOGIN MyNewLogin WITH PASSWORD = 'P@ssw0rd', DEFAULT_DATABASE = AdventureWorks
EXEC sp_addsrvrolemember 'MyNewLogin', 'dbcreator'
USE AdventureWorks
CREATE USER MyNewUser FOR LOGIN MyNewLogin
EXEC sp_addrolemember 'db_datareader', 'MyNewUser'
EXEC sp_addrolemember 'db_datawriter', 'MyNewUser'
Un error típico es el de usuarios huérfanos (orphaned users). Consiste en el hecho de tener un Usuario, pero sin tener asociado a él su Inicio de Sesión correspondiente. Pero, y esto, ¿por qué ocurre?. Un caso típico, al restaurar una base de datos en una Instancia distinta de en la que fué creada, aunque puede haber más motivos. Es importante tener en cuenta, que los Inicios de Sesión y los Usuarios se mapean por el ID del Inicio de Sesión (SID), no por el nombre del Inicio de Sesión (no vale crear un Inicio de Sesión con el mismo nombre). Pero ¿cómo lo solucionamos?. En SQL Server 2000 y versiones anteriores, muchas personas lo solucionaban actualizando manualmente las tablas del catálogo... bien, pues así NO, y de hecho, en SQL Server 2005 no podremos actualizar manualmente los objetos de sistema. La solución para arreglar el problema de usuarios huérfanos es utilizar el procedimiento almacenado del sistemasp_change_users_login, tanto en SQL Server 2000 como en SQL Server 2005. También es posible crear un Inicio de Sesión de SQL Server con el SID que deseemos, si lo especificamos en CREATE LOGIN o en sp_addlogin (ver la ayuda del producto para más información). A continuación se muestra un ejemplo de sp_change_users_login.
USE Northwind
GO
EXEC sp_change_users_login 'Update_One', 'ExistingUser', 'NewLogin'

Comentarios

Entradas populares de este blog

¿En qué puerto TCP escucha SQL Server 2005? ¿Cómo cambiar o configurar el puerto TCP de escucha de una Instancia de SQL Server 2005?

Una buena práctica inmediatamente después de instalar SQL Server 2005 es cambiar el Puerto TCP de escucha, por múltiples motivos: Seguridad, Configuración de reglas de acceso de Firewall, Aplicaciones cliente que requieren un puerto TCP estático para SQL Server, etc. En este Artículo se explica cómo averiguar en qué puerto TCP escucha SQL Server 2005, cómo cambiar el puerto TCP de escucha de SQL Server 2005, etc. Resulta de gran interés ser capaz de responder a la pregunta  ¿En qué puerto TCP escucha SQL Server?  Por defecto, una  Instancia por Defecto de SQL Server 2005  queda configurada durante la instalación para escuchar en el  puerto TCP-1433 , sin embargo,  las Instancias con Nombre  quedan configuradas durante el proceso de instalación para escuchar en  puertos TCP dinámicos , por lo tanto, cada vez que se inicie la Instancia puede que escuche en un puerto diferente. Esta situación puede resultar problemática, por un lado desde el punto de vista de la seguridad (el hecho d

¿Qué es el nivel de aislamiento (Isolation Level) de una Transacción? ¿Qué niveles de aislamiento ofrece SQL Server?

Esta capítulo explica qué es el nivel de aislamiento (isolation level) de una transacción, el comportamiento de SQL Server en operaciones de lectura o de escritura, se detallan los diferentes niveles de aislamiento basados en bloqueos (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) y los niveles de aislamiento basados en versionado de filas (READ COMMITTED SNAPSHOT, SNAPSHOT), se explican los males de la concurrencia (lecturas sucias, lecturas no repetibles, lecturas fantasma, y conflictos de actualización), como establecer el nivel de aislamiento deseado (SET TRANSACTION ISOLATION LEVEL y las opciones de base de datos READ_COMMITTED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLATION), cómo conecer el tiempo máximo de bloqueo (@@LOCK_TIMEOUT) y como establecer el tiempo máximo de bloqueo (SET LOCK_TIMEOUT), etc. El nivel de aislamiento de una transacción (transaction isolation level)  define el grado en que se aísla una transacción de las modificaciones de recursos o datos rea

Aumentar y Reducir la TempDB en SQL Server?

Una buena práctica después de instalar SQL Server (y que interesa revisar periódicamente) es tener bien dimensionada la base de datos TEMPDB, es decir que el  tamaño inicial de TEMPDB  sea suficiente, y en consecuencia no sea necesario que TEMPDB crezca ni tampoco reducir TEMPDB (SHRINK). Esta artículo explica brevemente  para qué sirve TEMPDB , explica camo cambiar el tamaño inicial de TEMPDB (aumentar o reducir),  cómo reducir TEMPDB , cuántos ficheros son recomendables para TEMPDB, etc. ¿Para qué sirve TEMPDB?  La base de datos TEMPDB es un elemento de gran importancia en una Instancia de SQL Server, ya que  TEMPDB es la encargada de almacenar tanto los objetos temporales  (tablas temporales, procedimientos almacenados temporales, etc.),  como los resultados intermedios  que pueda necesitar crear el motor de base de datos, por ejemplo durante la ejecución de consultas que utilizan las cláusulas GROUP BY, ORDER BY, DISTINCT, etc. (es decir, las tablas temporales o WorkTables que