Windows-Berechtigung auf Netzwerkfreigabe

[Codehunter]

Hallo!

Folgendes Szenario:

• eine Windows-2008-Domäne
• ein Fileserver mit freigegebenem Netshare
• ein Netzlaufwerksbuchstabe welcher auf jedem Domänenclient per GPO auf dieses Netshare verbunden wird
• ein Ordner unterhalb des Netzlaufwerkes
• ein spezieller Domänenbenutzer, welcher als einziger Lese- u. Schreibrechte auf diesem Ordner hat
• ein Delphi-Programm, welches im Benutzerkontext anderer Domänenbenutzer läuft
• das Delphi-Programm soll Dateien in besagtem Ordner ablegen und wieder lesen können
• den normalen Domänen-Benutzern sind die Zugangsdaten für den Ordner nicht bekannt

Besagter Ordner soll eine Art "Zettelkasten" für einen fortlaufenden Import eines zugekauften Warenwirtschaftssystems sein. Die Delphi-Anwendung wirft sozusagen Änderungsanweisungen für die Warenwirtschaft hinein. Ich will von vornherein ausschließen, dass bastelfreudige Angestellte an den Dateien im Zettelkasten herum schrauben. Darum dachte ich mir, ich konstruiere das über Datei-/Ordnerberechtigungen und gebe der Delphi-Anwendung die entsprechenden Login-Daten einfach mit.

Wo ich nicht so recht weiter komme ist die Tatsache, dass die Delphi-Anwendung vom jeweiligen Mitarbeiter-Domänenkonto aus ausgeführt wird und entsprechend dessen Berechtigungen erbt. Das ist auch gut so und soll so bleiben. Lediglich die "Zettelwerferei" soll intern mit anderern Benutzerrechten laufen. Und zwar ohne dass Login-Daten vom Benutzer abgefragt werden.

Über (mangelnde) Eleganz hartcodierter Login-Daten wollen wir uns an der Stelle mal nicht streiten, das ist nur eine kleine Umgehungslösung bis die nächste große Wawi-Release kommt.

Danke schon mal...

Grüße
Cody

[Dalai]

Soweit ich weiß, ist der kleinste gemeinsame Nenner die Prozessebene; ein Thread kann AFAIK nicht mit anderen Credentials laufen als die anderen Threads im selben Prozess (anderer Token geht glaub ich).

Ich sehe nur die Möglichkeit, dass die "Zettelwerferei" mit einer separaten EXE realisiert wird, die vom Delphi-Programm aus mit den entsprechenden Credentials gestartet wird. Alternativ könnte das Delphi-Programm eine zweite Instanz mit anderen Credentials seiner selbst starten (via Parameter), die die gewünschte Aktion ausführt und sich gleich wieder beendet. Wo die Zugangsdaten dann hinterlegt sind, lasse ich mal offen.

Aber vielleicht haben andere Leser noch bessere, elegantere Ideen.

MfG Dalai

[p80286]

Könnte man das nicht mit Hilfe einer/der DB lösen?
Die angestrebte Lösung scheint mir zu "tricky" zu sein.

In beiden Fällen hätte man einen "Hintertürbenutzer" der nach meiner Meinung für eine DB besser in den Griff zu bekommen ist (ein Benutzer mit Rechten nur auf einen View/Table, ggf noch in einem anderen Schema?)

U.U sind die Daten auch noch verschlüsselt!?

Gruß
K-H

[jobo]

Soweit mir bekannt, wird clientseitig ein Netzlaufwerk je Server nur mit einem(1!) Benutzer verbunden. Befindet sich die Freigabe für den Zettelkasten also auf dem gleichen Server, auf dem bereits andere Freigaben für den User aktiv- nicht nur definiert- sind, funktioniert eine weitere Ressourcennutzung unter anderem Account nicht.
Also vielleicht einfacher per DB, Webservice oder so umzusetzen.

[mjustin]

Meine "Ideallösung" wäre ein (Delphi-)Programm ohne Datenbank auf einem nicht-interaktiven Rechner - aber nicht auf dem Fileserver ;) - zu verwenden das über IPC (z.B. simples HTTP) die Daten entgegennimmt.

Vorteile: kein Overhead durch Starten eines weiteren Programms, Zugangsdaten stehen nicht in der Clientseitigen Anwendung, die Clientseite kennt nur den DNS Namen des nicht-interaktiven Rechners, Zugriff auf Zielordner erfolgt nur von einem einzigen System aus

