SQL Server Managment Studio

[Klaus R. (klara)]

Hallo,
Ich weiss, dies ist hier nicht das richtige Forum und bitte um 
Entschuldigung. Für einen Tipp wäre ich dankbar.
Kennt jemand ein passenderes Forum? Es geht eher um simple Probleme.
-------
Ich richte gerade auf einem neuen Rechner eine SQL Datenbank ein. Mit 
dem Microsoft SQL Server Managment Studio habe ich über ein Backup eine 
Datenbank wieder eingespielt.

Jetzt ist unter Security -> Logins der sa rot makiert.
Was bedeutet das?
Ich möchte das Passwort verändern. Das scheint auch zu funktionieren. 
Jedoch kann ich dann mit dem sa keinen neuen Connect zu Server 
ausführen.

Fehler bei der Anmeldung des Benutzers "sa"...
mfg Klaus

[Christian H. (ch-hunn)]

Melde dich mit dem Windows Benutzer, mit  welchem ursprünglich den SQL 
Server installiert wurde, im Management Studio an.
Vermutlich wurde die SQL Anmeldung bei der Installation deaktiviert

[Klaus R. (klara)]

Hallo Christian,
ja, ich habe mich als Windows Benutzer angemeldet. Sonst könnte ich ja 
gar nicht den sa editieren.
mfg klaus

[Harald K. (kirnbichler)]

Nach dem Einspielen eines Backups muss man die Benutzer reparieren. Aus 
irgendeinem schwachsinnigen Grund verknüpft der MSSQLServer die 
SQL-Benutzerkonten mit der jeweiligen Windows-Installation, so daß "sa" 
von Rechner X nicht das gleiche ist wie "sa" von Rechner Y, auch wenn 
das gleiche Passwort verwendet wird.

https://support.esri.com/en-us/knowledge-base/how-to-resynch-sql-server-logins-or-users-after-restori-000008079


Diesen Schwachsinn betreiben andere SQL-Server nicht.

[Klaus R. (klara)]

Hallo Harald,
ich habe auf jeden neuen Rechner SQLEXPRESS zunächst installiert und 
dann mit dem Mikrosoft SQL Server Management Studio zwei Backups 
eingespielt.

Bei der letzten Installation auf meinem Hauptrechner waren da nur die 
beiden Anmeldungen ##MS_Policy... mit einem roten Kreuz markiert. 
Genauso wie im beigefügten Bild.

Auf dem neuen Rechner ist jetzt die Anmeldung für sa ebenfalls mit einem 
roten Kreuz markiert. Das ist neu.

Nach einem erneuten start des SSMS ist die rote Markierung beim sa 
verschwunden. Ich kann nach wie vor ein neues Passwort eingeben, kann 
mich aber trotzdem nich damit einloggen. Die Fehlermeldung.

TITLE: Connect to Server
------------------------------

Cannot connect to JAMES-4\SQLEXPRESS.

------------------------------
ADDITIONAL INFORMATION:

A connection was successfully established with the server, but then an 
error occurred during the login process. (provider: Shared Memory 
Provider, error: 0 - Kein Prozess ist am anderen Ende der Pipe.) 
(Microsoft SQL Server, Error: 233)

For help, click: 
https://docs.microsoft.com/sql/relational-databases/errors-events/mssqlserver-233-database-engine-error

------------------------------

Kein Prozess ist am anderen Ende der Pipe

------------------------------
BUTTONS:

OK
------------------------------

Die Meldung eines fehlerhaften Logins sieht anders aus.
"Fehlermeldung bei der Anmeldung für den Benutzer saa ..."

Was nun?
mfg Klaus

[Klaus R. (klara)]

Hallo Harald,
man sollte doch den Help-Link sich mal anschauen.

------
Windows-Fehler 233: Kein Prozess befindet sich am anderen Ende der Pipe

Die vollständige Meldung lautet:

    Eine Verbindung mit dem Server wurde erfolgreich hergestellt, aber 
dann ist während des Anmeldevorgangs ein Fehler aufgetreten. (Anbieter: 
Shared Memory Provider, Fehler: 0 – Kein Prozess befindet sich am 
anderen Ende der Pipe.) (Microsoft SQL Server, Fehler: 233)

