Fehlende Berechtigung bei Programm-Update auf Server

[JustTheNextUser 7]

Hallo zusammen,

ich habe ein Problem mit einem Applikations-Update bei einem Kunden.

Der Großteil der Software liegt auf einem Netzlaufwerk 'X:' (UNC-Pfad: \\SERVER\FREIGABE).
Dieses ist auf dem DC als DFS-Freigabe eingerichtet.

Für die Software laufen ein Applikations- und ein Web-Server. Diese laufen als Applikation auf einem gesonderten (Terminal-)Server.
Hier befindet sich auch der Rest der Software-Daten in der Festplatten-Verzeichnisstruktur (C:\Software\)

Der Kunde macht für die Applikation regelmäßig Updates. Diese werden über eine Art Manager heruntergeladen (EXE-Datei) und dann aufgeführt/installiert.

Damit der Kunde diese Updates auf dem Server durchführen kann, habe ich einen dedizierten Benutzer 'programm_admin' angelegt, welcher sich am Terminal-Server anmelden kann und die Updates durführen soll.
Innerhalb dieses Nutzers laufen auf Applikations- und Web-Server.
Dieser (Domain-)Benutzer 'programm_admin' ist auf dem (Terminal-)Server in der Gruppe der Administratoren.
Zusätzlich hat der auf die Netzwerkfreigabe 'X:' Vollzugriff (in Freigabe- und Sicherheitsberechtigungen).

Dieser Benutzer kann das Update allerdings nicht durchführen!
Das Programm gibt zurück 'Keine ausreichenden Berechtigungen - Starte erneut mit Benutzer mit höheren Berechtigungen, bitte warten..'.
Hier passiert dann allerdings nichts mehr; man kann die Installation nur noch abbrechen.

Wenn ich die Update-Installation allerdings mit dem Domain-Administrator durchführe, oder dem Benutzer 'programm_admin' die Domain-Admin-Berechtigungen gebe bzw. die Administrator-Berechtigung des DC, dann geht es einwandfrei.

Ich verstehe leider nicht, warum das so ist.
Der Benutzer hat doch Admin-Rechte auf dem (Terminal-)Server und auf die Freigabe ('X:'). Dies ist meiner Meinung nach doch alles was er benötigt, um das Programm-Update auf dem Terminal-Server zu installieren.
Ich hatte gesehen, dass die EXE-Datei in das Benutzer-Verzeichnis TEMP in APPDATA entpackt wird, wenn man die Installation startet und bei der Fehlermeldung direkt verschwindet.
Allerdings hat der Benutzer ja volle Berechtigung auf sein Benutzer-Verzeichnis; sollte ja soweit passen.

Der Software Hersteller kann mir leider nicht weiterhelfen, die Verweisen darauf, dass es ein Berechtigungs-Problem ist, da es mit dem Domain-Admin klappt und ich das Problem selbst lösen müsste.

Hat hier einer noch eine Idee, was hier noch fehlen könnte an Berechtigungen, oder was das Problem ist?
Kann man ggf. irgendwie nachvollziehen, was die Installation für Prozesse versucht bzw. was für Verbindungen auf den DC?
Irgendwelche Ansätze?

Danke schonmal für die Mühen.
Viele Grüße.

[tesso 375]

Hiermit solltest du den Fehler eingrenzen können. Process Monitor - Windows Sysinternals | Microsoft Docs

 

Hat der program_admin auch ntfs Rechte auf das Verzeichnis? Rechte für den Share alleine reichen nicht. 

[testperson 1.682]

Hi,

 

klappt es, wenn du nicht über Laufwerk X: gehst sondern über den UNC Pfad? Ansonsten:

 

• Process Monitor - Windows Sysinternals | Microsoft Docs
• Process Explorer - Windows Sysinternals | Microsoft Docs

Gruß

Jan

[JustTheNextUser 7]

vor 49 Minuten schrieb tesso:

