direktes kopieren auf Netzlwaufwerk verhindern

[zeras]

Ich habe ein Programm für unsere Firma geschrieben, womit man Daten automatisch auf ein Netzwerklaufwerk archivieren kann. Die Dateien werden dann gleich noch mit gezipt und dort gespeichert. Im Programm sind Algorythmen drin, die das Archivieren erst erlauben, wenn bestimmte Regeln eingehalten werden.
Nun gibt es aber auch "Spezialisten", die die Daten direkt auf das Netzlaufwerk legen unter Umgehung meines Programms.
Wie kann ich das verhindern? Schreibrechte brauchen ja die Kollegen, um die Daten auf das Laufwerk zu bringen. Aber das wird auch manchmal ausgenutzt und direkt kopiert.
Unsere IT sagte mir, dass man vielleicht einen Prozeß schreiben sollte, der mit mehr Rechten ausgestattet ist und der normale User diese Rechte nicht mehr hat.
Kann ich solch einen Prozeß mit ins Programm einbauen?
Gibt es dazu Lösungsansätze? Oder wie kann ich da vorgehen?

[jfheins]

Am Ziel einen eigenen Prozess laufen lassen, der die Datei ablegt. Zum Beispiel wäre es möglich, über Samba (Windows-Freigabe) nur Lesezugriff zu gestatten, und den Schreibzugriff über SFTP abzuwickeln. Oder auch ein komplett eigener Server (ist aber vielleicht etwas mehr Aufwand)

[Captnemo]

Oder das Netzlaufwerk für den normalen User sperren / nur lese-recht, und das Programm unter einem anderen Usercontext laufen lassen, mit dem es dann auch schreibrechte hat.
Oder zur Laufzeit ein Netzlaufwerk mit anderer Useranmeldung verbinden, Daten schreiben und dann wieder trennen.

[zeras]

Zitat:

Zitat von Captnemo (Beitrag 1268883)

...
und das Programm unter einem anderen Usercontext laufen lassen, mit dem es dann auch schreibrechte hat.
Oder zur Laufzeit ein Netzlaufwerk mit anderer Useranmeldung verbinden, Daten schreiben und dann wieder trennen.

Das ist offensichtlich das, was mir unsere IT versuchte, klarzumachen. Nur weiß ich nicht, wie ich das anstellen kann.

[Captnemo]

Du könntest dir von der IT einen User mit schreibrechten einrichten lassen.

Dann teilst du dein Programm in 2 Teile. Teil 1 übernimmt das sammeln und Zippen der Daten z.b. im Temp-Verzeichnis.
Dann rufst das 2. Prog auf, und übergibst als Parameter die gezippte Datei incl. Pfad. Du startest dieses 2. Prog aber unter einem anderen Benutzer. Wie das geht: z.B. hierhttp://www.delphipraxis.net/176005-a...r-starten.html

Ab Vista kannst du ggf. auch dein Programm über die Verknüpfung gleich als anderer Benutzer starten lassen, aber ich weiß nicht, ob dann nicht immer das Kennwort abgefragt wird (ich glaube aber schon).

[zeras]

Zitat:

Zitat von Captnemo (Beitrag 1268888)

Du könntest dir von der IT einen User mit schreibrechten einrichten lassen.

Dann teilst du dein Programm in 2 Teile. Teil 1 übernimmt das sammeln und Zippen der Daten z.b. im Temp-Verzeichnis.
Dann rufst das 2. Prog auf, und übergibst als Parameter die gezippte Datei incl. Pfad. Du startest dieses 2. Prog aber unter einem anderen Benutzer. Wie das geht: z.B. hierhttp://www.delphipraxis.net/176005-a...r-starten.html

Ab Vista kannst du ggf. auch dein Programm über die Verknüpfung gleich als anderer Benutzer starten lassen, aber ich weiß nicht, ob dann nicht immer das Kennwort abgefragt wird (ich glaube aber schon).

Damit sollte ich erst mal klarkommen. Vielen Dank.

