Program auf Netzlaufwerk ausführen

[jb_alvarado]

Hallo an Alle!
Ich habe folgende Situation:

Wir werden zukünftig eine Software zum Verwalten von Spenden verwenden. Diese Software soll von einem Windows Server aus per Netzlaufwerk freigegeben werden. Auf diesem Server (Windows Server 2019) läuft noch eine MS SQL Express (2019) Instanz die die Daten der Software bereitstellt.

Laut Anleitung des Softwareherstellers soll der Freigabeordner des Programms an Jeden Benutzer mit vollen Zugriffsrechten freigegeben werden.

Neben dem Windows 2019 Server betreiben wir noch einen 2016 Server, wo die AD drauf läuft. Darauf habe ich einige Gruppenrichtlinien eingerichtet, wie z.B. Netzlaufwerke und App Locker Regeln.

App Locker habe ich für die Clients so eingerichtet, dass es alles erlaubt, auf der Freigabe wo die Spendensoftware drauf liegt. Das habe ich auch getestet, es lassen sich Batchscripte und EXE Dateien ausführen.

Das komische ist jetzt aber, dass als normaler User nicht alles von der Software korrekt ausgeführt wird. Wenn ich das richtig einschätzte, funktionieren die Programme nicht, die auf die Datenbank zugreifen wollen. Wenn ich diese jedoch als Administrator ausführe, funktionieren sie.

Auch das testweise Kopieren des Programmordner auf ein lokales Laufwerk bringt nichts.

Support bekommen wir nicht von dem Hersteller, weil er sagt das ist eine Rechteproblem und das müssen wir erledigen.

Vielleicht noch zur Datenbank Instanz: die ist mit gemischter Autorisierung installiert, und es ist der sa Benutzer in der Spendensoftware hinterlegt, also es werden keine User aus der AD genommen.

Habt ihr vielleicht ein paar Ideen, woran das liegen kann?

 

[benneq]

Nur um noch mal sicherzugehen, die ominöse Spenden Software benutzt eine Datenbankanbindung. Und die Datenbank liegt auf demselben Server wie die Software?

Also gehe ich mal davon aus, dass einfach als Datenbank Verbindung "localhost" genutzt wurde.

Wenn nun ein Client über das Netzlaufwerk das Programm startet, dann wird das Programm lokal auf dem Client ausgeführt. Und aus Sicht des Clients ist "localhost" dann eben nicht mehr der Server.

Wenn ich diese jedoch als Administrator ausführe, funktionieren sie.

Als Administrator von welchem Rechner aus?

 

[Darkblade08]

Das hört sich für mich danach an, dass das Programm noch irgendwo anders ausgeführt wird. Wenn du das mit AppLocker nicht sauber konfiguriert wurde, passiert genau sowas.

Ich würde eh bei AppLocker lieber mit Zertifikaten arbeiten. Macht die Arbeit damit deutlich einfacher.

 

[jb_alvarado]

Nur um noch mal sicherzugehen, die ominöse Spenden Software benutzt eine Datenbankanbindung. Und die Datenbank liegt auf demselben Server wie die Software?

Also gehe ich mal davon aus, dass einfach als Datenbank Verbindung "localhost" genutzt wurde.

Wenn nun ein Client über das Netzlaufwerk das Programm startet, dann wird das Programm lokal auf dem Client ausgeführt. Und aus Sicht des Clients ist "localhost" dann eben nicht mehr der Server.

Ne, daran kann's nicht liegen, verbunden wird mit: Servername\Instansname

Als Administrator von welchem Rechner aus?

Auf dem Client, mit rechts Klick -> ausführen als Administrator

Das hört sich für mich danach an, dass das Programm noch irgendwo anders ausgeführt wird. Wenn du das mit AppLocker nicht sauber konfiguriert wurde, passiert genau sowas.

Ich würde eh bei AppLocker lieber mit Zertifikaten arbeiten. Macht die Arbeit damit deutlich einfacher.

Kann mir das eigentlich nicht vorstellen, aber wie kann ich das denn am schnellsten testen?

 

[Darkblade08]

Die Frage ist, wie euer AppLocker konfiguriert ist. Das Ding ist, wenn man es scharf schaltet, ein ziemlich zickiges Biest. Das muss man sauber und am besten für die komplette Softwareumgebung konfigurieren.