Diese Meldung bedeutet, dass SQL Server nicht auf dem Shared Memory- 
oder Named Pipes-Protokoll lauscht.
------

Jetzt muß ich nur noch herausfinden wo man das einstellt.

Ich habe was gefunden.
https://portal.marcos-software.de/support/solutions/articles/26000031654-wie-aktiviere-ich-das-protokoll-named-pipes-innerhalb-meiner-sql-instanz-

Shared Memory war aktiv, Named Pipes habe ich aktiviert. Die Server 
wurden neu gestartet.

Jetzt habe ich wieder "Fehler bei der Anmeldung 'sa'. ... Error 18456)
Ich werde nun mal einen einfachen Anwender einrichten.
mfg Klaus

[C-hater (c-hater)]

Klaus R. schrieb:

> Ich richte gerade auf einem neuen Rechner eine SQL Datenbank ein. Mit
> dem Microsoft SQL Server Managment Studio habe ich über ein Backup eine
> Datenbank wieder eingespielt.

Damit hast du zwar die Datenbank eingespielt, aber deren Benutzer sind 
nicht mit irgendwelchen Logins des existierenden Servers verknüpft unter 
der sie jetzt laufen.

Echten Zugriff auf diese Datenbank bekommen also nur Logins, die die 
SQL-Server-Rolle Sysadmin haben. Andere User können die DB maximal och 
als solche sehen und irgendwelche sicherheitstechnisch unwichtigen 
Trivialitäten darin.

> Jetzt ist unter Security -> Logins der sa rot makiert.
> Was bedeutet das?

Vermutlich: Der Server ist nicht dafür konfiguriert, überhaupt Logins 
mit SQL-Accounts zu akzeptieren. Wenn das so ist, wird es auch keinen 
sa-Login geben und dementsprechend nix, was mit einen in der DB 
eventuell existierenden sa-Nutzer verknüpft sein (oder werden) könnte.


Also: dir ist offensichtlich nicht klar, das es erstens eine Trennung 
zwischen DB-Benutzern und Server-Logins gibt. Und zweitens ist dir nicht 
klar, das es zwei verschiedene Arten von Logins gibt. Dieses ganze 
Unwissen führt jetzt zu deinem Problem.

Die Lösung ist:

Erstens muß du dich entscheiden, ob du dem Server auch SQL-Logins 
erlauben willst. Das ist nicht unbedingt nötig, um vollen Zugriff auf 
die importierte DB zu erlangen. Kann man also machen, muß man aber 
nicht. Man muß nur wissen: ohne Aktivierung dieses Feature gibt es 
überhaupt keinen sa-Login!

Ob du den also nun einrichtest oder nicht, weiter geht es so:

Melde dich beim Server mit einem Login an, der die Sysadmin-Rolle 
besitzt. Das ist mindestens der Windows-User, der den Server 
eingerichtet hat. Ggf. halt aber auch der sa-User, wenn der Server 
SQL-Logins erlaubt.

Damit hast du dann vollen Zugriff auch auf die importierte Datenbank, 
insbesondere siehst du alle für diese konfigurierten Benutzer. Die 
siehst du nicht im "Security/Sicherheit"-"Unterordner" des Servers, 
sondern im gleichnamigen "Unterordner" der Datenbank.

Alles, was du nun noch machen musst: diese Benutzer sinnvoll mit 
existierenden Server-Logins verknüpfen. Oder wahlweise auch: 
entsprechende Server-Logins erschaffen und die DB-Benutzer dann mit 
diesen verknüpfen.

Dazu gibt es dann verschiedene Möglichkeiten, von denen die 
naheliegendste allerdings nicht funktioniert. Nämlich: man geht von 
den Server-Logins aus und versucht, die mit existierenden DB-Usern zu 
verknüpfen. Das klappt aber oft nicht. Das bekloppte Studio sieht hier 
nur den Fall vor, dass der Login mit einem noch zu erstellenden DB-User 
verknüpft wird und scheitert deshalb, wenn es einen gleichnamigen 
bereits in der DB gibt...

