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:
- 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.
- Crea un esquema 'DOMINIO \ Usuario1' en AppDb.
- Crea esas tablas usando el nuevo esquema 'DOMINIO \ Usuario1'.
Estoy completamente desconcertado por estos resultados. Aquí están mis preguntas:
- 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?
- ¿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?
- Además, ¿cómo utiliza la base de datos un inicio de sesión que no se muestra en SSMS \ Security \ Logins?
- 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.
Respuestas:
Esto siempre ha sucedido, volviendo a SQL Server 2000.
Sin esquema, ¿cómo sabe SQL Server que desea incluirlo en el
dbo
esquema?La única forma de especificar un esquema predeterminado es:
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:
Data
Archive
,Staging
etc.Desktop
,WebGUI
etc.Usar el esquema dbo es tan último milenio :-) Enlaces:
fuente
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.
fuente
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).
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"
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.
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
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).
fuente
Si bien esta es una pregunta anterior, he observado este comportamiento (en SQL Server 2014) y he encontrado lo siguiente:
Dado el guión
Este script creará dos tablas llamadas Test.
El primero
CREATE TABLE
crea una tabla llamada[MyDomain\MyAdGroupUser].[Test]
y también crea elMyDomain\MyAdGroupUser
esquema (así como unMyDomain\MyAdGroupUser
usuario de la base de datos que está deshabilitado)el segundo
CREATE TABLE
crea una tabla llamada[dbo].[Test]
La razón de esto es que, como los
CREATE TABLE
comandos 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
fuente