Nous avons ajouté un utilisateur de connexion au serveur et de base de données qui mappe un groupe Windows à une instance SQL 2008 R2 à l'aide du script suivant, avec les noms modifiés pour l'anonymat:
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
Lorsque le compte DOMAIN \ User1 se connecte à l'application, User1 interroge les tables du schéma dbo très bien car User1 est membre de DOMAIN \ AppUsers, mais cette application permet également à l'utilisateur de créer des tables. Lors de la création de ces tables sans spécifier de schéma , SQL Server effectue les opérations suivantes:
- Crée un utilisateur «DOMAIN \ User1» dans AppDb qui utilise une connexion «DOMAIN \ User1» non répertoriée dans SSMS \ Security \ Logins pour l'instance.
- Crée un schéma «DOMAINE \ Utilisateur1» dans AppDb.
- Crée ces tables à l'aide du nouveau schéma 'DOMAIN \ User1'.
Je suis complètement déconcerté par ces résultats. Voici mes questions:
- Je m'attendrais à ce que la création de la table échoue plutôt que de créer des objets supplémentaires. Quelqu'un peut-il m'indiquer la partie de Books Online qui explique cela?
- Pourquoi le serveur ne crée-t-il pas un schéma «DOMAIN \ AppUsers» et n'ajoute-t-il pas les nouvelles tables à ce schéma s'il veut ajouter des schémas?
- De plus, comment la base de données utilise-t-elle une connexion non affichée dans SSMS \ Security \ Logins?
- En regardant l'utilisateur «DOMAIN \ User1» dans SSMS \ Databases \ AppDb \ Security \ Users, l'icône de l'utilisateur a une petite flèche rouge pointant vers le bas. Qu'est-ce que ça veut dire?
Nous commençons tout juste à utiliser l'authentification Windows au sein d'une organisation qui a préféré l'authentification SQL pour plus de simplicité, donc je suis sûr que ma question vient de l'ignorance des différences. Ce code a été écrit bien avant que nous envisagions d'utiliser l'authentification Windows, donc je suis sûr que nous devons améliorer notre compréhension de la création de nouveaux schémas lorsque vous vous connectez à l'aide de l'authentification Windows en tant que personne autre que le propriétaire de la base de données.
Dans le cas où vous ne pouvez pas le dire, je suis celui qui pousse à l'utilisation de l'authentification Windows sur l'authentification SQL. Si nous ne parvenons pas à une bonne compréhension de cela, nous reviendrons à l'authentification SQL.
la source
Réponses:
Cela s'est toujours produit, retour à SQL Server 2000.
Sans schéma, comment SQL Server sait-il que vous voulez le mettre dans le
dbo
schéma?La seule façon de spécifier un schéma par défaut est de:
Aucun de ces éléments n'est acceptable
La meilleure pratique consiste à toujours qualifier le schéma pour chaque référence d'objet pour DDL et DML. La réutilisation du plan présente des avantages évidents en termes de performances.
En outre, l'utilisation délibérée du schéma est préférable pour SQL Server 2005:
Data
Archive
,Staging
etc.Desktop
,WebGUI
etc.L'utilisation du schéma dbo est donc le dernier millénaire :-) Liens:
la source
Eh bien, les types @gbn sont plus rapides que moi ...
Ma seule offre est ... Vous faites référence à l'utilisateur se connecte à l'application et il permet à l'utilisateur de créer des tables et autres. Si l'application le permet et que l'utilisateur ne le fait pas via SQL Server lui-même (se connectant directement à la base de données à l'aide de SSMS), vous devrez vérifier auprès du fournisseur de cette application.
la source
Bien que la question soit très ancienne et qu'elle ait déjà une réponse acceptée, je vais essayer de répondre à vos questions plus spécifiquement (plutôt que de donner des conseils généraux).
Le comportement est documenté dans https://docs.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql , dans la section "Schéma implicite et création d'utilisateurs"
Si vous souhaitez que les objets soient créés dans un schéma particulier (lorsque le schéma n'est pas spécifié explicitement dans l'instruction), vous devez spécifier DEFAULT_SCHEMA pour l'utilisateur. Dans SQL Server 2008 R2 (et versions antérieures), vous obtiendriez une erreur si vous essayez d'affecter un DEFAULT_SCHEMA à un utilisateur basé sur un groupe Windows, mais dans SQL Server 2012 (et versions ultérieures), cela est désormais possible.
Il n'est pas affiché simplement parce qu'il n'y a pas de connexion pour cet utilisateur. Comme spécifié dans https://docs.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql , un utilisateur peut être créé pour quelqu'un qui se connecte en utilisant un groupe différent ou même sans toute connexion.
La petite flèche rouge (ou le petit x rouge dans les versions plus récentes de SSMS) représente un utilisateur qui n'a pas l'autorisation CONNECT dans la base de données (cependant, cette autorisation peut être obtenue via un autre groupe).
la source
Bien que ce soit une vieille question, j'ai observé ce comportement (dans SQL Server 2014) et j'ai constaté ce qui suit:
Étant donné le script
Ce script va créer deux tables appelées Test.
Le premier
CREATE TABLE
crée une table appelée[MyDomain\MyAdGroupUser].[Test]
et crée également leMyDomain\MyAdGroupUser
schéma (ainsi qu'unMyDomain\MyAdGroupUser
utilisateur de base de données qui est désactivé)le second
CREATE TABLE
crée une table appelée[dbo].[Test]
La raison en est que, comme les
CREATE TABLE
commandes n'expriment pas explicitement le schéma, elles utiliseront le schéma par défaut.Comme nous n'avons pas spécifié le schéma par défaut lors de la création des utilisateurs, SQL Server définit le schéma par défaut de l'utilisateur Windows comme dbo mais ne définit AUCUN schéma par défaut pour l'utilisateur du groupe Windows et, par conséquent, cela provoque la création du schéma / utilisateur
la source