Benutzer können in SSMS keine Tabellen in einem nicht standardmäßigen Schema anzeigen

Ich habe ein Problem beim Festlegen der VIEW DEFINITIONBerechtigung auf Schemaebene für einen meiner Benutzer. Ich habe das Schema erstellt TestSchemaund einige Tabellen hinzugefügt. Der Benutzer hat derzeit Berechtigungen für den Zugriff festgelegt und ändern die Tabelle ( SELECT, UPDATE, DELETE, usw.) durch die dbo_datareaderund dbo_datawriterRollen. Sie können jedoch keine der Tabellen im SSMS-Objektexplorer sehen.

Ich habe versucht, Berechtigungen zum Anzeigen von Definitionen zu erteilen:

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

Das hat nicht funktioniert. Ich habe versucht, die Berechtigung auf Tabellenebene festzulegen:

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

Das hat auch nicht funktioniert. Dann habe ich nur einen Pauschalzuschuss versucht:

grant view definition to [User]

Und das hat funktioniert; Sie können jetzt TestSchemasowie andere Schemata sehen, auf die sie keinen Zugriff haben sollten.

Mein Ziel hier ist es, dem Benutzer zu ermöglichen, alle Tabellen innerhalb eines bestimmten Schemas anzuzeigen. Wie schaffe ich das? Wenn ich sollte in der Lage dies standardmäßig zu tun, welche Berechtigungen sollte ich suchen, warum ich nicht?

Kurze Antwort: Verwenden Sie keine db_datareaderoder db_datawriteroder ihre leugnen Äquivalente. Sie dienen nur der Abwärtskompatibilität. Ihre Verwendung führt zu Problemen wie dem, mit dem Sie konfrontiert sind.

Wenn Sie der Principal Alice die Berechtigungen SELECT, INSERT, UPDATE und DELETE für alle Objekte mit Tabellenwert im Schema Sales erteilen möchten, verwenden Sie Folgendes.

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

Wenn Sie der Principal Alice die Berechtigungen SELECT, INSERT, UPDATE und DELETE für alle Objekte mit Tabellenwert in allen Schemas erteilen möchten, verwenden Sie Folgendes.

GRANT SELECT, INSERT, UPDATE, DELETE TO Alice ;

Die Sichtbarkeit von Metadaten funktioniert dann ordnungsgemäß.

Werfen Sie einen Blick auf die anderen Berechtigungen des Principals, bei denen möglicherweise irgendwo eine Verweigerung vorliegt, die das Problem verursacht. Denken Sie daran, dass eine Ablehnung immer über einen Zuschuss hinaus gilt. Und da es nicht Ihr Dienstleister ist, befindet sich möglicherweise etwas in dem Konto, das die IT-Abteilung eingerichtet hat.

Verwenden Sie Folgendes auf Serverebene:

    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

Und so etwas auf Datenbankebene

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

Dies ist mir passiert, als ich unseren SQL Server von 2008R2 auf 2014 aktualisiert habe. Db_datareader oder db_datawriter oder deren Verweigerungsäquivalente funktionieren 2008R2 einwandfrei, aber 2014 nicht.

Beispiel zum Erteilen einer Berechtigung in SQL Server 2014

Wenn Sie der Benutzerin Alice die Berechtigungen SELECT, INSERT, UPDATE und DELETE für alle tabellenwertigen Objekte im Schema Sales erteilen möchten, verwenden Sie Folgendes.

GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA :: Sales TO Alice; Wenn Sie der Principal Alice die Berechtigungen SELECT, INSERT, UPDATE und DELETE für alle Objekte mit Tabellenwert in allen Schemas erteilen möchten, verwenden Sie Folgendes.

GRANT SELECT, INSERT, UPDATE, DELETE TO Alice; Die Sichtbarkeit von Metadaten funktioniert dann ordnungsgemäß.

Referenz [Greenstone Walker].