Am einfachsten lässt es sich testen, wenn du den AppLocker testweise deaktivierst. Dann hast du Gewissheit. Sollte das Programm beim Benutzer dann sauber laufen, dann musst du schauen wo das Programm noch Dateien ausführt. Da ich die Software nicht kenne, kann ich dir da nichts genaues zu sagen.

Eventuell ist es ja auch nicht das Problem.

 

[Turian]

Wenn du das als Admin ausführst, welche Art von Konto wird da benutzt ? Lokal, Domäne, DomAdmin,... ?

 

[jb_alvarado]

Danke @Darkblade08, werde das mal testen.

@Turian, es wird der Domain Admin genutzt. Habe gerade auch auf einem anderen Computer den lokalen Admin versucht, damit würde es auch nicht gehen. Also es geht nur der Domain Admin.

Ergänzung (25. November 2020)

Also am App Locker liegt es schon mal nicht. Nach Deaktivierung kann ich das Programm trotzdem nicht ausführen.

 

[Turian]

Erstell (oder nutze, wenn vorhanden) mal ein normales Userkonto, gib ihm die entsprechenden Berechtigungen auf der Freigabe, melde dich mal mit dem auf dem Server an, damit er lokal ein Profil hat, teste dann mal mit diesem Konto auf einem Client.

 

[jb_alvarado]

Also ich vermute, dass das wirklich mit der Ordnerfreigabe zusammen hängt. Habe mich jetzt auf einem Clientcomputer mit einem lokalem Konto angemeldet, und damit konnte ich das Netzlaufwerk nicht ohne Anmeldung erstellen. Die Freigaberegel Jeder tut also nicht greifen.

Wenn ich bei dem Netzlaufwerk eine bekannte Benutzeranmeldung nehme, geht es natürlich wieder nicht.

Edit2: Vielleicht noch als Info, wenn ich das Öffnen des Netzlaufwerks und des Programms von einem Client aus, in der Computerverwaltung auf dem Server verfolge, steht dort immer der Öffnungsmodus Lesen. Das müsste eigentlich Lesen/Schreiben sein, oder nicht? Wobei ich ja ansonsten Dateien in dem Laufwerk erstellen und verändern kann.

 

[snaxilian]

Berechtigungskontrollen bei Netzlaufwerken gibt es immer doppelt. Zum einen musst du angeben, wer per SMB-Protokoll, sprich übers Netzwerk, Zugriff haben soll. Nachdem der Zugriff des Anwenders vom Client-PC zum Server erlaubt ist kommen die Dateisystemberechtigungen hinzu denn auch dort muss der Anwender entsprechend berechtigt sein. Im besten Fall sollte man sich firmenweit als Admin bzw. die Admins. Gängige Best Practices ist eigentlich immer die Freigabe für Everyone oder "authenticated Users" (ja, das ist ein Unterschied) zu setzen und Zugriffskontrolle über die NTFS Berechtigungen zu steuern.

 

[jb_alvarado]

@snaxilian, die NTFS Berechtigungen stellt man doch unter: Ordern -> Egenschaften -> Sicherheit ein, richtig? Das wurde auch in der Anleitung beschrieben und ich habe damit jetzt auch noch mal etwas rumgespielt. Wenn ich z.B. den Besitzer ändere kann ich das Programm noch nicht mal mehr als Administrator ausführen.
Habe auch den Besitzer auf Jeder gestellt, selbst da kann ich das Programm nur als Admin öffnen.

Habe zusätzlich die Zugriffe in der Computerverwaltung beobachtet. Der Admin User verhält sich da genau so wie der normale User, mit dem Unterschied, dass er eine Datenbankverbindung aufbaut:

Vielleicht liegt das Problem hier doch bei der Datenbank, dass die andere Benutzer nicht zulässt. Wobei ja in der Konfigurationsdatei von dem Programm, explizit der sa User mit Passwort angegeben ist.

Edit: An der Datenbank liegt es vielleicht doch nicht, die registriert jedes mal einen erfolgreichen Login:

