it-swarm.com.de

Der Server-Principal kann im aktuellen Sicherheitskontext in SQL Server MS 2012 nicht auf die Datenbank zugreifen

Ich versuche, auf die Datenbank meines Hosting-Servers über SQL Server Management Studio zuzugreifen. Alles bis zur Anmeldung ist in Ordnung, aber wenn ich den Befehl use myDatabase verwende, erhalte ich diesen Fehler:

The server principal "****" is not able to access the database "****" under the current security context.

Ich habe gesucht und der Hosting-Dienstanbieter hat this für das Problem behoben.

Dies funktioniert jedoch wahrscheinlich nicht für mich, weil es für SQL Server Management Studio 2008 ist, obwohl ich SQL Server Management Studio 2012 verwende.

Kann das ein Problem sein? Und wenn ja, kann mir jemand seine Alternative in SSMS 2012 mitteilen?

81
Maven

Überprüfen Sie, ob Ihr Benutzer der Datenbank zugeordnet ist, in der Sie sich anmelden möchten.

70
Scott

Wir hatten den gleichen Fehler bei der Bereitstellung eines Berichts an SSRS in unserer PROD-Umgebung. Es wurde festgestellt, dass das Problem sogar mit einer "use" -Anweisung reproduziert werden konnte. Die Lösung bestand darin, die GUID - Kontenreferenz des Benutzers mit der betreffenden Datenbank erneut zu synchronisieren (d. H. Mit "sp_change_users_login" wie nach dem Wiederherstellen einer Datenbank). Ein aktives (Cursorgesteuertes) Skript zum erneuten Synchronisieren aller Konten ist beigefügt:

USE <your database>
GO

-------- Reset SQL user account guids ---------------------
DECLARE @UserName nvarchar(255) 
DECLARE orphanuser_cur cursor for 
      SELECT UserName = su.name 
      FROM sysusers su
      JOIN sys.server_principals sp ON sp.name = su.name
      WHERE issqluser = 1 AND
            (su.sid IS NOT NULL AND su.sid <> 0x0) AND
            suser_sname(su.sid) is null 
      ORDER BY su.name 

OPEN orphanuser_cur 
FETCH NEXT FROM orphanuser_cur INTO @UserName 

WHILE (@@fetch_status = 0)
BEGIN 
--PRINT @UserName + ' user name being resynced' 
exec sp_change_users_login 'Update_one', @UserName, @UserName 
FETCH NEXT FROM orphanuser_cur INTO @UserName 
END 

CLOSE orphanuser_cur 
DEALLOCATE orphanuser_cur
16
Anonymous

Ich habe eine ganze Weile mit diesem Problem gerungen und dann festgestellt, dass ich einen einfachen Fehler gemacht habe, weil ich vergessen hatte, auf welche Datenbank ich meine Verbindung abzielte. Ich habe das Standard-SQL Server-Verbindungsfenster verwendet, um die Anmeldeinformationen einzugeben:

SQL Server Connection Window

Ich musste die Registerkarte Verbindungseigenschaften überprüfen, um zu überprüfen, ob ich die richtige Datenbank für die Verbindung ausgewählt habe. Ich hatte versehentlich die Option Mit Datenbank verbinden hier auf eine Auswahl aus einer vorherigen Sitzung gesetzt. Aus diesem Grund konnte ich keine Verbindung zu der Datenbank herstellen, zu der ich eine Verbindung herstellen wollte .

Connection Properties

Beachten Sie, dass Sie auf die Schaltfläche Options >> Klicken müssen, damit die Verbindungseigenschaften und andere Registerkarten angezeigt werden.

7
Phil Ringsmuth

In meinem Fall wurde die Nachricht durch ein Synonym verursacht, das versehentlich den Datenbanknamen in den "Objektnamen" aufgenommen hat. Wenn ich die Datenbank unter einem neuen Namen wiederherstellte, wies das Synonym immer noch auf den alten DB-Namen hin. Da der Benutzer keine Berechtigungen in der alten Datenbank hatte, wurde die Nachricht angezeigt. Um das Problem zu beheben, habe ich das Synonym gelöscht und erneut erstellt, ohne den Objektnamen mit dem Datenbanknamen zu qualifizieren:

    USE [new_db]
