SQL 2008 R2 crea un usuario / esquema cuando el usuario de Windows crea tablas


9

Agregamos un inicio de sesión en el servidor y un usuario de la base de datos que asigna un grupo de Windows a una instancia de SQL 2008 R2 utilizando el siguiente script, con los nombres cambiados por anonimato:

USE master
go
CREATE LOGIN [DOMAIN\AppUsers] FROM WINDOWS
WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
go
USE AppDb
go
CREATE USER [DOMAIN\AppUsers] FOR LOGIN 
[DOMAIN\AppUsers]
go
EXEC sp_addrolemember N'db_owner', N'DOMAIN\AppUsers'
go

Cuando la cuenta DOMINIO \ Usuario1 inicia sesión en la aplicación, Usuario1 consulta las tablas en el esquema dbo bien porque Usuario1 es miembro de DOMAIN \ AppUsers, pero esta aplicación también permite al usuario crear tablas. Al crear estas tablas sin especificar un esquema , SQL Server hace lo siguiente:

  1. Crea un usuario 'DOMINIO \ Usuario1' en AppDb que utiliza un inicio de sesión 'DOMINIO \ Usuario1' que no figura en SSMS \ Seguridad \ Inicios de sesión para la instancia.
  2. Crea un esquema 'DOMINIO \ Usuario1' en AppDb.
  3. Crea esas tablas usando el nuevo esquema 'DOMINIO \ Usuario1'.

Estoy completamente desconcertado por estos resultados. Aquí están mis preguntas:

  1. Esperaría que la creación de la tabla fallara en lugar de crear objetos adicionales. ¿Alguien puede señalarme la parte de Books Online que explica esto?
  2. ¿Por qué el servidor no crea un esquema 'DOMINIO \ Usuarios de aplicaciones' y agrega las nuevas tablas a ese esquema si va a agregar esquemas?
  3. Además, ¿cómo utiliza la base de datos un inicio de sesión que no se muestra en SSMS \ Security \ Logins?
  4. Al mirar al usuario 'DOMINIO \ Usuario1' en SSMS \ Bases de datos \ AppDb \ Seguridad \ Usuarios, el icono del usuario tiene una pequeña flecha roja que apunta hacia abajo. Qué significa eso?

Recién estamos comenzando a usar la autenticación de Windows dentro de una organización que prefiere la autenticación de SQL por simplicidad, por lo que estoy seguro de que mi pregunta proviene de ignorar las diferencias. Este código se escribió mucho antes de considerar el uso de la autenticación de Windows, por lo que estoy seguro de que necesitamos mejorar nuestra comprensión de la creación de nuevos esquemas cuando inicie sesión con la autenticación de Windows como cualquier otra persona que no sea el propietario de la base de datos.

En caso de que no pueda saberlo, soy yo quien impulsa el uso de la Autenticación de Windows sobre la Autenticación de SQL. Si no llegamos a una comprensión sólida de esto, volveremos a la Autenticación SQL.


Puede definir el esquema predeterminado {dbo, por ejemplo} para usuarios de dominio, pero no para grupos de dominio.

Respuestas:


9

Esto siempre ha sucedido, volviendo a SQL Server 2000.
Sin esquema, ¿cómo sabe SQL Server que desea incluirlo en el dboesquema?

La única forma de especificar un esquema predeterminado es:

  • usar inicios de sesión SQL (no Windows)
  • ejecutar como "sysadmin"

Ninguno de estos es aceptable

La mejor práctica es calificar siempre el esquema para cada referencia de objeto para DDL y DML. Existen claros beneficios de rendimiento debido a la reutilización del plan.

Además, el uso deliberado del esquema es mejor para SQL Server 2005:

  • mesas en Data
  • otras mesas en Archive, Stagingetc.
  • código en esquemas por permisos de cliente: Desktop, WebGUIetc.

Usar el esquema dbo es tan último milenio :-) Enlaces:


Entonces, mi conclusión es que debemos actualizar el código para prefijar nuevas tablas con el esquema, ¿verdad? ¿Significa esto que es frecuente que aparezcan nuevos usuarios en el nodo Seguridad?
flipdoubt

@flipdoubt: sí a ambos. Una vez en ella, y el uso de esquemas como espacios de nombres o recipientes, se convierte en una segunda naturaleza
GBN