Da muß man dann auf SQL-Ebene aktiv werden. Einfach einen Editor für die 
betreffen DB öffnen (wichtig: falls das Studio den Editor für "master" 
oder irgendeine andere DB öffnet, muß man hier nachbessern) und dann 
mittels folgender simplen Zeile einen User mit einem Login verknüpfen:

alter user <DB-User-Name> with login <Server-Login-Name>;

Das macht man dann für jeden User, der in der DB existiert und der Drops 
ist gelutscht.

[Klaus R. (klara)]

C-hater schrieb:
> Vermutlich: Der Server ist nicht dafür konfiguriert, überhaupt Logins
> mit SQL-Accounts zu akzeptieren. Wenn das so ist, wird es auch keinen
> sa-Login geben und dementsprechend nix, was mit einen in der DB
> eventuell existierenden sa-Nutzer verknüpft sein (oder werden) könnte.

Jawoll! Ich habe es vor ein paar Minuten herausgefunden.

Auf meinem Hauptrechner läuft ja alles wie gewünscht. Ich hatte zunächst 
über den SQL Server Konfigurations-Manager alt und neu verglichen. Dort 
stimmte alles überein. Zumindest zuletzt.

An Einstellungen über Microsoft SQL Server Management Studio dachte ich 
eigentlich gar nicht mehr. Der Konfigurations-Manager war beim letzen 
mal vor 3 Jahren da wichtiger. OK.

Ich habe dann doch die SQLEXPRESS Eigenschaften verglichen. Unter 
SICHERHEIT fiel es mir sofort auf. Die Serverauthentifizierung stand auf 
Windows-Authentifizierung.

Nach der Umstellung auf SQL Server- und Windows-Authentifizierung war 
alles in Ordnung.

Bei der Datenbankinstallation habe ich sicher diesen Punkt übersehen. 
Dabei werden auch jede Menge Fragen gestellt die mich gar nicht 
interessieren. Eine Bitte an Microsoft, geht es nicht auch etwas 
simpler?

Aber Danke für Deine Unterstützung. Du hast den Punkt ja schon genau 
angesprochen.
mfg Klaus

[C-hater (c-hater)]

Klaus R. schrieb:

> Bei der Datenbankinstallation habe ich sicher diesen Punkt übersehen.

Jepp.

> Dabei werden auch jede Menge Fragen gestellt die mich gar nicht
> interessieren. Eine Bitte an Microsoft, geht es nicht auch etwas
> simpler?

Sicherheit läuft leider schon immer ziemlich entgegen "Einfachheit" und 
"Komfort".

Das ist nicht die Schuld von Microsoft. Die gehen halt (zu Recht!) davon 
aus, dass der Betreiber eines Datenbankservers zumindest einen groben 
Überblick über die sicherheitsrelevanten Aspekte der Sache hat.

Und das ist bei allen konkurrierenden Datenbank-Serversystemen kein 
bissel anders.

Und bei denen (wie auch bei MS) ist i.A. zumindest dies sehr gut 
dokumentiert. Man muß die Dokumentation halt nur lesen. Hast du 
offensichtlich nicht getan...

[Klaus R. (klara)]

C-hater schrieb:
> Man muß die Dokumentation halt nur lesen. Hast du
> offensichtlich nicht getan...

Wenn man was wissen will ist das wie die Suche im Heuhaufen, zumindest 
manchmal.

Beruflich hatte ich früher mal mit Informix auf UNIX-Rechnern zu tun. 
Ich war auch mal in Dresden auf einem Oracle Lehrgang. Dann kam ich 
privat auf MYSQL bis dann endlich MSSQL frei zur Verfügung stand. Das 
ist jetzt gut 20 Jahre her. Allerdings habe ich dieser Zeit nur 4-6 
Neuinstallationen gehabt. Die letzte ist drei Jahre her. Und jetzt hatte 
ich beim Punkt "SQL Server- und Windows-Authentifizierung" wohl etwas 
geschlafen. Geht doch eigentlich. Na ja, nochmals Danke.
mfg Klaus