Hat der program_admin auch ntfs Rechte auf das Verzeichnis? Rechte für den Share alleine reichen nicht. 

Ja hat er, ich dachte das war klar mit meiner Formulierung 'Freigabe- und Sicherheitsberechtigungen'. Also ja Freigabe- und NTFS-Berechtigungen hat er.

Und jeweils sogar 'Vollzugriff', auch wenn 'Ändern' ja mMn eigentlich reichen würde/bzw. richtig wäre.

 

 

vor 51 Minuten schrieb testperson:

klappt es, wenn du nicht über Laufwerk X: gehst sondern über den UNC Pfad?

Nein über den UNC-Pfad genauso wenig.

Ich hatte schon einige Versuche und Kombinationen probiert, auch mit der UAC gespielt, verschiedene Benutzer, Gruppen, RUNAS, etc. Hat erstmal alles nichts geholfen.

 

Danke euch beiden, ich schaue mal ob ich mit dem Process Monitor/Explorer weiter komme.

 

VG

[testperson 1.682]

Wenn die Software nicht geheim ist, könntest du die noch benennen. Evtl. gibt es jemanden, der das schon durch hat und helfen kann. Andererseits würde ich den Hersteller mit dieser Aussage nicht durchkommen lassen und dort ggfs. weiter anfragen.

 

Der "programm_admin" hat auch auf dem Applikations und/oder Webserver Berechtigungen, sofern dort welche gebraucht werden?

[JustTheNextUser 7]

vor 41 Minuten schrieb testperson:

Wenn die Software nicht geheim ist, könntest du die noch benennen. Evtl. gibt es jemanden, der das schon durch hat und helfen kann. Andererseits würde ich den Hersteller mit dieser Aussage nicht durchkommen lassen und dort ggfs. weiter anfragen.

Die Software ist nicht wirklich geheim, aber eine arge Nischen-Lösung, ich denke nicht dass diese hier Forenweit jemand einsetzt. Ich will auch dem Hersteller nicht zu Nahe treten, darum wollte ich jetzt erstmal keine Namen nennen; ist ja meines Erachtens auch nicht zielführen.

Nicht durchkommen lassen sagt sich einfach.. das ist ein Ein-Mann-Programmierer, der sagt er hält sich an die Spezifikationen von Windows und kopiert/überschreibt nur Dateien innerhalb des Netzwerk-Pfads. Ich bin hier gestern schon auf Granit gestoßen, als ich sagte, dass die Berechtigungen dann ja ausreichend sein sollten. Wollte er so nicht verstehen; zumal es ja mit dem Domain-Admin-Rechten klappt.. nur toll ist dieser 'Workarround' ja ehr nicht.

 

vor 41 Minuten schrieb testperson:

Der "programm_admin" hat auch auf dem Applikations und/oder Webserver Berechtigungen, sofern dort welche gebraucht werden?

Es laufen 2 Applikationen auf dem (Terminal-)Server, der Webserver und der Applikations-Server. Und auf diesem (Terminal-)Server ist der 'programm_admin' in der Gruppe Administratoren. Also ja; ich kann mit diesem Benutzer auf dem Terminal-Server auch ohne Probleme in den Windows-Ordnern schreiben/Dateien erstellen/löschen.

 

 

Ich kämpfe gerade mit den Prozess-Monitor/Explorer, aber finde hier erstmal nicht auffälliges. Ich kenne mich damit aber auch quasi nicht aus. Soweit ich sehen kann will der Installer nur auf den UNC Pfad zugreifen oder auf den lokalen Server... aber wie gesagt, ich kenne mich auch nicht wirklich mit dem Sysinternals-Tools aus.

 

VG

bearbeitet 8. April 2021 von JustTheNextUser

[testperson 1.682]

vor 2 Stunden schrieb JustTheNextUser:

Das Programm gibt zurück 'Keine ausreichenden Berechtigungen - Starte erneut mit Benutzer mit höheren Berechtigungen, bitte warten..'.