GO

/****** Object:  Synonym [dbo].[synTable]    Script Date: 10/15/2015 9:45:01 AM ******/
DROP SYNONYM [dbo].[synTable]
GO

/****** Object:  Synonym [dbo].[synTable]    Script Date: 10/15/2015 9:45:01 AM ******/
CREATE SYNONYM [dbo].[synTable] FOR [dbo].[tTheRealTable]
GO
3
Joshua Yeidel

Das hat für mich funktioniert:

use <Database>
EXEC  sp_change_users_login @Action='update_one', @UserNamePattern='<userLogin>',@LoginName='<userLogin>';

Das Problem kann visualisiert werden mit:

SELECT sid FROM sys.sysusers WHERE name = '<userLogin>'
SELECT sid FROM sys.syslogins WHERE name = '<userLogin>';
1
azak

SQL Logins werden auf Serverebene definiert und müssen sers in bestimmten Datenbanken zugeordnet werden.

Erweitern Sie im SSMS-Objekt-Explorer unter dem Server, den Sie ändern möchten, Sicherheit> Anmeldungen und doppelklicken Sie dann auf den entsprechenden Benutzer, um das Dialogfeld "Anmeldeeigenschaften" aufzurufen.

Wählen Sie Benutzerzuordnung, um alle Datenbanken auf dem Server anzuzeigen, für die eine vorhandene Zuordnung ausgewählt ist. Hier können Sie zusätzliche Datenbanken auswählen (und sicherstellen, dass Sie die Rollen in jeder Datenbank auswählen, zu denen der Benutzer gehören soll). Klicken Sie dann auf OK, um die Zuordnungen hinzuzufügen.

enter image description here

Diese Zuordnungen können nach einer Wiederherstellung oder einem ähnlichen Vorgang getrennt werden. In diesem Fall ist der Benutzer möglicherweise noch in der Datenbank vorhanden, aber keinem Login zugeordnet. In diesem Fall können Sie Folgendes ausführen, um die Anmeldung wiederherzustellen:

USE {database};
ALTER USER {user} WITH login = {login}

Sie können den Datenbankbenutzer auch löschen und im Dialogfeld "Anmeldeeigenschaften" neu erstellen. Es müssen jedoch alle Rollenmitgliedschaften oder andere Einstellungen neu erstellt werden.

1
Toby J