Una última pregunta. Si es una práctica común tener usuarios agregados automáticamente y una práctica recomendada para especificar esquemas durante la creación de objetos, ¿cómo puede otorgar derechos al nuevo esquema antes de que el usuario creado automáticamente cree un error al consultar un objeto en el nuevo esquema? Usando el ejemplo que publiqué con respecto a 'DOMINIO \ Usuario1', puedo asignar acceso a la cuenta 'DOMINIO \ Usuarios de aplicaciones', pero ¿las consultas usarán los derechos de acceso para 'DOMINIO \ Usuario1' o 'DOMINIO \ Usuarios de aplicaciones'? Es tan astuto que el servidor crea al usuario tan pronto como se crea el objeto.
flipdoubt

Los permisos predeterminados para el propietario del esquema, que es user1. Esto es como DB_OWNER para esquema
gbn

2

Bueno, @gbn escribe más rápido que yo ...

Mi única oferta es ... Usted hace referencia al usuario que está iniciando sesión en la aplicación y le permite crear tablas y demás. Si la aplicación lo permite y el usuario no lo hace a través de SQL Server (iniciando sesión directamente en la base de datos mediante SSMS), deberá consultar con el proveedor de esa aplicación.


Nosotros escribimos la aplicación.
flipdoubt

2

Aunque la pregunta es muy antigua y ya tiene una respuesta aceptada, intentaré responder sus preguntas más específicamente (en lugar de dar consejos generales).

  1. El comportamiento está documentado en https://docs.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql , en la sección "Esquema implícito y creación de usuarios"

  2. Si desea que los objetos se creen en un esquema particular (cuando el esquema no se especifica explícitamente en la declaración), debe especificar el DEFAULT_SCHEMA para el usuario. En SQL Server 2008 R2 (y versiones anteriores), obtendría un error si intenta asignar un DEFAULT_SCHEMA a un usuario basado en un grupo de Windows, pero en SQL Server 2012 (y versiones posteriores) esto ahora es posible.

  3. No se muestra simplemente porque no hay inicio de sesión para ese usuario. Como se especifica en https://docs.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql , se puede crear un usuario para alguien que inicia sesión con un grupo diferente o incluso sin cualquier inicio de sesión

  4. La pequeña flecha roja (o la pequeña x roja en las versiones más recientes de SSMS) representa a un usuario que no tiene el permiso CONNECT en la base de datos (sin embargo, este permiso se puede obtener a través de otro grupo).


0

Si bien esta es una pregunta anterior, he observado este comportamiento (en SQL Server 2014) y he encontrado lo siguiente:

Dado el guión

USE [master]
CREATE DATABASE [Test]

USE [Test]

-- Note that we create the users without specifying the default schema
CREATE USER [MyDomain\MyADGroup] FOR LOGIN [MyDomain\MyADGroup] -- ad group
CREATE USER [MyDomain\MyDomainUser] FOR LOGIN [MyDomain\MyDomainUser] -- ad user (not in said AD group)

ALTER ROLE db_ddladmin ADD MEMBER [MyDomain\MyADGroup]
ALTER ROLE db_ddladmin ADD MEMBER [MyDomain\MyDomainUser]

EXECUTE AS LOGIN = 'MyDomain\MyAdGroupUser' -- a windows account which is a member of [MyDomain\MyADGroup]

CREATE TABLE Test
(
    a INT
)

REVERT 

EXECUTE AS USER = 'MyDomain\MyDomainUser'

CREATE TABLE Test
(
    a INT
)

Este script creará dos tablas llamadas Test.

El primero CREATE TABLEcrea una tabla llamada [MyDomain\MyAdGroupUser].[Test]y también crea el MyDomain\MyAdGroupUseresquema (así como un MyDomain\MyAdGroupUserusuario de la base de datos que está deshabilitado)

el segundo CREATE TABLEcrea una tabla llamada[dbo].[Test]

La razón de esto es que, como los CREATE TABLEcomandos no indican explícitamente el esquema, utilizarán el esquema predeterminado.

Como no especificamos el esquema predeterminado al crear los usuarios, SQL Server establece el esquema predeterminado del usuario de Windows como dbo, pero NO establece NINGÚN esquema predeterminado para el usuario del Grupo de Windows y, por lo tanto, esto provoca la creación del esquema / usuario

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.