Benötigtes Recht ermitteln
Hallo zusammen,
gibt es unter Windows 7 Professional eine Möglichkeit, zu ermitteln, auf welche Rechte (nicht NTFS-Berechtigungen) ein Programm zurückgreift?
Der Hintergrund ist folgender: Wir benutzen die Web-Exportfunktion von Lotus Organizer 6.1, um unsere Gottesdienst- und Veranstaltungstermine auf unsere WebSite zu exportieren. Unter Windows XP war das kein Problem, aber nachdem wir nun auf Windows 7 umgestellt haben, geht es nicht mehr. Grundsätzlich funktioniert der Lotus Organizer problemlos, aber wenn ich in der Menüleiste im Menü Datei auf den Punkt Als Web-Seiten veröffentlichen anklicke passiert ... nichts
Als Administrator geht es allerdings, nur als Benutzer nicht. Da ich dem Benutzer bereits volle Schreibrechte auf das Programmverzeichnis gegeben habe, kann es an den NTFS-Berechtigungen eher nicht liegen (es sei denn, das Programm möchte ins Windows-Verzeichnis schreiben). Wir möchten unseren Sekretärinnen aber keine allgemeinen Administratorrechte geben. Aber vielleicht fehlt dem Programm ja nur ein ganz "bannales" Recht, welches man per GPO dem Benutzer zuweisen könnte. Daher die obige Frage ...
Danke im Voraus,
Sarek \\//
gibt es unter Windows 7 Professional eine Möglichkeit, zu ermitteln, auf welche Rechte (nicht NTFS-Berechtigungen) ein Programm zurückgreift?
Der Hintergrund ist folgender: Wir benutzen die Web-Exportfunktion von Lotus Organizer 6.1, um unsere Gottesdienst- und Veranstaltungstermine auf unsere WebSite zu exportieren. Unter Windows XP war das kein Problem, aber nachdem wir nun auf Windows 7 umgestellt haben, geht es nicht mehr. Grundsätzlich funktioniert der Lotus Organizer problemlos, aber wenn ich in der Menüleiste im Menü Datei auf den Punkt Als Web-Seiten veröffentlichen anklicke passiert ... nichts
Als Administrator geht es allerdings, nur als Benutzer nicht. Da ich dem Benutzer bereits volle Schreibrechte auf das Programmverzeichnis gegeben habe, kann es an den NTFS-Berechtigungen eher nicht liegen (es sei denn, das Programm möchte ins Windows-Verzeichnis schreiben). Wir möchten unseren Sekretärinnen aber keine allgemeinen Administratorrechte geben. Aber vielleicht fehlt dem Programm ja nur ein ganz "bannales" Recht, welches man per GPO dem Benutzer zuweisen könnte. Daher die obige Frage ...
Danke im Voraus,
Sarek \\//
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 236534
Url: https://administrator.de/forum/benoetigtes-recht-ermitteln-236534.html
Ausgedruckt am: 24.04.2025 um 00:04 Uhr
13 Kommentare
Neuester Kommentar
Moin,
Ich würde einfach mal mit den Sysinternals Tools von MS, genauer dem Process Explorer mal nachschauen, was da schiefgeht. zur Not reicht eventuell auch das ältere filemon, was aber nicht mehr so einfach herunterzuladen ist.
lks
Ich würde einfach mal mit den Sysinternals Tools von MS, genauer dem Process Explorer mal nachschauen, was da schiefgeht. zur Not reicht eventuell auch das ältere filemon, was aber nicht mehr so einfach herunterzuladen ist.
lks
Zitat von @Lochkartenstanzer:
Ich würde einfach mal mit den Sysinternals Tools von MS, genauer dem Process Explorer mal nachschauen, was da schiefgeht.
Ich würde einfach mal mit den Sysinternals Tools von MS, genauer dem Process Explorer mal nachschauen, was da schiefgeht.
Was Du da verlinkt hast, ist nicht der Process Explorer, sondern der Process Monitor, aber ich nehme an, daß es dann auch der sein sollte? Den habe ich also gerade mal benutzt, aber der schmeißt ja so viele Informationen raus, dass es schwierig ist, die vernünftig auszuwerten. Gibt es eine Möglichkeit, nur die Aktivitäten anzuzeigen, die unmittelbar oder mittelbar von dem Prozess org6.exe hervorgerufen wurden?
Danke im Voraus,
Sarek \\//
Zitat von @SarekHL:
> Zitat von @Lochkartenstanzer:
>
> Ich würde einfach mal mit den Sysinternals Tools von MS,
genauer dem Process Explorer mal nachschauen, was da schiefgeht.
Was Du da verlinkt hast, ist nicht der Process Explorer, sondern der Process Monitor, aber ich nehme an, daß es dann auch
der sein sollte?
> Zitat von @Lochkartenstanzer:
>
> Ich würde einfach mal mit den Sysinternals Tools von MS,
genauer dem Process Explorer mal nachschauen, was da schiefgeht.
Was Du da verlinkt hast, ist nicht der Process Explorer, sondern der Process Monitor, aber ich nehme an, daß es dann auch
der sein sollte?
Jepp, der Vorläufer hiees Process Explorer, iirc.
Den habe ich also gerade mal benutzt, aber der schmeißt ja so viele Informationen raus, dass es schwierig
ist, die vernünftig auszuwerten. Gibt es eine Möglichkeit, nur die Aktivitäten anzuzeigen, die unmittelbar oder
mittelbar von dem Prozess org6.exe hervorgerufen wurden?
ist, die vernünftig auszuwerten. Gibt es eine Möglichkeit, nur die Aktivitäten anzuzeigen, die unmittelbar oder
mittelbar von dem Prozess org6.exe hervorgerufen wurden?
Über das Filtermenü sollte man passende Filter definieren können.
lks
Lann man bestimmt, wenn man weiß, wie. Ich habe es bisher jedenfalls nicht geschafft. Wichtig wäre ja auch, daß auch Vorgänge angezeigt werden, die nur mittelbar von org6.exe hervorgerufen wurden. Da hilft mir dann die "Parent PID" nicht mehr weiter.
Hallo Sarek.
Beispiel:
Das ganze kannst du auch hier nachlesen:
Was du alternativ zum Procmon hernehmen kannst, ist der Microsoft Standard User Analyzer aus dem Microsoft Application Compatibility Toolkit.
Grüße Uwe
Zitat von @SarekHL:
Lann man bestimmt, wenn man weiß, wie. Ich habe es bisher jedenfalls nicht geschafft.
Kein Problem, vereinfachen kanst du dir das wenn du die Zielscheibe im ProcessMonitor auf die Applikation ziehst, welche du beobachten möchtest:Lann man bestimmt, wenn man weiß, wie. Ich habe es bisher jedenfalls nicht geschafft.
Beispiel:
auch Vorgänge angezeigt werden, die nur mittelbar von org6.exe hervorgerufen wurden. Da hilft mir dann die "Parent PID" nicht mehr weiter.
Da es dir hier vorrangig um fehlende Zugriffsrechte geht, kannst du im Filter mit dem Feld Result auf ACCESS DENIED filtern. Dann siehst du schon mal wo es Probleme mit den Zugriffsrechten gibt. Ebenso kannst du die ganzen SUCCESS bzw. anderen überflüssigen Einträge ausfiltern indem du in der Liste einen Rechtsklick auf Success machst und dann Exclude SUCCESS... wählst. So lässt sich das ganze schon deutlich zusammenschrumpfen. Wenn du außerdem noch die Capture-Events auf die "wesentlichen" einschränkst => Registry und Filesystem, wird das ganze noch übersichtlicher.Das ganze kannst du auch hier nachlesen:
- Process Monitor - Hands-On Labs and Examples
- Using Microsoft Process Monitor to trace file-, rights- or registry related problems
Was du alternativ zum Procmon hernehmen kannst, ist der Microsoft Standard User Analyzer aus dem Microsoft Application Compatibility Toolkit.
Grüße Uwe
Zitat von @colinardo:
Kein Problem, vereinfachen kanst du dir das wenn du die Zielscheibe im ProcessMonitor auf die Applikation ziehst, welche du beobachten möchtest
Kein Problem, vereinfachen kanst du dir das wenn du die Zielscheibe im ProcessMonitor auf die Applikation ziehst, welche du beobachten möchtest
Guter Tipp, Danke!
Da es dir hier vorrangig um fehlende Zugriffsrechte geht,
Hm, meinst Du mit Zugriffsrechten die NTFS-Berechtigungen? Ich denke gerade nicht, dass es um die geht. Ich habe der Benutzergruppe ja schon Schreibrechte auf das Programmverzeichnis gegeben. Meine Vermutung ist eher, daß dem Benutzer ein Recht fehlt statt einer Berechtigung.
Vielleicht reden wir auch gerade aneinander vorbei. Ich habe in meiner Ausbildung mal gelernt, daß man als Berechtigungen die NTFS-Zugriffsberechtigungen (Schreiben, Lesen, Ändern usw.) bezeichnet und als Rechte solche Dinge wir "Darf sich interaktiv anmelden", "Debuggen von Programmen", "Erstellen globaler Objekte", "Annehmen der Clientidentität nach Authentifizierung" und so weiter.
Meine Frage wäre eher, wie ich herausfinde, welche Rechte ein Programm braucht, nicht welche Berechtigungen. Mir scheint, daß der ProcessMonitor dafür gar nicht das adäquate Mittel ist ... oder habe ich was übersehen?
Das Programm hat immer nur so viel "Rechte" wie der User mit seinem Security-Token mitbringt, sofern es mit seinem Account gestartet wurde. Normalerweise sollte der ProcMon wenn es Probleme mit einem Recht gibt irgendwo zumindest ein paar Access Denied Meldungen auswerfen => ist das Programm durch den User mit zu wenig "Rechten" ausgestattet hat es also kein "Zugriff" auf bestimmte Objekte; hängt ja alles zusammen.
Bisher habe ich noch kaum ein Programm mit solchen Problemen nicht wieder mit dem ProcMon auf die Beine helfen können, man muss ihn nur zu bedienen wissen...manche App aber lässt sich auf Verderb und Gedeih nicht umstimmen ohne Admin-Rechte zu arbeiten.
Wenn du mit dem "Programmverzeichnis" "C:\Program Files (x86)" meinst, dies unterliegt durch die UAC besonderem Schutz auch bei Schreibrechten, das Problem könnte also daher herrühren. Solche Programme kann man dann sehr oft dadurch auf die Beine helfen indem man sie in ein anderes Verzeichnis außerhalb von "c:\program Files (x86)" installiert.
Des weiteren wären da Registry-Zugriff, und Funktionsaufrufe die Administrator-Rechte benötigen.
Ältere Programme benutzen nutzen oft nicht die dafür vorgesehenen APIs um den UAC Dialog zu triggern wenn mehr Rechte benötigt werden, diese halten sich also nicht an die empfohlenen Designregeln für Windows Applikationen. Dann landen Schreiboperationen oft im VirtualStore im AppData-Verzeichnis.
Grüße Uwe
Bisher habe ich noch kaum ein Programm mit solchen Problemen nicht wieder mit dem ProcMon auf die Beine helfen können, man muss ihn nur zu bedienen wissen...manche App aber lässt sich auf Verderb und Gedeih nicht umstimmen ohne Admin-Rechte zu arbeiten.
Wenn du mit dem "Programmverzeichnis" "C:\Program Files (x86)" meinst, dies unterliegt durch die UAC besonderem Schutz auch bei Schreibrechten, das Problem könnte also daher herrühren. Solche Programme kann man dann sehr oft dadurch auf die Beine helfen indem man sie in ein anderes Verzeichnis außerhalb von "c:\program Files (x86)" installiert.
Des weiteren wären da Registry-Zugriff, und Funktionsaufrufe die Administrator-Rechte benötigen.
Ältere Programme benutzen nutzen oft nicht die dafür vorgesehenen APIs um den UAC Dialog zu triggern wenn mehr Rechte benötigt werden, diese halten sich also nicht an die empfohlenen Designregeln für Windows Applikationen. Dann landen Schreiboperationen oft im VirtualStore im AppData-Verzeichnis.
Grüße Uwe
Zitat von @colinardo:
Bisher habe ich noch kaum ein Programm mit solchen Problemen nicht wieder mit dem ProcMon auf die Beine helfen können, man muss ihn nur zu bedienen wissen...manche App aber lässt sich auf Verderb und Gedeih nicht umstimmen ohne Admin-Rechte zu arbeiten.
Bisher habe ich noch kaum ein Programm mit solchen Problemen nicht wieder mit dem ProcMon auf die Beine helfen können, man muss ihn nur zu bedienen wissen...manche App aber lässt sich auf Verderb und Gedeih nicht umstimmen ohne Admin-Rechte zu arbeiten.
Das Problem ist gelöst, und es hatte offenbar nichts mit Rechten oder Berechtigungen zu tun. Ich habe zufällig diesen Beitrag gefunden und habe dann auf gut Glück mal versucht, wie dort empfohlen, mich als der Benutzer anzumelden, der den Organizer installiert hat, den Registrierungsschlüssel HKCU\Software\Lotus\Organizer\99.1\ zu exportieren und beim gewünschten Benutzer wieder zu importieren. Und siehe da, der Web-Export geht!!! Warum dieser Würgaround unter Windows 7 notwendig ist (unter XP war das nie ein Problem), weiß ich nicht, aber solange es läuft, ist es mir auch egal. Trotzdem Danke für Eure Tipps ...
Warum dieser Würgaround unter Windows 7 notwendig ist (unter XP war das nie ein Problem), weiß ich nicht,
na ja, wenn da steht "compatible with Windows® 2000 and Windows XP" muss man sich auf neueren OS halt ab und zu auf solche Probleme einstellen. Hat ja schon einige Jahre auf dem Buckel 
Schön das du es trotzdem gelöst hast.
Grüße Uwe
Hi.
Eine Frage noch der Vollständigkeit halber an Uwe. Du schriebst:
Eine Frage noch der Vollständigkeit halber an Uwe. Du schriebst:
Wenn du mit dem "Programmverzeichnis" "C:\Program Files (x86)" meinst, dies unterliegt durch die UAC besonderem Schutz auch bei Schreibrechten
Was meinst Du damit? Ich kenne keinen "besonderen" Schutz für diesen Ordner.
@dww
na ja, hatte das wohl etwas krumm ausgedrückt, meinte damit das Integrity Level (Critical) das für den Ordner gesetzt ist und der Trusted Installer den Besitz der Ordner hält, so dass man selbst als Admin noch bestimmte Aktionen bestätigen muss. Aber das lässt sich ja ändern.
Grüße Uwe
na ja, hatte das wohl etwas krumm ausgedrückt, meinte damit das Integrity Level (Critical) das für den Ordner gesetzt ist und der Trusted Installer den Besitz der Ordner hält, so dass man selbst als Admin noch bestimmte Aktionen bestätigen muss. Aber das lässt sich ja ändern.
Grüße Uwe
Moin.
Auf den Programmordnern ist kein Integrity-Level gesetzt (unlabeled) - insofern würde er, sobald er den Nutzer per NTFS-ACL berechtigt, damit keine Probleme haben. Und was meinst Du mit critical?
Auf den Programmordnern ist kein Integrity-Level gesetzt (unlabeled) - insofern würde er, sobald er den Nutzer per NTFS-ACL berechtigt, damit keine Probleme haben. Und was meinst Du mit critical?
vergess es, war gestern doch etwas zu spät ... da spielen einem die Geister doch ab und zu einen Streich 
