MSSQL - Zugriff bei integrierter Sicherheit testen

[DeddyH]

Ich habe hier einen Dienst, der ggf. auf eine MSSQL-Datenbank mit integrierter Sicherheit zugreifen soll. Da das Systemkonto nicht unbedingt zugriffsberechtigt ist, möchte ich eine Option anbieten, ihn unter einem einzugebenden Benutzerkonto laufen zu lassen. Nun suche ich eine Möglichkeit des Testzugriffs auf die DB mit dem angegebenen Benutzerkonto. Hat jemand eine Idee, wie man das mit vertretbarem Aufwand realisieren könnte? Ein externes Programm unter dem angegebenen Konto zu starten, das dann versucht, auf die DB zuzugreifen und das Ergebnis dann irgendwie wieder an das Hauptprogramm zurückmeldet ist mir momentan zuviel Aufwand, gibt es da nichts simpleres?

[Der schöne Günther]

Ich habe aktuell lustigerweise genau das gleiche (MS-SQL 2008 + FireDAC), kenne mich aber nicht wirklich aus. "Integrierte Sicherheit" ist Active Directory-Integration? Und der Nutzer unter dem du entwickelst hat nicht zwangsläufig die Rechte unter welcher die Anwendung später läuft?

Der SQL-Server kann Active Directory-Konten plus zusätzliche SQL-Server-Accounts gleichzeitig. Man musste erst auf Server-Ebene den Benutzer als "Anmeldung" hinzufügen und dann noch einmal zur Datenbank selbst hinzufügen. Bei mir war das notwendig weil mein PC zuhause nicht in der Domäne steckt, hier muss ich zum testen einen normalen Account mit Name und Passwort nehmen.

Richtig verstanden?

[DeddyH]

Im Prinzip schon. Mir geht es darum: ein Dienst wird ja standardmäßig unter dem lokalen Systemkonto gestartet. Damit er aber dann bei integrierter Sicherheit ("Windows-Authentifizierung") auch auf die DB zugreifen kann, muss man im DB-Server entweder die Berechtigung für NT-AUTHORITY/System (oder so ähnlich) einrichten, oder man startet den Dienst halt unter einem AD-Benutzer, der entsprechende Rechte besitzt. Wenn der Endbenutzer sich für Letzteres entscheidet, biete ich die Möglichkeit einer Eingabe für Namen und Kennwort des Accounts. Bevor ich das aber einfach stumpf übernehme, würde ich gern testhalber mit den eingegebenen Daten auf die DB zugreifen und bei Misserfolg eben eine entsprechende Meldung ausgeben. Und genau dafür fehlt mir der Ansatz.

[Der schöne Günther]

Das Connect() der TFdConnection wirft doch direkt eine Exception wenn er sich nicht verbinden kann? Das kann man ja sogar schon testen indem man sich einfach eine Connection auf ein Formular klatscht und Connected auf True setzt. In meinem Fall bekomme ich immer eine Exception mit sprechendem Namen (dem man dem Benutzer auch direkt anzeigen könnte) wenn es an der Authentifizierung scheitert. Wenn ich es beispielsweise von zu hause über meinen AD-Account versuche haut er mir das um die Ohren und meint "Der Computer ist nicht Teil der Domäne, geh weg!"

[TigerLilly]

Du kannst beim Dienst ja sagen, welches Konto er benutzen soll. Mach doch einfach ein Konto so, wie du es testen willst + starten den Dienst mit diesem Konto.

[DeddyH]

Ich möchte ja, bevor ich den Dienst starte, den Zugriff testen, im Kontext eines Setups und/oder Konfigurationsprogramms. Hier liegt das Hauptproblem. Ein Gedanke war, einfach ein kleines Testprogramm zu schreiben, welches mit übergebenen Daten (Datenbankserver, Name der Datenbank) einen Connect versucht und das Ergebnis zurückmeldet. Dieses Programm könnte ich aus dem Setup heraus unter dem angegebenen Benutzeraccount starten, aber schon das ist ja nicht ganz trivial, vor allem, wenn ich einen Passwort-Prompt vermeiden möchte.

[Papaschlumpf73]

Mit FD weiß ich es auch nicht; aber mit ADO geht es ganz einfach:

Delphi-Quellcode:

with TADOConnection.Create(self) do 
 try
 ConnectionString:='Provider=SQLOLEDB;Integrated Security=SSPI;OLE DB Services = -2;Initial Catalog=[Name der Datenbank];Data Source=[Name des SQLServers];Current Language=german';
 LoginPrompt:=false;
 Connected:=true;
 except {wenn es nicht geklappt hat} end;

[Papaschlumpf73]

Sorry, ADOConnection muss am Ende natürlich auch wieder freigegeben werden.

[Der schöne Günther]

Trivial sicher nicht, aber ich glaube das Auslagern in einen eigenen Prozess ist wahrscheinlich immer noch einfacher als zu versuchen, das in der Setup-Anwendung nachzubilden, mit all der AD-Authentifizierung und allem. Mit runas könnte man Windows wahrscheinlich auch die Eingabe des Passwortes übernehmen lassen, dann muss man sich damit auch nicht herumschlagen.

Und das Tool braucht ja keine Oberfläche, Benutzer und Kennwort könnte man ihm über Kommandozeile oder Umgebungsvariablen mitgeben und der Rückgabewert beim Beenden des Prozesses muss nur sagen "Ging" oder "ging nicht". Oder es loggt halt Dinge wie eine sprechende Fehlermeldung in eine Textdatei.

So ein kleines Testprogramm ließe sich vielleicht auch recyclen für den Fall der Kunde (oder sein Dienstleister) eines Tages was an Servernamen oder Berechtigungen ändert.