[jaenicke]

Ich würde das ganze mit dem Starten als anderer Benutzer sein lassen. Es genügt, wenn du einen Dienst schreibst, der das übernimmt und den so konfigurierst, dass er als anderer Benutzer läuft (der, der die Rechte hat). Das sollte über die Softwareverteilung klappen, sofern es eine gibt, oder ansonsten mit einem Aufruf der sc.exe mit Adminrechten erledigt sein. Du brauchst dann nur den Dienst per IPC steuern.

[Uwe Raabe]

Der übliche Weg, eine Verbindung zu einem Netztwerkpfad unter einem anderen Benutzer zu erstellen ist eigentlich WNetAddConnection2. Eine Lösung könnte in etwa so aussehen:

Delphi-Quellcode:

const
  cLocalName = 'N:'; // oder ein anderer verfügbarer Buchstabe
var
  data: TNetResource;
  res: Cardinal;
begin
  data.dwType := RESOURCETYPE_DISK;
  data.lpLocalName := cLocalName ; 
  data.lpRemoteName := <Der Netzwerkpfad>;
  data.lpProvider := '';
  res := WNetAddConnection2(data, <Das Passwort>, <Der Username>, CONNECT_TEMPORARY);

  if res = NOERROR then begin
    try
      <Mach was immer nötig ist>
    finally
      res := WNetCancelConnection2(cLocalName , 0, false);
    end;
  end
  else begin
    <Fehlerbehandlung> 
  end;
end;

[BUG]

Leicht OT:
Auf der anderen Seite könntest du versuchen herauszufinden, warum einige Nutzer dein Programm umgehen.

Im Prinzip: Warum sollte man den "Spezialisten" ihren Workflow vorenthalten?
Du könntest ein Eingangsordner haben, dessen Inhalt dann von deinem Service validiert und auf das Netzlaufwerk geschrieben wird.

[zeras]

Zitat:

Zitat von BUG (Beitrag 1268897)

Leicht OT:
Auf der anderen Seite könntest du versuchen herauszufinden, warum einige Nutzer dein Programm umgehen.

Im Prinzip: Warum sollte man den "Spezialisten" ihren Workflow vorenthalten?

Es werden mit dem Kopieren noch Versionen rausgezogen, die man dann nicht automatisiert hätte. Die Daten werden teilweise sehr lange nicht gebraucht, aber wenn man diese brauchen sollte, dann sollten diese korrekt abgelegt sein.
In Summe sollten ca. 8 Leute mit dem Programm arbeiten. Da wüsste ich nicht, wie man an die Info kommt, wer das direkt auf das Laufwerk kopiert hat.
Kann man denn an der Datei etwas sehen, wer das kopiert hat?

[Captnemo]

Zitat:

Zitat von zeras (Beitrag 1268898)

Da wüsste ich nicht, wie man an die Info kommt, wer das direkt auf das Laufwerk kopiert hat.
Kann man denn an der Datei etwas sehen, wer das kopiert hat?

Naja, eure Netzwerkadmins sollten in der Lage dazu sein.

[Captnemo]

Zitat:

Zitat von jaenicke (Beitrag 1268890)

Ich würde das ganze mit dem Starten als anderer Benutzer sein lassen. Es genügt, wenn du einen Dienst schreibst, der das übernimmt und den so konfigurierst, dass er als anderer Benutzer läuft (der, der die Rechte hat). Das sollte über die Softwareverteilung klappen, sofern es eine gibt, oder ansonsten mit einem Aufruf der sc.exe mit Adminrechten erledigt sein. Du brauchst dann nur den Dienst per IPC steuern.

Geht natürlich auch.
Aber wenn ich den TE richtig verstanden habe, dann wird das Speichern nur in großen Abständen durchgeführt. Dazu immer einen Dienst laufen lassen, der Ewigkeiten nutzlos Rechenzeit verbraucht?

[jensw_2000]