2020-11-26 10:29:53.83 Logon       Login succeeded for user 'sa'. Connection made using SQL Server authentication. [CLIENT: <named pipe>]
2020-11-26 10:29:53.83 spid53      Starting up database 'Linear'.
2020-11-26 10:29:53.92 spid53      Parallel redo is started for database 'Linear' with worker pool size [2].
2020-11-26 10:29:53.99 spid53      Parallel redo is shutdown for database 'Linear' with worker pool size [2].
2020-11-26 10:29:54.09 Logon       Login succeeded for user 'sa'. Connection made using SQL Server authentication. [CLIENT: <named pipe>]
2020-11-26 10:31:02.04 Logon       Login succeeded for user 'sa'. Connection made using SQL Server authentication. [CLIENT: <named pipe>]
2020-11-26 10:31:02.04 spid53      Starting up database 'Linear'.
2020-11-26 10:31:02.13 spid53      Parallel redo is started for database 'Linear' with worker pool size [2].
2020-11-26 10:31:02.19 spid53      Parallel redo is shutdown for database 'Linear' with worker pool size [2].
2020-11-26 10:31:02.30 Logon       Login succeeded for user 'sa'. Connection made using SQL Server authentication. [CLIENT: <named pipe>]

 

[t-6]

Vorsicht: Lass den Besitzer mal so wie er ist. Es ist in den wenigsten Fällen sinnvoll da etwas anzufassen.

Du musst einstellen dass der oder die Benutzer (arbeite mit Gruppen!) die relevanten Rechte haben. Fang mit "Ändern" an und teste das Programm noch mal.
Die Gruppe "Domänen-Benutzer" mit Ändern-Rechte zu versehen wäre ein guter Anfang; standardmäßig haben Domänen-Benutzer nur Leserechte, sind aber überall standardmäßig voreingetragen.

Domänen-Admins gehören standardmäßig zur lokalen Administratoren-Gruppe, welche Vollzugriff haben. Daher funktioniert das Programm.

 

[snaxilian]

Ist die Installations- & Konfigurationsanleitung irgendwo/beim Hersteller öffentlich einsehbar? Also zum einen möchte ich gerne etwas lachen und danach ist das ein nettes Hobbyprojekt für einen IT-Sicherheitsforscher und zum anderen übersiehst du ggf. etwas das wir hier alle aber nicht wissen können weil wir nur die teilweisen Informationen haben, die genannt sind

 

[Turian]

So, ich lehne mich mal ganz weit aus dem Fenster - ist das dein Programm ?
https://support.linear-software.de/220734-SQL-Datenbank-Anmeldeeigenschaften

 

[jb_alvarado]

Vorsicht: Lass den Besitzer mal so wie er ist. Es ist in den wenigsten Fällen sinnvoll da etwas anzufassen.

Ja, wollte das nur kurz mal testen.

Du musst einstellen dass der oder die Benutzer (arbeite mit Gruppen!) die relevanten Rechte haben. Fang mit "Ändern" an und teste das Programm noch mal.
Die Gruppe "Domänen-Benutzer" mit Ändern-Rechte zu versehen wäre ein guter Anfang; standardmäßig haben Domänen-Benutzer nur Leserechte, sind aber überall standardmäßig voreingetragen.

Domänen-Admins gehören standardmäßig zur lokalen Administratoren-Gruppe, welche Vollzugriff haben. Daher funktioniert das Programm.

Habe das probiert, zuerst mit einer definierten Gruppe, dann mit den Domänen-Benutzer.

Hier noch mal ein paar Screens:

@snaxilian, habe die Anleitung nicht im Netz gefunden, habe dazu nur ein PDF. Ich bin ja schon froh, dass man nicht gleich von Anfang an hier über die Sicherheit geschimpft hat :-). Im Grunde bleibt mir auch nichts anderes übrig, das Programm wird gebraucht und ich muss schauen wie ich es zum laufen bekommen. Das die Buchhaltungsabteilung in Betrieben die größte Schwachstelle eines Unternehmens ist, wundert mich schon lange nicht mehr...

Wenn es dann mal läuft, kann ich auch versuchen es etwas mehr abzusichern.

@Turian, Volltreffer - das ist das Programm. Ob das auch der Fehler ist, muss ich gerade mal prüfen.

 

[jb_alvarado]

Wenn ich die Benutzerzuordnung mit denen von @Turian verlinkten Webseite vergleiche, fehlen dort wirklich Berechtigungen. Das wurde in der Anleitung nicht erwähnt, allerdings kann ich die beschriebenen Zuordnungen nicht setzten.

 

[Turian]

Wo versuchst du die zu setzen ? Benutzeranmeldung ? DB ?
Hat dein genutztes Konto hat die Rechte dafür ?

 

[jb_alvarado]

Wo versuchst du die zu setzen ? Benutzeranmeldung ? DB ?
Hat dein genutztes Konto hat die Rechte dafür ?

