Username und passwort für MSSQL

[bernhard_LA]

Kann ich für meinen SQL Server eigentlich nur ein Passwort für mein Windows login vergeben - ich kann keinen ganze neuen Benutzer am Server anlegen und dann für diesen Benutzer ein Passwort setzen ?

[Schokohase]

Die Frage ist etwas diffus.

MSSQL hat eine integrierte Benutzerverwaltung und braucht dann zum authentifizieren den Namen und das Kennwort, oder delegiert diese Authentifzierung an das Betriebssystem (Windows) und braucht dann lediglich den Windows-Anmeldenamen.

Windows-Konto und dazu ein spezielles Kennwort am MSSQL => Nein.

[TigerLilly]

Der MSSQL Server kennt zwei Arten der Anmeldung: Windows only + Mixed Mode. Bei ersterem können sich NUR Windows Benutzer anmelden, bei zweiterem können sich zusätzlich andere Benutzer über Username+Password anmelden. Das wird beim Setup des Servers entschieden, kann nachträglich aber auch noch geändert werden. Windows Benutzer müssen sich nicht extra anmelden, sondern wird der Benutzer durchgereicht.

Siehe auch:
https://docs.microsoft.com/en-us/sql...ql-server-2017
https://docs.microsoft.com/en-us/sql...ql-server-2017

[jobo]

Vielleicht noch netter Weise die Info, dass die verschiedenen Anmeldearten sich auch in verschiedenen Verbindungsparametern zur Steuerung niederschlagen und (naheliegend)auch im Falle der Nutzung des OS users keine account Parameter benötigen.

[bernhard_LA]

passt, die Idee war einfach einen ganz neuen User zu definieren am Server

UserName=MeineDatenbankAnwendung
Password=GanzandersalsWindowsPasswort

Und dann diese Daten im ConnectString übergeben
die Idee läßt sich aber nicht umsetzen am MSSQL Server ....

[Delphi.Narium]

Wieso nicht:

Man muss halt 'nen Datenbanknutzer MeineDatenbankAnwendung anlegen, ihm das Passwort GanzandersalsWindowsPasswort verpassen und diese Anmeldedaten dann beim Verbindunsgaufbau nutzen.

Wäre mir neu, wenn das nicht ginge.

[p80286]

Zitat:

Zitat von bernhard_LA (Beitrag 1405514)

passt, die Idee war einfach einen ganz neuen User zu definieren am Server

Was ist "am Server"? Einen DB-User einrichten, hat nichts mi dem OS zu tun.
(Auch wenn MS das gerne vermengt)

Gruß
K-H

[TigerLilly]

@bernhard_LA: Doch, das geht schon so, aber NUR wenn der Server entsprechend konfiguriert ist, also diese Form der Anmeldung auch zulässt. Und natürlich schaut der Connect String ein bissl anders aus. Und natürlich muss es diesen Login am DB Server auch geben.

Aber wie gesagt, das ist NICHT die Windows Anmeldung!

[jobo]

Generell:
Ist die Anwendung produktspezifisch an SQL Server gebunden, kann man am ehesten mit OS Usern / Trusted Login arbeiten. Ansonsten gar nicht erst mit Trusted Login loslegen, sondern standardmäßig mit SQL user.*

Wann/Was
Datenhaltung (plus ggF. Logik) im SQL Server per SQL User (nenne ich immer Application Owner)
Das ist nicht zu verwechseln mit irgendwelchen Systemaccounts.
Eine Anwendung sollte DB seitig m.E. niemals im Kontext eines Standard Admin Kontos laufen.
Der Nutzerzugriff durch die Anwender kann dann per Trusted Login erfolgen**, besonders wenn eh im Windows Domänen Kontext gearbeitet wird. Auch diese Nutzer können mit unterschiedlichen Rechten/Rollen verwendet werden, idealerweise weniger Rechte als der Application Owner.
Gibt es keine Windows Domäne, entfällt Nutzen und Einsatzmöglichkeit des Trusted Logins mehr oder weniger.
Wird Trusted Login eingesetzt, empfiehlt sich allerdings dann auf Domänenebene, entsprechende Rechtegruppen zu definieren, Projekt spezifisch oder fachlich, damit nicht jede Putzkraft einloggen kann. (Obwohl, die sind ja meist extern heutzutage)

* Oder auf allgemein verfügbare singlesignon Verfahren setzen
**Das ist wirklich bequem, bedeutet allerdings auch, dass eine fehlende Abmeldung in der Kaffepause von jedem genutzt werden kann, an der Anwendung rumzuspielen.

[jobo]

Zitat:

Zitat von TigerLilly (Beitrag 1405520)

Doch, das geht schon so, aber NUR

Genau, ich denke MS macht es da besonders leicht, sich in "beiden Welten" das auszusuchen, was man braucht.

[MichaelT]

Das ist SQL Server Authentication, ist konfigurierbar.

Ist der User den du so anlegen willst 'der' User/Login unter dem die Verbindung zur Datenbank hergestellt wird egal welcher Anwendungsuser einsteigt? Anwendungsuser würden ihrerseits in der Anwendung definiert und wären aber keine DB-Logins/User. Ala Linux mit dem klassischen Anwendungsuser ... (bpsw. postgres).

Beide Varianten haben Vor- resp. Nachteile mal von der Security abgesehen. Wenn du monitorst siehst du sofort wessen Statements just diese Moment laufen und wieviele Ressourcen die brauchen usw...

Zitat:

Zitat von bernhard_LA (Beitrag 1405514)

passt, die Idee war einfach einen ganz neuen User zu definieren am Server

UserName=MeineDatenbankAnwendung
Password=GanzandersalsWindowsPasswort

Und dann diese Daten im ConnectString übergeben
die Idee läßt sich aber nicht umsetzen am MSSQL Server ....

[bernhard_LA]

unter Windows scheint es jetzt mit username und passwort zu klappen, wobei halt username mein Benutzername auf diesem Rechner ist.

Langfristig ( also bis nächste Woche :shock: ) benötige ich aber auch die Option mich mit einer LINUX variante meiner APP auf einem LINUX Installation von MSSQL ( https://docs.microsoft.com/de-de/sql...ver-linux-2017 .... ) einzuloggen

[Schokohase]

Ich verstehe dein Problem nicht und du antwortest irgendwie auch nicht auf Fragen.

Was habe ich mal eben gemacht:

1. Auf einem Ubuntu-Docker-System per
   
   Code:

   docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=Geheim1234' -p 1433:1433 -d microsoft/mssql-server-linux:latest

   einen MSSQL Server installiert und gestartet
2. Mit Delphi per
   Delphi-Quellcode:

   TADOConnection

   und dem ConnectionString
   Code:

   Provider=SQLOLEDB.1;Password=Geheim1234;Persist Security Info=True;User ID=sa;Data Source=myubuntu

   eine Verbindung aufgebaut

Ja, läuft einfach so.

Dann einen neuen Benutzer angelegt per

Code:

CREATE LOGIN [ich] WITH PASSWORD = 'Geheim4321'

und auch diese Anmeldung

Code:

Provider=SQLOLEDB.1;Password=Geheim4321;Persist Security Info=True;User ID=ich;Data Source=myubuntu

funtkioniert einwandfrei.

BTW: Die Windows-Benutzerkonten heißen werden sa noch ich, es sind somit also Konten die nur vom SQL-Server verwaltet werden.