Zumindest an der Stelle sollte der Entwickler doch sagen können, wie er auf welche Berechtigungen prüft und scheinbar auch "anfordert"?

[MurdocX 952]

vor 2 Stunden schrieb JustTheNextUser:

Wenn ich die Update-Installation allerdings mit dem Domain-Administrator durchführe, oder dem Benutzer 'programm_admin' die Domain-Admin-Berechtigungen gebe bzw. die Administrator-Berechtigung des DC, dann geht es einwandfrei.

Ich verstehe leider nicht, warum das so ist.

 

Das ist nicht schlimm, denn dafür gibt es ja einen Herstellersupport. Wenn dieser Dir nicht weiterhelfen kann, dann kennt er wohl sein eigenes Programm nicht.

 

Was deinen lokalen Admin generell von dem eines Domänen-Admins unterscheidet, sind die Berechtigungen im Active Directory. Der nächste Schritt wäre festzustellen, auf was oder wo während der Installation im AD zugegriffen wird. Der zweite Schritt ist dann dem Benutzer "programm_admin" dort Änderungs- oder Leserechte einzuräumen. Damit wird diese Meldung nicht mehr erscheinen. Mehr als ein "Admin" wirst du nicht brauchen, und falls doch, wird das sich das Programm diese Berechtigung holen können. 

 

vor 2 Stunden schrieb JustTheNextUser:

Dies ist meiner Meinung nach doch alles was er benötigt, um das Programm-Update auf dem Terminal-Server zu installieren.

 

 

Das weiß wohl nur der Entwickler oder der Support. Raten ist meiner Meinung nach kein zielgerichtetes Vorgehen.

 

vor 2 Stunden schrieb JustTheNextUser:

Kann man ggf. irgendwie nachvollziehen, was die Installation für Prozesse versucht bzw. was für Verbindungen auf den DC?

 

Siehe @testperson.

 

vor einer Stunde schrieb JustTheNextUser:

Ich kämpfe gerade mit den Prozess-Monitor/Explorer, aber finde hier erstmal nicht auffälliges. Ich kenne mich damit aber auch quasi nicht aus. Soweit ich sehen kann will der Installer nur auf den UNC Pfad zugreifen oder auf den lokalen Server... aber wie gesagt, ich kenne mich auch nicht wirklich mit dem Sysinternals-Tools aus.

Das ist erstmal kein Problem. Um den Zugriff eingrenzen zu können, solltest du erstmal nach der Exe-Filtern. Denn dann wird der Rest schon mal ausgeblendet.

 

Hier wird das recht gut erklärt: 

Process Monitor, powerful tool to troubleshoot applications and Windows | youtube

 

[Sunny61 806]

vor 2 Stunden schrieb MurdocX:

Das ist nicht schlimm, denn dafür gibt es ja einen Herstellersupport. Wenn dieser Dir nicht weiterhelfen kann, dann kennt er wohl sein eigenes Programm nicht.

Wenn es eine 1-Mann Bude ist, und so hab ich den TO verstanden, dann kennt der Entwickler wahrscheinlich nur Dom-Admin und Benutzer, sonst nichts. Zielführender wäre dann vermutlich ein Systemwechsel, mit allen Vor- und Nachteilen die an so einem Wechsel dran hängen.

[tesso 375]

Über procmon sollte man bei der Installation aber sehen wo ein Zugriff fehlschlägt. 

Je nachdem was nicht ausgeführt werden kann, muß man dann die Berechtigungen anpassen.

[MurdocX 952]

vor 2 Stunden schrieb Sunny61:

Wenn es eine 1-Mann Bude ist, und so hab ich den TO verstanden, dann kennt der Entwickler wahrscheinlich nur Dom-Admin und Benutzer, sonst nichts. Zielführender wäre dann vermutlich ein Systemwechsel, mit allen Vor- und Nachteilen die an so einem Wechsel dran hängen.