Sicherheit -> Anmeldung -> User (sa) > Benutzerzuordnung.

Habe das als sa Benutzer und als Admin versucht. Fehlermeldung ist:

===================================

Fehler bei Mitglied hinzufügen von DatabaseRole "db_datareader".  (Microsoft.SqlServer.Smo)

------------------------------
Hilfe erhalten Sie durch Klicken auf: https://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=16.100.44091.28+(SMO-master-A)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Mitglied+hinzufügen+DatabaseRole&LinkId=20476

------------------------------
Speicherort des Programms:

   bei Microsoft.SqlServer.Management.Smo.DatabaseRole.AddMember(String name)
   bei Microsoft.SqlServer.Management.SqlManagerUI.CreateLoginData.LoginPrototype.ApplyDatabaseRoleChanges(Server server)
   bei Microsoft.SqlServer.Management.SqlManagerUI.CreateLoginDatabaseAccess.OnRunNow(Object sender)

===================================

Ausnahme beim Ausführen einer Transact-SQL-Anweisung oder eines Transact-SQL-Batches. (Microsoft.SqlServer.ConnectionInfo)

------------------------------
Speicherort des Programms:

   bei Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(String sqlCommand, ExecutionTypes executionType, Boolean retry)
   bei Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(StringCollection sqlCommands, ExecutionTypes executionType, Boolean retry)
   bei Microsoft.SqlServer.Management.Smo.ExecutionManager.ExecuteNonQuery(StringCollection queries, Boolean retry)
   bei Microsoft.SqlServer.Management.Smo.DatabaseRole.AddMember(String name)

===================================

Der Spezialprinzipal "dbo" kann nicht verwendet werden. (.Net SqlClient Data Provider)

------------------------------
Hilfe erhalten Sie durch Klicken auf: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=15.00.2070&EvtSrc=MSSQLServer&EvtID=15405&LinkId=20476

------------------------------
Servername: WIN-DB\Linear
Fehlernummer: 15405
Schweregrad: 16
Status: 1
Zeilennummer: 1


------------------------------
Speicherort des Programms:

   bei Microsoft.SqlServer.Management.Common.ConnectionManager.ExecuteTSql(ExecuteTSqlAction action, Object execObject, DataSet fillDataSet, Boolean catchException)
   bei Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(String sqlCommand, ExecutionTypes executionType, Boolean retry)

Ergänzung (27. November 2020)

Habe jetzt mal einen neuen DB user angelegt, mit den Zuordnungen: db_datareader, db_datawriter, db_ddladmin, public. Aber das gleiche Spiel, bekomme die Meldung von dem Programm: Anmeldungstimeout abgelaufen.

Im SQL Log bekomme ich allerdings die Meldung:

2020-11-27 09:21:23.95 Logon       Login succeeded for user 'USER'. Connection made using SQL Server authentication. [CLIENT: <named pipe>]

 

[jb_alvarado]

Also zur Info: Es hängt definitiv mit der Datenbank zusammen. Habe nämlich testhalber die Linux Version des MS SQL Server als Docker Container installiert, und nach etwas Startschwierigkeiten wegen benötigten Zertifikaten läuft nun alles so wie es soll.

Ob wir das so Produktiv nutzen werden, muss ich noch testen und abwägen. Support werde ich so sicher noch weniger bekommen...

 

[jb_alvarado]

Noch ein Nachtrag... Habe noch mal auf dem Windows Server alles deinstalliert und wieder installiert. Ging natürlich wieder nicht. Interessanterweise konnte ich auch mit sqlcmd per Remote nicht verbinden. Dort kam aber immer ein Timeout. Mit der Option -l120 konnte sqlcmd sich dann verbinden. Einen Verbindungstimeout kann man auch in der Datenbank angeben, aber das hat komischerweise nicht geholfen.

Heute bin ich bei meiner Recherche dann über diese Seite gestolpert. Und siehe da, das Eintragen des Ports 1433 unter IPALL war der Schlüssel.

Dafür habe ich jetzt mehrere Tage gebraucht... und meine Abneigung gegen Microsoft Server/Anwendungen hat ein neues Hoch erreicht... Auch stellt sich jetzt die Frage, ob das auch weiterhin funktionieren wird, wenn ich mehrere SQL Instanzen installiert habe.

Edit: Was wohl auch geht ist, wenn man den dynamischen Port bei IPALL in die Firewall einträgt.