Nachteile/Risiken: der IPC Prozess könnte gerade mal unerreichbar sein. Clients müssten "Retry" Fähigkeit besitzen oder es wird eine "Message Queue" (anstatt HTTP) verwendet

[Codehunter]

Das Problem ist leider, dass die Wawi serverseitig (also die DB) verriegelt und verrammelt ist. Die bieten nichts anderes an als die Dateischnittstelle. Die Variante, einen Serverdienst zu schreiben hatte ich mir auch schon überlegt, dann aber aus Kosten-Nutzen-Gründen wieder verworfen.

[pesi]

Hi,
ich habe mal folgenden Codeschnipsel gefunden und den nutze ich auf fleißig.
...allerdings immer nur um ein Laufwerk zu mappen, aber nie mit den Parametern User und Passwort. Müsstest Du also mal ausprobieren!?

Code:

function TForm1.LaufwerkVerbinden(const ADrive: String;
  const ADirectory, AUsername, APassword: String;
  const ARestoreAtLogon: Boolean ): Boolean;
var
  NetResource: TNetResource;
  dwFlags:     DWORD;
  lPwd, lUser: PChar;
begin
  NetResource.dwType:=RESOURCETYPE_DISK;
  NetResource.lpLocalName:=PChar(ADrive);
  NetResource.lpRemoteName:=PChar(ADirectory);
  NetResource.lpProvider:=nil;

  if ARestoreAtLogon then
    dwFlags:=CONNECT_UPDATE_PROFILE
  else
    dwFlags:=0;

  if AUsername<>'' then
    lUser:=PChar(AUsername)
  else
    lUser:=nil;

  if APassword<>'' then
    lPwd:=PChar(APassword)
  else
    lPwd:=nil;

  Result:=WNetAddConnection2(NetResource,
                             lPwd,
                             lUser,
                             dwFlags)=NO_ERROR;
end;

[pesi]

Ach so.... trennen tu ich mein Laufwer "B:" dann immer mit WNetCancelConnection2('B:',0, True);

[Dalai]

Zitat:

Zitat von jobo (Beitrag 1327345)

Soweit mir bekannt, wird clientseitig ein Netzlaufwerk je Server nur mit einem(1!) Benutzer verbunden.

Wenn der Zugriff mit demselben (lokalen) Benutzer stattfindet, dann stimmt das. Ein Nutzer kann beim Verbinden einer Freigabe (bzw. dem Zugriff auf diese) desselben Servers keine anderen Zugangsdaten benutzen als diejenigen, die für bereits verbundene/bestehende Netzlaufwerke aktiv sind. Windows quittiert jeglichen Versuch mit einer entsprechenden Fehlermeldung (Meldungstext gerade nicht gegenwärtig).

Zitat:

Befindet sich die Freigabe für den Zettelkasten also auf dem gleichen Server, auf dem bereits andere Freigaben für den User aktiv- nicht nur definiert- sind, funktioniert eine weitere Ressourcennutzung unter anderem Account nicht.

Mit demselben Benutzertoken nicht, aber mittels eines z.B. via RunAs gestarteten Prozesses schon; das ist das, was ich oben meinte.

MfG Dalai

[jobo]

Zitat:

Zitat von Dalai (Beitrag 1327353)

Zitat:

Befindet sich die Freigabe für den Zettelkasten also auf dem gleichen Server, auf dem bereits andere Freigaben für den User aktiv- nicht nur definiert- sind, funktioniert eine weitere Ressourcennutzung unter anderem Account nicht.

Mit demselben Benutzertoken nicht, aber mittels eines z.B. via RunAs gestarteten Prozesses schon; das ist das, was ich oben meinte.

Ok, das habe ich oben so nicht verstanden. Es dreht sich um den (Domänen)Account für die Serveranmeldung. Es kann nur jeweils einen geben. Werden die anderen Credentials nicht nur bei der Ressourcenanforderung des Netzlaufwerks, sondern schon beim (separat gestarteten) Prozess per RunAS angegeben, wird das wohl gehen.

Dann gibt's noch die "Gemeinheit", dass es nicht unbedingt geheim bleibt, wenn ein Nutzer sich alle Prozesse anzeigen darf. Zumindest der "Fremd"-Account ist dann bekannt.
Wenn der Prozess selbst auf der Freigabe Probleme macht, kann man schlecht erkennen, wer der Übeltäter ist (gesperrte Datei, ..)

Kann man nicht einfacher User spezifische Share mit entsprechenden Berechtigungen einrichten, so wie bei einem privaten Laufwerk?
Ist transparenter, kein Gewurschtel mit Accounts, maximale Verwüstung wären die eigenen Zettel.