Wenn ich das richtig gelesen habe, dann sollen die User eine Read-Only Verbindung zum Share haben und aus dem Programm heraus soll eine weitere SMB Session zum gleichen Share aufgebaut werden (mit Schreibrechten, unter anderem User Account).

Das wird nur mit einem "Trick" funktionieren.

Pro User Session ist nur eine authentifizierte Verbindung zum gleichen Server zugelassen. Die zweite Anmeldung (aus dem Programm heraus) wird fehlschlagen.

Das kann man ganz leicht nachprüfen:
- auf einem Server ein Share einrichten, auf dem der aktuelle User keine Rechte besitzt
- einem anderen Useraccount, als dem Eigenen, Leserechte geben
- vom Client aus mit dem Share verbinden (\\Server\Share) > der Server fragt nach User und Kennwort, weil der aktuelle User keine Rechte besetzt
- anmelden mit den "Readonly User Account" >>> Share wird readonly verbunden
- vom Client aus eine 2. Verbindung zum gleich Server aufbauen ( z.B. als Admin auf \\Server\c$ ) >>> Server fragt wieder nach User+Kennwort, weil der aktuelle User und der Readonly User nicht für das Share c$ authentifiziert sind
- eingeben von gültigen Admin Credentials >>> führt zwangsläufig zur Fehlermeldung

Zitat:

Mehrfache Verbindungen zu einem Server oder einer freigegebenen Ressource von demselben Benutzer unter Verwendung mehrere Benutzernamen sind nicht zulässig. Trennen sie alle früheren Verbindungen zu dem Server bzw. der freigegebenen Ressource und versuchen Sie es erneut. Die Verbindung wurde nicht wiederhergestellt.

Es ist also erstmal unmöglich sich mit 2 Accounts am gleichen Server zu authentifizieren.

Umgehen kann man das nur durch einen Trick.
- der normale User verbindet sich ReadOnly mit dem UNC Pfad "\\Server\ArchiveShare"
- Das Programm nimmt anstatt des Servernamens die Server IP "\\192.168.0.10\ArchiveShare" um sich schreibend zu authentifizieren

SMB ist zum Glück so "dumm", dass es nicht prüft ob es sich bei "Server" und "192.168.0.10" um das gleiche Ziel handelt.

[zeras]

Zitat:

Zitat von Captnemo (Beitrag 1268900)

Aber wenn ich den TE richtig verstanden habe, dann wird das Speichern nur in großen Abständen durchgeführt. Dazu immer einen Dienst laufen lassen, der Ewigkeiten nutzlos Rechenzeit verbraucht?

Im Durchschnitt werden pro Tag ca. 20-30 Dateien pro Tag auf den Server kopiert. Heruntergeladen wird aber mehr. Ob da ein Dienst Sinn macht, weiß ich nicht. Wie schon geschrieben, sind das um die 8 User mit teilweise 2 Rechnern pro User.

Zitat:

Zitat von jensw_2000 (Beitrag 1268903)

Umgehen kann man das nur durch einen Trick.
- der normale User verbindet sich ReadOnly mit dem UNC Pfad "\\Server\ArchiveShare"
- Das Programm nimmt anstatt des Servernamens die Server IP "\\192.168.0.10\ArchiveShare" um sich schreibend zu authentifizieren

SMB ist zum Glück so "dumm", dass es nicht prüft ob es sich bei "Server" und "192.168.0.10" um das gleiche Ziel handelt.

Danke für die Info. Das müsste ich dann noch beachten, wenn ich diese Lösung nutzen würde.

[himitsu]

Zitat:

Zitat von Captnemo (Beitrag 1268900)

Dazu immer einen Dienst laufen lassen, der Ewigkeiten nutzlos Rechenzeit verbraucht?

Man kann natürlich Programme so schreiben, daß sie das nicht machen.

- Das Programm belegt nur wenig Arbeitsspeicher und/oder es kann problemlos der Speicher ausgelagert werden (PageFile).
- Das Programm guckt nicht sändig sinnlos nach, ob was da ist, sonder lässt sich darüber Informieren (Verzeichnisüberwachung registrieren) und legt sich dazwischen schlafen bis eines der Events reinkommt (es ist was in der Messageloop oder die Überwachung hat was gemeldet), areitet das Ereignis ab und schläft dann weider.

