it-swarm.com.de

Berechtigungsproblem in SSMS: "Die SELECT-Berechtigung wurde für das Objekt 'extended_properties', Datenbank 'mssqlsystem_resource', ... Fehler 229) verweigert."

Hier ist der einfachste mögliche Reprofall.

  1. Erstellen Sie eine brandneue Datenbank. (Ich verwende SQL 2005.)
  2. Erstellen Sie ein Login, einen SQL-Benutzer und eine Tabelle in der neuen Datenbank (siehe Beispielcode unten).
  3. Starten Sie SSMS und öffnen Sie den Objekt-Explorer. Melden Sie sich an als neu erstellter Benutzer.
  4. Versuchen Sie, den Ordner "Tables" im Objekt-Explorer zu öffnen.

Das Problem

Schlägt mit dieser Fehlermeldung fehl.

Nachrichtentext:

TITEL: Microsoft SQL Server Management Studio
Fehler beim Abrufen von Daten für diese Anforderung. (Microsoft.SqlServer.Management.Sdk.Sfc)
Für Hilfe klicken Sie auf: Link
ZUSÄTZLICHE INFORMATION:
Beim Ausführen einer Transact-SQL-Anweisung oder eines Batch ist eine Ausnahme aufgetreten. (Microsoft.SqlServer.ConnectionInfo)
Die SELECT-Berechtigung wurde für das Objekt 'extended_properties', Datenbank mssqlsystemresource ', Schema' sys 'verweigert. (Microsoft SQL Server, Fehler: 229)
Für Hilfe klicken Sie auf: Link

Dieser Benutzer can greift auf die Tabelle und den Datensatz in der Tabelle zu. Der Benutzer kann nicht greift jedoch auf die Liste der Tabellen im Objekt-Explorer zu.

SELECT USER_NAME() AS CurrentUser, col1
FROM dbo.TestTable

CurrentUser col1
----------- ----
robg_test   1000

Die einzige Problemumgehung, die ich gefunden habe, ist, dem Benutzer höhere Berechtigungen als nötig zu geben (wie db_datareader).

Die Frage:

Was ist das minimum-Privileg, damit dieser Benutzer die Tabellenliste im Objekt-Explorer öffnen kann?

Ich habe versucht, dem Benutzer verschiedene Berechtigungen für das Dbo-Schema zu gewähren, aber das hat nicht geholfen.

Beachten Sie auch, dass ich einen SQL-Benutzer verwende, um das Problem zu veranschaulichen. Das ursprüngliche Problem lag bei einem AD-Benutzer.

Hier ist eine relativ ähnliche Frage bei Serverfault.


Code

SET NOCOUNT ON
USE master
GO
IF EXISTS (SELECT * FROM sys.server_principals WHERE name = N'robg_test')
    DROP LOGIN [robg_test]
GO
CREATE LOGIN [robg_test]
WITH
    PASSWORD         = N'CLK63!!black',
    DEFAULT_DATABASE = [RGTest],
    DEFAULT_LANGUAGE = [us_english],
    CHECK_EXPIRATION = OFF,
    CHECK_POLICY     = ON
GO

IF EXISTS (SELECT * FROM sys.databases WHERE name = 'RGTest')
    DROP DATABASE [RGTest]
GO
CREATE DATABASE [RGTest]
GO
USE [RGTest]
GO
CREATE USER [robg_test] FOR LOGIN [robg_test] WITH DEFAULT_SCHEMA = [dbo]
GO
CREATE TABLE dbo.TestTable (col1 int)
GO
GRANT SELECT ON dbo.TestTable TO [robg_test]
GO
INSERT INTO dbo.TestTable VALUES (1000)
GO
16
Rob Garrison

Bitte überprüfen Sie, ob Sie die db_denydatareader-DB-Rolle nicht überprüft haben. Durch das Entfernen des Schecks hat es für mich funktioniert.

69
Eltigani

Ich hatte ein ähnliches Problem und löste das Problem, indem ich zwei Rollen db_denydatareader und db_denydatawriter für diesen Benutzer entfernte und weitere Rollen hinzufügte. Ich habe SQL Management Studio verwendet.

9
Cool Man

SSMS versucht, die erweiterten Eigenschaften der Tabelle mithilfe von fn_listextendedproperty abzurufen. Gemäß MSDN lauten die erforderlichen Berechtigungen, um die erweiterten Eigenschaften einer Tabelle anzuzeigen 

ALTER auf dem Tisch OBJECT

Ihr Login-Test sollte diese Berechtigung als Besitzer der Testtabelle haben (es ist der Eigentümer, oder?). Aber selbst wenn Sie nicht über Berechtigungen für die Tabelle verfügen, sollte die Abfrage für erweiterte Eigenschaften eine leere Ergebnismenge liefern, nicht aber den Zugriff verweigern. Die Tatsache, dass Sie bei einem Sys-Objekt in der Ressourcendatenbank einen Fehler mit verweigertem Zugriff erhalten, zeigt an, dass die Codesignatur der Systemressourcendatenbank (mssqlsystemresource) fehlerhaft ist. Haben Sie eines der "##" -Zertifikate vom Master abgelegt? Haben Sie ein Objekt in der Ressourcendatenbank manuell geändert? 

Jedenfalls haben Sie zu diesem Zeitpunkt eine aussehende Instanz, die wie eine beschädigte Instanz aussieht. Ich würde Ihnen empfehlen, sich an den Produktsupport zu wenden, um zu erfahren, wie Sie die Instanz wieder in einen zusammenhängenden Zustand bringen können.

1
Remus Rusanu

Ich hatte ein ähnliches Problem. Ich habe es gelöst, indem ich den Benutzer zur öffentlichen Rolle hinzugefügt habe. Wenn Sie dies nicht tun wollten, habe ich auch festgestellt, dass es behoben werden könnte, indem Sie dem Benutzer die Berechtigung für die Ansicht sys.extended-properties erteilen (in den Systemansichten der Datenbank, auf die Sie zugreifen möchten).

1
Eric Weir

"Durch das Erstellen der SQL Server-Datenbank mit einem Konto ist dieses Konto Eigentümer und hat alle erforderlichen Zugriffsrechte." 

Keine weiteren Verbesserungen der Berechtigungen erforderlich.

Dieser Ansatz hat den Zugriffsfehler beseitigt, um den es in diesem Thread geht. Ich habe einen Zugriffsfehler in SSMS sowie in Visual Studio (EF) festgestellt, wobei die Windows-Authentifizierung verwendet wurde und die SQL Server-Datenbank mit dem Administratorkonto erstellt wurde.

Praktische Lösung für mich war: 

SSMS> Als Administrator starten, SQL Server-Anmeldung: mit Windows-Authentifizierung - KEINE SQL-Server-Datenbank erstellen -, sondern um einem Konto "Erlaubnis" zu geben. 

dann SSMS-Anmeldung mit diesem Konto (das über die Berechtigung "create db any" für master verfügt) , um die (leere) Datenbank zu erstellen

(VISUAL STUDIO xtra: Verbindet sich dann in Visual Studio mit diesem Konto mit dem SQL-Server und vergleicht das Schema zwischen LocalDB (Quelle) und SQL Server-Datenbank (Ziel). Funktioniert gut: Die Ziel-Datenbank erhält das Schema und Dateninhalt)

0
user7077707