[Papaschlumpf73]

Ups, da habe ich gepennt. Mein Beispiel versucht es ja nur mit dem aktuell angemeldeten User.

[Papaschlumpf73]

Mir fällt jetzt aber noch etwas anderes ein: Als Kunde würde ich nur ungern meine Windows-Anmeldedaten irgendwo in eine Anwendung eintippen, die nicht Windows selbst ist. Hätte ich kein gutes Gefühl dabei. Ist aber Geschmackssache.

[DeddyH]

Das ist ja nur eine Option.

[Der schöne Günther]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1490944)

Als Kunde würde ich nur ungern meine Windows-Anmeldedaten irgendwo in eine Anwendung eintippen, die nicht Windows selbst ist. Hätte ich kein gutes Gefühl dabei.

Ich auch nicht. Deshalb mein Vorschlag mit dem runas, da sollte Windows selbst die Authentifizierung handeln.

[generic]

"Integrierte Sicherheit" sagt, dass das Konto verwendet wird, welches den Prozess ausführt.

Wenn etwas als Dienst läuft, läuft der Prozess im Dienstkonto. Dieses kannst du auch berechtigen in der DB.
Das alles geht auch ohne AD.
Evtl. musst du das Computerkonto berechtigen, wenn das o.g. Konto nicht geht. Computerkonten heißen so wie der PC mit angehängten $ -> MeinPC$
Du kannst den Dienst natürlich auch in jedem beliebigen Konto laufen lassen. Das kannst du in den Dienst-Einstellungen hinterlegen.

Ich als Benutzer freue mich über jedes Passwort welches ich nicht eingeben muss, schließlich bin ich schon in Windows angemeldet.

Das mit den Dienst und dem Systemkonto klingt erstmal komisch für mich.
Das Hauptprogramm läuft doch im Benutzerkonto. Welchen Grund hast du, dass du einen Services zwischen brauchst?
Wenn der Service notwendig ist, dann müsste der Service auf das Benutzerkonto eine Impersonation durchführen.
Alternativ müsste die Verbindung vom Hauptprogramm authentifiziert werden und die Berechtigungen müssen geprüft werden, um dann mit einen Servicekonto in die DB weiter zu gehen.

Ich erwähne dieses, weil schön ist, dass Benutzerkonto von vorne bis hinten zur Verfügung zu haben. Berechtigungen und Audits gehen dann erheblich leichter. Auch die Rechte sollte imho immer am zu sichernden Objekt liegen z.B. an der Datenbanktabelle, Sicht oder Prozedur. Dadurch können auch Daten einfacher gefiltert werden.

[DeddyH]

Zitat:

Zitat von generic (Beitrag 1490955)

Das mit den Dienst und dem Systemkonto klingt erstmal komisch für mich.
Das Hauptprogramm läuft doch im Benutzerkonto. Welchen Grund hast du, dass du einen Services zwischen brauchst?

Es ist genau andersherum. Ich habe einen Dienst, der als REST-Server fungiert und auf eine Datenbank zugreift. Damit er das kann, muss er aber auch wissen, wie er das machen muss. Dazu wird eine Konfigurationsdatei benutzt, die alle nötigen Angaben enthält, sensible Daten natürlich verschlüsselt. Wenn nun also MSSQL mit integrierter Sicherheit benutzt wird, muss SQL-Serverseitig der Zugriff für NTAUTHORITY\System auf die Datenbank zugelassen sein. Da viele unserer Kunden nicht halb so technikaffin sind, wie sie zu sein glauben, bekommen sie das aber nicht hin oder haben in der Compu****ild gelesen, dass das ein Sicherheitsrisiko ist, oder was weiß ich. Nun könnte man sagen "wenn Sie das nicht möchten, richten Sie eben den Dienst so ein, dass er unter einem berechtigten Benutzerkonto läuft". Von mindestens der Hälfte der Kunden kommt dann wieder "wieso ich, das muss doch automatisch gehen". Also möchte ich lediglich die Möglichkeit bieten, dass es eben automatisch geht, wenn man die Anmeldedaten gleich beim Setup hinterlegt. Der Dienst schaut im OnCreate in seiner Konfiguration nach entsprechenden Angaben und setzt dann ggf. StartServiceName und Password. Da ich aber jemand bin, der Benutzereingaben nach Möglichkeit auf Korrektheit prüft, wollte ich eben im Vorfeld testen, ob das dann auch so klappt. Und wie gesagt, niemand muss Anmeldedaten eingeben, wenn in meinem Setup der Haken bei "Windows-Authentifizierung" gesetzt ist, kann man Anmeldename und Kennwort auch leer lassen. In dem Fall muss man aber selbst dafür Sorge tragen, dass mein Dienst an die Daten kommt.

[jobo]

Also möchtest Du lediglich eine "manuelle" Anmeldung bei MSSQL per SQL Account über ein Testprogramm ausprobieren? (Weil alles andere sowieso geht)

[DeddyH]

So ist es. Mittlerweile habe ich es auch mit LogonUser und ImpersonateLoggedOnUser hinbekommen. Ich wechsle kurz den Account, schaue, ob damit die Anmeldung funktioniert und wechsle wieder zurück. Zumindest in meinen ersten Tests klappt das ganz hervorragend.

[Jumpy]

Wenn integrierte Sicherheit nicht aktiv ist, würdest du mit einem in der Anwendung bekannten/konfigurierbaren festen Konto arbeiten? Wie weiter oben schon gesagt wurde geht das trotz integrierter Sicherheit weiterhin. Wollte das nur noch mal erwähnt haben.

[DeddyH]

AFAIK aber nur, wenn die Serverauthentifizierung auch so eingestellt ist.