[RWarnecke]

Und warum wird nicht einfach das Recht zum Browsen für das Verzeichnis entzogen ? So kann jeder User immer noch schreiben und lesen, kann sich aber den Inhalt im Explorer nicht mehr anschauen. Damit bräuchte man keine zweite Anmeldung.

[samso]

@jensw_2000
Der Trick der hier geplant ist, ist aber, eben nicht die gleiche User-Session zu benutzen, sondern eine neue Session aufzumachen (entweder in Form eines Dienstes, oder als zweiten Prozess, der sich am Client-Rechner unter einem anderen Useraccount anmeldet). Deswegen kommen die genanten Einschränkungen hier nicht zum Tragen.
Ich persönlich würde den Aufwand eines zweiten Prozesses und der Interprocesskommunikation eher vermeiden und stattdessen den Vorschlag von jfheins aufgreifen und ein anderes Netzwerkprotokoll wählen.

[zeras]

Zitat:

Zitat von Uwe Raabe (Beitrag 1268891)

Der übliche Weg, eine Verbindung zu einem Netztwerkpfad unter einem anderen Benutzer zu erstellen ist eigentlich WNetAddConnection2. Eine Lösung könnte in etwa so aussehen:

Delphi-Quellcode:

const
  cLocalName = 'N:'; // oder ein anderer verfügbarer Buchstabe
var
  data: TNetResource;
  res: Cardinal;
begin
  data.dwType := RESOURCETYPE_DISK;
  data.lpLocalName := cLocalName ; 
  data.lpRemoteName := <Der Netzwerkpfad>;
  data.lpProvider := '';
  res := WNetAddConnection2(data, <Das Passwort>, <Der Username>, CONNECT_TEMPORARY);

  if res = NOERROR then begin
    try
      <Mach was immer nötig ist>
    finally
      res := WNetCancelConnection2(cLocalName , 0, false);
    end;
  end
  else begin
    <Fehlerbehandlung> 
  end;
end;

Ich komme noch einmal auf diese Funktion zurück.
Das geht erst einmal, nur wird der User sehen, dass ein neues Laufwerk gemappt wurde. Kann man nicht eine Netzwerkressource in der Art "\\192.168.220.xxx\PfadNurFuerWissenende" nutzen, damit man nicht so leicht die Ressource findet?

[HolgerX]

Hmm.

Zitat:

Zitat von zeras (Beitrag 1445150)

Ich komme noch einmal auf diese Funktion zurück.
Das geht erst einmal, nur wird der User sehen, dass ein neues Laufwerk gemappt wurde. Kann man nicht eine Netzwerkressource in der Art "\\192.168.220.xxx\PfadNurFuerWissenende" nutzen, damit man nicht so leicht die Ressource findet?

Wieso dann in der Funktion nicht einfach

Delphi-Quellcode:

const
  cLocalName = ''

verwenden?
Dadurch wird sich auf dem Share mit dem angegebenen User und Password 'angemeldet', ohne ein Laufwerksbuchstaben zu verwenden.
Anschließend dann einfach über den UNC-Pfad (deinem "\\192.168.220.xxx\PfadNurFuerWissenende") darauf zugreifen.

ABER
Mit 'net use' taucht auch diese Verbindung auf, jedoch nicht im Explorer....

[zeras]

Zitat:

Zitat von HolgerX (Beitrag 1445158)

ABER
Mit 'net use' taucht auch diese Verbindung auf, jedoch nicht im Explorer....

Danke für den Hinweis.
Ist aber ein wenig schwieriger zu finden, als ein Laufwerkszugriff.
Wenn jemand weiß, wie das ganze funktioniert, wird er auch den Zugriff finden, aber die Leute sollen sich eigentlich auf mein Programm verlassen.