Der gleiche Fehler ist bei der Verwendung von Server Management Objects (SMO) in vb.net aufgetreten (ich bin sicher, dass es in C # derselbe ist).

Techie Joes Kommentar zum ersten Beitrag war eine nützliche Warnung, dass im Shared Hosting viele weitere Dinge passieren. Es hat etwas gedauert, bis Sie herausgefunden haben, aber der folgende Code zeigt, wie sehr der Zugriff auf SQL-Datenbanken sehr spezifisch sein muss. Der Fehler "Server Principal ..." schien immer dann aufzutreten, wenn die SMO-Aufrufe in der gemeinsam genutzten Hosting-Umgebung nicht genau festgelegt waren.

Dieser erste Codeabschnitt war gegen einen lokalen SQL Express-Server gerichtet und stützte sich auf die einfache Windows-Authentifizierung. Der in diesen Beispielen verwendete Code basiert auf dem SMO-Tutorial von Robert Kanasz in diesem Code Project-Website-Artikel :

  Dim conn2 = New ServerConnection()
  conn2.ServerInstance = "<local pc name>\SQLEXPRESS"
  Try
    Dim testConnection As New Server(conn2)
    Debug.WriteLine("Server: " + testConnection.Name)
    Debug.WriteLine("Edition: " + testConnection.Information.Edition)
    Debug.WriteLine(" ")

    For Each db2 As Database In testConnection.Databases
      Debug.Write(db2.Name & " - ")
      For Each fg As FileGroup In db2.FileGroups
        Debug.Write(fg.Name & " - ")
        For Each df As DataFile In fg.Files
          Debug.WriteLine(df.Name + " - " + df.FileName)
        Next
      Next
    Next
    conn2.Disconnect()

  Catch err As Exception
    Debug.WriteLine(err.Message)
  End Try

Der obige Code findet die .mdf-Dateien für jede Datenbank auf dem lokalen SQLEXPRESS-Server nur in Ordnung, da die Authentifizierung von Windows ausgeführt wird und sich auf alle Datenbanken erstreckt.

Im folgenden Code werden zwei Abschnitte für die MDF-Dateien durchlaufen. In diesem Fall funktioniert nur die erste Iteration, die nach einer Dateigruppe sucht, und findet nur eine einzelne Datei, da die Verbindung zu nur einer Datenbank in der gemeinsam genutzten Hosting-Umgebung besteht.

Die zweite Iteration, bei der es sich um eine Kopie der oben beschriebenen Iteration handelt, drosselt sofort, da die Art und Weise, in der sie geschrieben wurde, versucht, auf die erste Datenbank in der gemeinsam genutzten Umgebung zuzugreifen, die nicht die Benutzer-ID/das Kennwort ist Der SQL Server gibt einen Autorisierungsfehler in Form des Fehlers "Server Principal ..." zurück.

Dim sqlConnection1 As New System.Data.SqlClient.SqlConnection
sqlConnection1.ConnectionString = "connection string with User ID/Password to a specific database in a shared hosting system. This string will likely also include the Data Source and Initial Catalog parameters"
Dim conn1 As New ServerConnection(sqlConnection1)
Try
  Dim testConnection As New Server(conn1)
  Debug.WriteLine("Server: " + testConnection.Name)
  Debug.WriteLine("Edition: " + testConnection.Information.Edition)
  Debug.WriteLine(" ")

  Dim db2 = testConnection.Databases("the name of the database to which the User ID/Password in the connection string applies")
  For Each fg As FileGroup In db2.FileGroups
    Debug.Write(fg.Name & " - ")
    For Each df As DataFile In fg.Files
      Debug.WriteLine(df.Name + " - " + df.FileName)
    Next
  Next

  For Each db3 As Database In testConnection.Databases
    Debug.Write(db3.Name & " - ")
    For Each fg As FileGroup In db3.FileGroups
      Debug.Write(fg.Name & " - ")
      For Each df As DataFile In fg.Files
        Debug.WriteLine(df.Name + " - " + df.FileName)
      Next
    Next
  Next

  conn1.Disconnect()

Catch err As Exception
  Debug.WriteLine(err.Message)
End Try

In dieser zweiten Iterationsschleife wird der Code gut kompiliert. Da SMO jedoch nicht für den Zugriff auf die richtige Datenbank mit der genauen Syntax eingerichtet wurde, schlägt dieser Versuch fehl.

Als ich gerade SMO lernte, dachte ich, dass andere Neulinge es zu schätzen wissen würden, dass es auch eine einfachere Erklärung für diesen Fehler gibt - wir haben ihn nur falsch codiert.

0
Alan

Wir hatten den gleichen Fehler, obwohl der Benutzer dem Login ordnungsgemäß zugeordnet wurde. 

Nach dem Versuch, den Benutzer zu löschen, wurde festgestellt, dass einige SPs diesen Benutzer mit "Ausführen als" enthalten.

Das Problem wurde gelöst, indem diese SPs gelöscht wurden, der Benutzer gelöscht wurde, der mit der Anmeldung verknüpfte Benutzer neu erstellt und die SPs neu erstellt wurden.

Möglicherweise hat es sich in diesem Zustand durch das Wiederherstellen aus dem Backup (zu einer Zeit, als das zugehörige Login nicht vorhanden war) oder durch die Massenschemasynchronisierung (wenn möglich, ein SP mit Ausführen erstellen können, obwohl der Benutzer nicht vorhanden ist, in den Status versetzt Könnte auch auf diese Antwort bezogen sein.

0
crokusek