SQL 2008 R2 crea utente / schema quando l'utente Windows crea tabelle

Abbiamo aggiunto un utente di accesso al server e database che associa un gruppo Windows a un'istanza di SQL 2008 R2 utilizzando lo script seguente, con i nomi modificati per l'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

Quando l'account DOMAIN \ User1 accede all'app, User1 interroga correttamente le tabelle nello schema dbo perché User1 è un membro di DOMAIN \ AppUsers, ma questa app consente anche all'utente di creare tabelle. Quando si creano queste tabelle senza specificare uno schema , SQL Server effettua le seguenti operazioni:

1. Crea un utente "DOMAIN \ User1" in AppDb che utilizza un accesso "DOMAIN \ User1" non elencato in SSMS \ Security \ Login per l'istanza.
2. Crea uno schema 'DOMINIO \ Utente1' in AppDb.
3. Crea quelle tabelle usando nel nuovo schema 'DOMAIN \ User1'.

Sono completamente sconcertato da questi risultati. Ecco le mie domande:

1. Mi aspetto che la creazione della tabella fallisca piuttosto che creare oggetti aggiuntivi. Qualcuno può indicarmi la parte di Libri online che spiega questo?
2. Perché il server non crea uno schema "DOMAIN \ AppUsers" e non aggiunge le nuove tabelle a quello schema se sta per aggiungere schemi?
3. Inoltre, in che modo il database utilizza un accesso non mostrato in SSMS \ Security \ Login?
4. Guardando l'utente "DOMINIO \ Utente1" in SSMS \ Database \ AppDb \ Sicurezza \ Utenti, l'icona utente ha una piccola freccia rossa rivolta verso il basso. Cosa significa?

Stiamo appena iniziando a utilizzare l'autenticazione di Windows all'interno di un'organizzazione che ha preferito l'autenticazione SQL per semplicità, quindi sono sicuro che la mia domanda viene dall'ignorare le differenze. Questo codice è stato scritto molto prima di considerare l'utilizzo dell'autenticazione di Windows, quindi sono sicuro che dobbiamo migliorare la nostra comprensione della creazione di nuovi schemi quando si accede utilizzando l'autenticazione di Windows come chiunque non sia il proprietario del database.

Nel caso in cui non si possa dire, sono io a spingere per l'uso dell'autenticazione di Windows su autenticazione SQL. Se non arriviamo a una solida comprensione di ciò, torneremo all'autenticazione SQL.

Questo è sempre successo, tornando a SQL Server 2000.
Senza schema, come fa SQL Server a sapere che vuoi inserirlo nello dboschema?

L'unico modo per specificare uno schema predefinito è:

• usa accessi SQL (non Windows)
• corri come "amministratore di sistema"

Nessuno di questi è accettabile

È consigliabile qualificare sempre lo schema per ogni riferimento a oggetto per DDL e DML. Ci sono chiari vantaggi prestazionali a causa del riutilizzo del piano.

Inoltre, l'uso intenzionale dello schema è migliore per SQL Server 2005:

• tabelle in Data
• altre tabelle in Archive, Stagingecc
• codice schemi per le autorizzazioni client: Desktop, WebGUIetc

L'uso dello schema dbo è quindi l' ultimo millennio :-) Collegamenti:

• Progettazione dello schema: migliori pratiche?
• https://dba.stackexchange.com/q/7257/630

Bene, i tipi @gbn più veloci di me ...

La mia unica offerta è ... Si fa riferimento l'utente accede in app e che permette all'utente di creare tabelle e così via. Se l'applicazione lo consente e l'utente non lo fa tramite SQL Server stesso (accedendo direttamente al database tramite SSMS), sarà necessario verificare con il fornitore dell'applicazione.

Sebbene la domanda sia molto vecchia e abbia già una risposta accettata, cercherò di rispondere alle tue domande in modo più specifico (piuttosto che dare consigli generali).

1. Il comportamento è documentato in https://docs.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql , nella sezione "Schema implicito e creazione dell'utente"

2. Se si desidera creare gli oggetti in uno schema particolare (quando lo schema non è specificato esplicitamente nell'istruzione), è necessario specificare DEFAULT_SCHEMA per l'utente. In SQL Server 2008 R2 (e versioni precedenti), si otterrebbe un errore se si tenta di assegnare un DEFAULT_SCHEMA a un utente basato su un gruppo di Windows, ma in SQL Server 2012 (e versioni successive) questo è ora possibile.

3. Non viene mostrato semplicemente perché non esiste un accesso per quell'utente. Come specificato in https://docs.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql , un utente può essere creato per qualcuno che accede utilizzando un gruppo diverso o anche senza qualsiasi accesso.

4. La piccola freccia rossa (o la piccola x rossa nelle versioni più recenti di SSMS) rappresenta un utente che non dispone dell'autorizzazione CONNECT nel database (tuttavia, questa autorizzazione può essere ottenuta tramite un altro gruppo).

Mentre questa è una vecchia domanda ho osservato questo comportamento (in SQL Server 2014) e ho trovato quanto segue:

Data la sceneggiatura

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
)

Questo script creerà due tabelle chiamate Test.

Il primo CREATE TABLEcrea una tabella chiamata [MyDomain\MyAdGroupUser].[Test]e crea anche lo MyDomain\MyAdGroupUserschema (oltre a un MyDomain\MyAdGroupUserutente del database che è disabilitato)

il secondo CREATE TABLEcrea una tabella chiamata[dbo].[Test]

La ragione di ciò è che poiché i CREATE TABLEcomandi non indicano esplicitamente lo schema, useranno lo schema predefinito.

Poiché non abbiamo specificato lo schema predefinito durante la creazione degli utenti, SQL Server imposta lo schema predefinito dell'utente Windows come dbo ma NON imposta QUALSIASI schema predefinito per l'utente del Gruppo Windows e quindi ciò causa la creazione dello schema / utente