So hart wie das klingt, ja. Das kann er auch nur mit kleinen Kunden machen. Einem bekannten Soft-und Hardwarehersteller für Laborgeräte bin ich mal "dezent" auf die Füße gestiegen.

[JustTheNextUser 7]

vor 19 Stunden schrieb testperson:

Zumindest an der Stelle sollte der Entwickler doch sagen können, wie er auf welche Berechtigungen prüft und scheinbar auch "anfordert"?

Mir zumindest sagt er es nicht, bzw. nicht genauer.

 

vor 19 Stunden schrieb MurdocX:

Das ist erstmal kein Problem. Um den Zugriff eingrenzen zu können, solltest du erstmal nach der Exe-Filtern. Denn dann wird der Rest schon mal ausgeblendet.

Hab ich soweit gemacht, dachte mir schon dass es ohne Filter sonst quasi unmöglich hier etwas zu finden, da ist ja zu viel los. Ich schau mir am Wochenende auch mal das Video an, bzw. dann auch nochmal die Installations-Prozesse etwas genauer.

Dass ich im ersten Moment nichts auffälliges gefunden habe heißt ja erstmal nicht.

 

vor 16 Stunden schrieb Sunny61:

Wenn es eine 1-Mann Bude ist, und so hab ich den TO verstanden, dann kennt der Entwickler wahrscheinlich nur Dom-Admin und Benutzer, sonst nichts. Zielführender wäre dann vermutlich ein Systemwechsel, mit allen Vor- und Nachteilen die an so einem Wechsel dran hängen.

Dazu kann ich recht wenig sagen, ich kenne die Firma nicht wirklich, weiß nur dass es quasi 1 Geschäftsführer und sein Programmierer ist. Ich bin selbst auch kaum bewandert in Programmierung an sich, deswegen lehne ich mich da auch mal nicht zu weit aus dem Fenster.

 

vor 15 Stunden schrieb tesso:

Über procmon sollte man bei der Installation aber sehen wo ein Zugriff fehlschlägt. 

Ja wenn ich Zeit finde werde ich wie gesagt nochmal genauer schauen, ich habe schon echt viel Zeit versenkt, was mir wieder keiner bezahlt weil dem Kunden ist es natürlich komplett egal ob da ein Nutzer mit Dom-Admin-Rechten rumgeistert. Da kann ich dann auch sagen was ich will.

Verstehen viele dann immer erst wenn es knallt.

 

vor 14 Stunden schrieb MurdocX:

So hart wie das klingt, ja. Das kann er auch nur mit kleinen Kunden machen. Einem bekannten Soft-und Hardwarehersteller für Laborgeräte bin ich mal "dezent" auf die Füße gestiegen.

Also ich bin im Prinzip immer erstmal der Freund von einer friedlichen, kommunikativen Lösung und habe eigentlich auch keine Lust auf so eine Schlammschlacht und dieses 'hin und her - Schuld zuweisen'. Ich habe kein Druckmittel, weil des meinem Kunden erstmal egal ist und wenn die Firma auf stur schaltet dann kann ich erstmal nicht viel machen. Ich verstehe was du meinst, aber hier in meinem Fall wohl nicht the way to go.

 

 

 

Danke euch allen für die schnelle Hilfe, ich habe meine Info wegen dem Process Monitor und werde schauen wie und ob ich damit zu Rande komme.

Am Ende des Tages liegt es ja an den Berechtigungen, nur wo und wer und mit dem Tool und genügend Zeit wird sich das schon ermitteln lassen.

 

Merci und VG.

[testperson 1.682]

Dann teile dem Kunden mit, was wie machbar wäre und was deine Empfehlung ist und mit welchen möglichen Konsequenzen zu rechnen ist. Der (zahlende) Kunde kann manchmal etwas mehr Druck bei einem Softwarehaus oder dem GF dort ausüben. 

 

vor 18 Minuten schrieb JustTheNextUser:

