web-dev-qa-db-fra.com

Les utilisateurs ne peuvent pas afficher les tables dans un schéma non par défaut dans SSMS

Je rencontre un problème lors de la définition de VIEW DEFINITION autorisation appropriée au niveau du schéma pour l'un de mes utilisateurs. J'ai créé le schéma TestSchema et ajouté quelques tables. L'utilisateur dispose actuellement d'autorisations définies pour accéder et modifier la table (SELECT, UPDATE, DELETE, etc.) via le dbo_datareader et dbo_datawriter les rôles. Cependant, ils ne peuvent voir aucune des tables dans l'explorateur d'objets SSMS.

J'ai essayé d'accorder des autorisations pour afficher les définitions:

grant view definition on SCHEMA :: [TestSchema] to [User]

Ça n'a pas marché. J'ai essayé de définir l'autorisation au niveau de la table:

grant view definition on [TestSchema].[NewTable] to [User]

Cela n'a pas fonctionné non plus. Ensuite, j'ai essayé juste une subvention globale:

grant view definition to [User]

Et cela a fonctionné; ils peuvent désormais voir TestSchema, ainsi que d'autres schémas auxquels ils ne devraient pas avoir accès.

Mon objectif ici est de permettre à l'utilisateur de visualiser toutes les tables d'un schéma donné. Comment puis-je y parvenir? Si je devrais être en mesure de le faire par défaut, quelles autorisations dois-je rechercher pour savoir pourquoi je ne peux pas?

sql-serversql-server-2008securityssmspermissions
9
eykanal

Réponse courte: n'utilisez pas db_datareader ou db_datawriter ou leurs équivalents de refus. Ils sont uniquement à des fins de compatibilité descendante. Leur utilisation entraînera des problèmes comme celui auquel vous êtes confronté.

Si vous souhaitez donner à Alice principale les autorisations SELECT, INSERT, UPDATE et DELETE sur tous les objets table dans le schéma Sales, utilisez ce qui suit.

GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::Sales TO Alice ;

Si vous souhaitez donner à Alice principale les autorisations SELECT, INSERT, UPDATE et DELETE sur tous les objets table dans tous les schémas, utilisez la procédure suivante.

GRANT SELECT, INSERT, UPDATE, DELETE TO Alice ;

La visibilité des métadonnées fonctionnera alors correctement.

11
Greenstone Walker

Jetez un coup d'œil aux principales autres autorisations, il pourrait y avoir un refus quelque part à l'origine du problème. N'oubliez pas qu'un refus s'appliquera toujours en plus d'une subvention. Et comme ce n'est pas votre serveur, il pourrait y avoir quelque chose dans le compte que le département informatique a créé.

Utilisez quelque chose comme ça pour le niveau serveur:

    use master
    go
    SELECT a.*,b.name as 'Login ID' FROM sys.server_permissions as A inner join 
    sys.server_principals as B on a.grantee_principal_id = b.principal_id
    where b.name = 'login ID of the account'
    GO

Et quelque chose comme ça au niveau de la base de données

SELECT a.*,b.name as 'Login ID' FROM sys.database_permissions as A 
inner join sys.server_principals as B on a.grantee_principal_id = b.principal_id
where b.name = 'test'
GO
0
Nick Winstanley

Cela m'est arrivé lorsque j'ai mis à niveau notre SQL Server de 2008R2 à 2014. db_datareader ou db_datawriter ou leurs équivalents de refus fonctionnent parfaitement en 2008R2 mais ils ne fonctionnent pas en 2014.

Exemple pour accorder une autorisation dans SQL Server 2014

Si vous souhaitez accorder à l'utilisateur Alice les autorisations SELECT, INSERT, UPDATE et DELETE sur tous les objets table dans le schéma Sales, utilisez ce qui suit.

GRANT SELECT, INSÉRER, METTRE À JOUR, SUPPRIMER SUR SCHEMA :: Sales TO Alice; Si vous souhaitez donner à Alice principale les autorisations SELECT, INSERT, UPDATE et DELETE sur tous les objets table dans tous les schémas, utilisez la procédure suivante.

DONNER SÉLECTIONNER, INSÉRER, METTRE À JOUR, SUPPRIMER À Alice; La visibilité des métadonnées fonctionnera alors correctement.

Référence [Greenstone Walker].

0
Sundeep