12
MSSQL Server : Zugriffsrechte auf Datenbank
Hallo zusammen !
Ich habe ein Problem der unwirklichen Art. Ich habe auf 2 Servern A und B je eine MSSQL-Serverinstanz gehabt:
Server A : MSSQL 2000
[Datenbank], hatte 3 drei individuell angelegte Benutzer: writer, reader, php-user
User writer, reader, php-user sind in Rolle "Sicherheit" mit Zugriff auf [Datenbankname] angelegt (Checkboxen)
User writer, reader, php-user sind auf Datenbankebene / Berechtigungen als "berechtigt zum Verbinden sichtbar.
Server B : MSSQL 2008R2
Die Rolle Sicherheit hat dieselben 3 drei individuell angelegten Benutzer: writer, reader, php-user, Passwörter identisch.
Das Problem: Server A kolabierte mit Festplattenschaden. Es gelang aber, auf Server B die [Datenbank] wieder hochzuziehen. Der SA ist derselbe => Zugriff per SA möglich.
=> wir arbeiten nun auf Server B : MSSQL 2008R2
Es sollen aber auch die besagten Benutzer writer, reader, php-user zugreifen können ! => also rein in die "Rolle Sicherheit" und dort bei den Usern User writer, reader, php-user die Checkboxen für den Zugriff auf [Datenbank] anchecken und speichern !
Eigentlich ganz einfach, aber denkste ! Beim Versuch, diese Änderungen zu speichern erscheint ein Fehler mit der Meldung, die Änderung sei nicht möglich, da der jeweilige Benutzer bereits Zugriff auf die Datenbank habe.
... was korrekt ist, aber bloss auf Ebene der Datenbank-Eigenschaften. In der Rolle Sicherheit -und diese wird beim Zugriff abgefragt eben nicht. Ausschlaggebend ist eben das Setzen des Hakens in der Siicherheit und genau das wird verweigert.
Jetzt habe ich natürlich versucht, den als bereits vorhanden angemeckerten Eintrag des Benutzers auf Datenbankebene zu löschen, damit ihn die Rolle Sicherheit wieder neu schreiben kann. Aber das geht auch nicht, weil eine Bearbeitung dieser Datensätze (angezeigte Benutzer auf Datenbankeben) anscheinend nicht vorgesehen ist.
Was nun ? Es muss ja einen Weg (SQL-Kommando ?) geben, diese berechtigten Benutzer da rauszuhauen, damit sie von der Sicherheit wieder zugeweisen werden können.
Vielen Dank im Voraus für Eure Hilfe !
Gruss Walter
Ich habe ein Problem der unwirklichen Art. Ich habe auf 2 Servern A und B je eine MSSQL-Serverinstanz gehabt:
Server A : MSSQL 2000
[Datenbank], hatte 3 drei individuell angelegte Benutzer: writer, reader, php-user
User writer, reader, php-user sind in Rolle "Sicherheit" mit Zugriff auf [Datenbankname] angelegt (Checkboxen)
User writer, reader, php-user sind auf Datenbankebene / Berechtigungen als "berechtigt zum Verbinden sichtbar.
Server B : MSSQL 2008R2
Die Rolle Sicherheit hat dieselben 3 drei individuell angelegten Benutzer: writer, reader, php-user, Passwörter identisch.
Das Problem: Server A kolabierte mit Festplattenschaden. Es gelang aber, auf Server B die [Datenbank] wieder hochzuziehen. Der SA ist derselbe => Zugriff per SA möglich.
=> wir arbeiten nun auf Server B : MSSQL 2008R2
Es sollen aber auch die besagten Benutzer writer, reader, php-user zugreifen können ! => also rein in die "Rolle Sicherheit" und dort bei den Usern User writer, reader, php-user die Checkboxen für den Zugriff auf [Datenbank] anchecken und speichern !
Eigentlich ganz einfach, aber denkste ! Beim Versuch, diese Änderungen zu speichern erscheint ein Fehler mit der Meldung, die Änderung sei nicht möglich, da der jeweilige Benutzer bereits Zugriff auf die Datenbank habe.
... was korrekt ist, aber bloss auf Ebene der Datenbank-Eigenschaften. In der Rolle Sicherheit -und diese wird beim Zugriff abgefragt eben nicht. Ausschlaggebend ist eben das Setzen des Hakens in der Siicherheit und genau das wird verweigert.
Jetzt habe ich natürlich versucht, den als bereits vorhanden angemeckerten Eintrag des Benutzers auf Datenbankebene zu löschen, damit ihn die Rolle Sicherheit wieder neu schreiben kann. Aber das geht auch nicht, weil eine Bearbeitung dieser Datensätze (angezeigte Benutzer auf Datenbankeben) anscheinend nicht vorgesehen ist.
Was nun ? Es muss ja einen Weg (SQL-Kommando ?) geben, diese berechtigten Benutzer da rauszuhauen, damit sie von der Sicherheit wieder zugeweisen werden können.
Vielen Dank im Voraus für Eure Hilfe !
Gruss Walter
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7243300001
Url: https://administrator.de/contentid/7243300001
Ausgedruckt am: 24.11.2024 um 10:11 Uhr
12 Kommentare
Neuester Kommentar
Hi
Ihr migriert jetzt also von Urzeit auf Steinzeit...
Das ist immer so wenn man eine DB woanders einhängt.
Mit
https://www.sqlservergeeks.com/sql-server-error-15023-user-already-exist ...
solltest du das wieder Gerade biegen können
Ihr migriert jetzt also von Urzeit auf Steinzeit...
Das ist immer so wenn man eine DB woanders einhängt.
Mit
https://www.sqlservergeeks.com/sql-server-error-15023-user-already-exist ...
solltest du das wieder Gerade biegen können
Hi Seastorm !
Die Urzeit hat damit zu tun, dass die Systementwicklung in 2000 begonnen wurde und da einiges serverseitig in diesen "Workflow-Steps" programmiert wurde, die man nicht so einfach in die Zukunft migrieren kann, weil sich bei den nachfolgenden Versionen des SQL Server die komplette Vorgehensweise geändert hat.
Und Versuche haben ergeben, dass die Datenbankanwendung sowohl lesend als auch schreibend keineswegs schneller wird, wenn ich die DB auf SQL-Server 2919 laufen lasse zum Beispiel. Bloss der Overhead, der da an sys-Tabellen daher kommt, ist überwältigend. Und völlig nutzlos, wenn man nicht Microsoft heisst.
Vielen Dank für Deine Hilfe ! Ich werde sehen was ich hinkriege.
Da der Fehler bzw. das Problem ja bekannt ist, hätte Microsoft ja auch reagieren können. Dieser Fehlerzustand wäre nicht notwendig, wenn von der Rolle Sicherheit aus die entsprechenden bereits vorhandenen Einträge einfach mit den richtigen Schlüsseln überschrieben würden.
Gruss Walter
Die Urzeit hat damit zu tun, dass die Systementwicklung in 2000 begonnen wurde und da einiges serverseitig in diesen "Workflow-Steps" programmiert wurde, die man nicht so einfach in die Zukunft migrieren kann, weil sich bei den nachfolgenden Versionen des SQL Server die komplette Vorgehensweise geändert hat.
Und Versuche haben ergeben, dass die Datenbankanwendung sowohl lesend als auch schreibend keineswegs schneller wird, wenn ich die DB auf SQL-Server 2919 laufen lasse zum Beispiel. Bloss der Overhead, der da an sys-Tabellen daher kommt, ist überwältigend. Und völlig nutzlos, wenn man nicht Microsoft heisst.
Vielen Dank für Deine Hilfe ! Ich werde sehen was ich hinkriege.
Da der Fehler bzw. das Problem ja bekannt ist, hätte Microsoft ja auch reagieren können. Dieser Fehlerzustand wäre nicht notwendig, wenn von der Rolle Sicherheit aus die entsprechenden bereits vorhandenen Einträge einfach mit den richtigen Schlüsseln überschrieben würden.
Gruss Walter
Hi Seastorm !
Nachdem ich mir das angesehen habe:
1) Ich weiss ja, wie meine 3 User heissen, das muss ich nicht erst abfragen.
2) => ich müsste also z.B. nur die neue Methode ALTER USER (Query 2) als Code ausführen:
-- Query 1: sp_change_users_login 'Update_one',<username>.<loginname>
-- will be deprecated in future
EXECUTE sp_change_users_login 'Update_one','login1','login1'
-- Query 2: the new way
ALTER USER login1 WITH LOGIN = login1
Was mich stört: an keiner Stelle dieses Codes "ALTER USER login1 WITH LOGIN = login1" muss ich die Datenbank, die gemeint ist, angeben oder etwa einen Instanznamen.
Was sagst Du dazu ?
Gruss Walter
Nachdem ich mir das angesehen habe:
1) Ich weiss ja, wie meine 3 User heissen, das muss ich nicht erst abfragen.
2) => ich müsste also z.B. nur die neue Methode ALTER USER (Query 2) als Code ausführen:
-- Query 1: sp_change_users_login 'Update_one',<username>.<loginname>
-- will be deprecated in future
EXECUTE sp_change_users_login 'Update_one','login1','login1'
-- Query 2: the new way
ALTER USER login1 WITH LOGIN = login1
Was mich stört: an keiner Stelle dieses Codes "ALTER USER login1 WITH LOGIN = login1" muss ich die Datenbank, die gemeint ist, angeben oder etwa einen Instanznamen.
Was sagst Du dazu ?
Gruss Walter
Den Befehl setzt du ja gegen die entsprechende DB ab, da es ja um deren Einträge geht.
User existieren ja ohne den Isolation Mode immer am Server und an der DB.
User existieren ja ohne den Isolation Mode immer am Server und an der DB.
Ok, ich denke ich habe verstanden: ich setze mich in der Management Console -den Cursor- auf die DB und führe den Code aus.
Jain... Im SSMS muss oben Links die richtige DB ausgewählt sein für das query.
Oder du setzt ein
Use DeineDB
Als erstes ein
Oder du setzt ein
Use DeineDB
Als erstes ein
Zitat von @MeinGottWalter:
Da der Fehler bzw. das Problem ja bekannt ist, hätte Microsoft ja auch reagieren können. Dieser Fehlerzustand wäre nicht notwendig, wenn von der Rolle Sicherheit aus die entsprechenden bereits vorhandenen Einträge einfach mit den richtigen Schlüsseln überschrieben würden.
Ja und nein.Da der Fehler bzw. das Problem ja bekannt ist, hätte Microsoft ja auch reagieren können. Dieser Fehlerzustand wäre nicht notwendig, wenn von der Rolle Sicherheit aus die entsprechenden bereits vorhandenen Einträge einfach mit den richtigen Schlüsseln überschrieben würden.
Das ist kein Fehler sondern gewollt.
Aber das Problem ist lange bekannt und seit 2012 gibt es den Containment Mode.
(Nicht Isolation wie ich ihn oben genannte hatte. Bekomme den richtigen Begriff einfach nicht in meinen Schädel...)
Damit existieren User dann nur noch in der DB und können beim migrieren auf einen anderen Server einfach mitgenommen werden.
Und es ist außerdem sicherer.
Hallo SeaStorm ! Ich amüsiere mich immer noch über Deine Urzeit->Steinzeit-Bemerkung ! .-)))
Aber das hat natürlich einen Hintergrund: der alte Enterprise Manager (2000) hatte wie gesagt diesen "Workflowmanager", der es ermöglichte, in einer vorgegebenen Sequenz einfache Schritte auszuführen ... was wir dazu benutzen, Anfügeanfragen auszuführen. Aufgabe war, täglich automatisch DS von einer DB2 auf einer AS400/iSeries in die SQLServer-DB zu importieren oder upzudaten und schon damit nicht alle 15 Steps oder Packages (ich glaube so nannte sich das, kann bloss gerade wegen der Serverhavarie nicht kucken) gleichzeitig ausgeführt werden, haben wir diese Schritte schön nacheinander ablaufen lassen.
Dann kam irgendwann SQL Server 2008R2 auf den Markt. Natürlich habe ich nach dem entsprechenden Nachfolger dieses "Workflowmanagers" gekuckt, aber anscheinend ist MS von dieser Möglichkeit weggegangen ... was schade ist, denn das war sehr praktisch .. mit grafischer Oberfläche sogar. Was ich als "Nachfolger" gefunden habe, klang sehr kompliziert. So haben wir es gelassen und das alte System lief ja treu und brav.
Kennst Du den aktuellen stand für solche Aufgaben ?
Gruss Walter
Aber das hat natürlich einen Hintergrund: der alte Enterprise Manager (2000) hatte wie gesagt diesen "Workflowmanager", der es ermöglichte, in einer vorgegebenen Sequenz einfache Schritte auszuführen ... was wir dazu benutzen, Anfügeanfragen auszuführen. Aufgabe war, täglich automatisch DS von einer DB2 auf einer AS400/iSeries in die SQLServer-DB zu importieren oder upzudaten und schon damit nicht alle 15 Steps oder Packages (ich glaube so nannte sich das, kann bloss gerade wegen der Serverhavarie nicht kucken) gleichzeitig ausgeführt werden, haben wir diese Schritte schön nacheinander ablaufen lassen.
Dann kam irgendwann SQL Server 2008R2 auf den Markt. Natürlich habe ich nach dem entsprechenden Nachfolger dieses "Workflowmanagers" gekuckt, aber anscheinend ist MS von dieser Möglichkeit weggegangen ... was schade ist, denn das war sehr praktisch .. mit grafischer Oberfläche sogar. Was ich als "Nachfolger" gefunden habe, klang sehr kompliziert. So haben wir es gelassen und das alte System lief ja treu und brav.
Kennst Du den aktuellen stand für solche Aufgaben ?
Gruss Walter
Du redest von DTS?
Das ist später in SSIS integriert bzw damit ersetzt worden.
IMHO gab es da auch converter die einem die Migration leicht bis automatisch gemacht haben
Update:
http://www.sqlcircuit.com/2017/12/sql-server-dts-to-ssis-migration.html ...
Das ist später in SSIS integriert bzw damit ersetzt worden.
IMHO gab es da auch converter die einem die Migration leicht bis automatisch gemacht haben
Update:
http://www.sqlcircuit.com/2017/12/sql-server-dts-to-ssis-migration.html ...
Ja, genau ! DTS-Pakete hieß das ! Aha ! Kucke ich mir an !
Übrigens: ich kann Erfolg melden !:
Der User "writer" ist jetzt in der Sicherheit für diese DB eingetragen.
Allerdings wurde auch das "Standard-Schema" "writer" gesetzt.
Ist das ok so ? Wir haben an dieser Stelle immer "dbo" angegeben ...ohne wirklich zu wissen, was wir damit sagen.
Gruss Walter
Übrigens: ich kann Erfolg melden !:
Der User "writer" ist jetzt in der Sicherheit für diese DB eingetragen.
Allerdings wurde auch das "Standard-Schema" "writer" gesetzt.
Ist das ok so ? Wir haben an dieser Stelle immer "dbo" angegeben ...ohne wirklich zu wissen, was wir damit sagen.
Gruss Walter
Kommt drauf an wie das Programm arbeitet. Aber das kannst du ja manuell einfach auf dbo ändern um Problemen vorzubeugen
Mach ich !
Danke Dir !!!
Gruss Walter
PS: ich weiss schon, warum ich den Namen MeinGottWalter gewählt habe. Meist liegen Dinge an, die im Grunde nicht sein müssten.
Danke Dir !!!
Gruss Walter
PS: ich weiss schon, warum ich den Namen MeinGottWalter gewählt habe. Meist liegen Dinge an, die im Grunde nicht sein müssten.