Ja wenn ich Zeit finde werde ich wie gesagt nochmal genauer schauen, ich habe schon echt viel Zeit versenkt, was mir wieder keiner bezahlt

Das bist du unterm Strich doch selber Schuld.

[JustTheNextUser 7]

vor 13 Minuten schrieb testperson:

Dann teile dem Kunden mit, was wie machbar wäre und was deine Empfehlung ist und mit welchen möglichen Konsequenzen zu rechnen ist. Der (zahlende) Kunde kann manchmal etwas mehr Druck bei einem Softwarehaus oder dem GF dort ausüben.

Habe ich bereits gemacht, ist dem Kunden aber recht egal. Mit den Konsequenzen lebt er und mit dem Softwarehaus wird er nicht reden... also von meiner Seite aus habe ich fertig. Der Kunde weiß Bescheid, mehr kann ich nicht tun.

 

vor 13 Minuten schrieb testperson:

Das bist du unterm Strich doch selber Schuld.

Richtig! War ja auch keine Beschwerde.

Ich habe allerdings (leider) eine gewisse Technik-'Ehre' und Interesse/Neugier mich mit einem Problem zu beschäftigen und es adequat zu lösen... das mag dumm sein, aber da bin ich zu sehr in meiner Berufung um das auf sich beruhen zu lassen. Auch wenn dann nochmal 2 Stunden am Wochenende versenkt werden.

bearbeitet 9. April 2021 von JustTheNextUser

[Weingeist 159]

Kämpfe auch immer wieder mal mit solchem Schmarrn. Das können übrigens auch grosse Firmen, nicht nur kleine. Im Industrie-Bereich wollen immer alle Admins sein. Für alles. Sonst oft nichtmal Support, spricht per Script reversibel gestalten. Absolut üblich. Gibt dann teilweise sehr viel Arbeit das aufzudröseln, Service-User zu erstellen für bestimmte Szenarien, Aufgaben mit Trigger, die Programmkompatibilität zu bemühen usw. Der totale Wahnsinn.

 

Bei sehr vielen solcher Probleme war am Ende Schuld, dass eben die lokale Rechte-Erhöhung mit Remote-Laufwerken nicht harmoniert. Sprich das Problem ist sehr oft, dass eben gewisse Funktionen mit dem lokalen Admin eskaliert werden und nicht wirklich mit dem angemeldeten Benutzer, selbst wenn dieser auch Mitglied der Admins ist. Dieser hat aber auf das Remote-Laufwerk gar keine Berechtigungen, ein Domain-Admin allerdings schon. Ein Mitglied der lokalen-Admin-Gruppe des Remote-Laufwerks-Computers (in Deinem Fall der DC) oft ebenso.

 

Ein weitere Möglichkeit ist, dass eben der Build-In lokale Admin mit dem dann eigentlich ausgeführt wird, das Netzlaufwerk gar nicht zu Verfügung hat. Da ist aber dann eher die Meldung, dass die Quelle nicht da ist. Kommt aber immer darauf an wie eben der Zugriff implementiert wurde und wer die Fehlermeldung schickt. Windows oder das Programm. Sprich ob die Meldung generell kommt wenn schreiben nicht möglich ist oder nur wenn keine Berechtigungen da ist, Verzeichnis aber schon.

 

Je nach dem gibt es verschiedene Ansätze das zu lösen, allesamt halt etwas "Krücken"

- DFS-Ordner für die Installation zbsp. statt auf das Remote-Laufwerk auf ein lokales Laufwerk mit gleichem Buchstaben und gleicher Struktur und anschliessend mit eigenem Script die Daten kopieren

- Sicherstellen, dass die Kopierbefehle auf das Netzlaufwerk mit dem aktuell angemeldeten User und nicht mit dem allfällig eskalierten Build-In-Admin ausgeführt werden (evtl. Installer modifizieren und sonstige Spässe)

- Sicherstellen, dass auch der Build-In Admin der Maschine wo es aufgeführt ist, auf dem entfernten Verzeichnis Zugriff hat