[b0toxXP]

Hi,

also ich habe mal ne kleine frage

Ich habe WinXP Home + SP2 installiert.

Nun möchte ich aus sicherheitsgründen dauerhaft als Eingeschränkter Nutzer arbeiten, jedoch benötigen manche Programme (so zum Beispiel Lexware Financial Office Pro) Admin Rechte.

Ich wusste dafür mal einen Parameter den ich auf z.B. einer Desktopverknüpfung von Lexware hinzugefügt habe. Jedoch ist mir dieser entfallen ... ich weiß aber das ein verweiß ins Systemverzeichnis von Windows mit bei war oO

Jedenfalls lief es dann so ab ... das sich dann beim erstmaligem Starten des Programmes als eingeschr. Nutzer eine Console Öffnete und ich das Admin Passwort eingeben musste, anschließend gings dann immer automatisch

Würde mich tierisch freuen wenns jemand wüsste

Gruß

B0toxXP

Habe die Lösung eben selbst gefunden

Danke an alle die ihren Kopf anstrengten :-p

Und hier die Lösung:

Eine Verknüpfung auf das Programm erstellen
- Eigenschaften der Verknüpfung öffnen
- Beim Ziel folgendes eingeben
%systemroot%\system32\runas.exe /savecred /user:administrator programmpfad

z.B.
%systemroot%\system32\runas.exe /savecred /user:administrator "C:\Program Files\Ahead\Nero\nero.exe"

Der Parameter /savecred dient dazu, dass nur beim ersten Start des Programms die Eingabe des Passworts notwendig ist, danach bleibt es gespeichert und muss nicht erneut eingegeben werden.

[Rika]

Wenn du das Admin-Passwort speicherst, dann kannst du dir auch gleich wieder Adminrechte geben...

Wie wär's, wenn du
1. mal Filemon und Regmon anstrengst, um herauszufinden, welche Berechtigungen das Programm benötigt?
2. statt Passwortspeicher-Orgien mal lieber Process Token Impersonations nimmst?

[valeron]

@Rika:
heißt das es bringt garnichts als eingeschränkter nutzer zu arbeiten wenn man auch nur einem programm adminrechte einräumt; oder bringt das insgesammt doch mehr sicherheit und ist nur
ein kleiner risikofaktor?

[Rika]

Zitat

heißt das es bringt garnichts als eingeschränkter nutzer zu arbeiten wenn man auch nur einem programm adminrechte einräumt;

Das ist nicht das Problem. Das Problem ist, daß du an einer gewissen Stelle (wenn auch automatisiert) das Admin-Passwort an den zugehörigen Dienst (SecondaryLogon) übergibst - es also lesbar ist, insbesondere von Malware oder böswilligen Benutzern.

Die Alternative ist halt Process Token Impersonation. Dort sorgt ein Dienst, der bereits mit Adminrechten läuft, daß das Programm mit Adminrechten gestartet wird, sobald der Benutzer ein Signal gibt - natürlich nur mit Whitelist, versteht sich. Windows kann das zwar, hat aber keine GUI dafür - da nimmt man dann z.B. "PolicyMaker Application Security".

Generell ist's aber so, daß du so etwas erst dann in Betracht ziehen solltest, wenn das Programm sich partout nicht mit Benutzerrechten zum Laufen bekommen lässt. Zu diesem Zwecke sollte man halt überprüfen, welche Berechtigungen das Programm benötigt.

[dante]

Kann es sein, dass "PolicyMaker Application Security" Windows XP Prof bzw. gpedit voraussetzt? Bekommnämlich kein Snap-In hin bzw. kann das Prog nicht starten.

dante

[Rika]

Eigentlich nicht.
Wie schon gesagt: Erst versuchen, mit Filemon und Regmon herauszufinden, was das Programm benötigt und, wenn akzeptabel, die entsprechenden Berechtigungen einräumen.

[dante]

Dann bekomm ichs wohl nicht hin
Um überhaupt Reg- oder Filemon zum laufen zu bekommen wärs halt net schlecht.

dante

[Rika]

Remon und Filemon brauchen natürlich Adminrechte. Aber bitte nur temporär und nicht mit gespeichertem Passwort. Oder halt mit PolicyMaker. :-)
Idealerweise benutzt man dann auch einfach nur die SecondaryLogon-Funktion in der Verknüpfung und nicht runas.

Jedenfalls solltest du damit das Programm idR zurechtgebogen bekommen. Ich kann dir ja bei der Auswertung der Logfiles behilflich sein, wenn du's nicht alleine hinbekommst.

Dieser Beitrag wurde von Rika bearbeitet: 07. Februar 2006 - 21:49

[Sina]

Lese sehr interessiert mit, denn es gibt eine Menge Programme, die Adminrechte benötigen - weshalb ja vermutlich so viele Leute auch mit einem Adminkonto unterwegs sind und nicht mit einem eingeschränkten Benutzerkonto – aber was ist

 Zitat (Rika: 07.02.2006, 21:48)

Remon und Filemon

?

Sina

[Talla]

Das sind kleine Programme von http://www.sysinternals.com die dir Datei bzw. Registry zugriffe eines bestimmten Programms anzeigen können, so dass du sehen kannst was für Rechte(z.b. schreibrechte auf bestimmte Dateien usw.) das Programm brauch.

Nen grundsätzliches Problem ist ja, das die meisten Programme(gerade die nicht mehr taufrischen) nur Adminrechte benötigten, weil sie unsauber programmiert sind, und z.b. Einstellungen im eigenen Installationsordner speichern wollen. Nur deshalb ist der Standarduser unter XP auch Admin, weil man sich gefürchtet hat, das die meisten Programme net laufen, bzw. der DAU zu unerfahren ist, um das zu ändern. Mit Vista zieht man das jetzt wohl aber endgültig durch und ist standardmäßig eingeschränkt und da haben dann die Programme die falsch programmiert sind, Pech.

[DK2000]

@b0toxXP:

Für Nero gibt es ja Nero Burning Rights. Mit dem Teil kann man dann auch einem Eingeschränkten Nutzer Rechte zum Brennen geben.

Und für alles andere kann man auch das Application Compatibility Toolkit verwenden, wobei ich mir momentan nicht sicher bin, ob das mit der Home Version läuft.

Zitat

Nen grundsätzliches Problem ist ja, das die meisten Programme(gerade die nicht mehr taufrischen) nur Adminrechte benötigten, weil sie unsauber programmiert sind, und z.b. Einstellungen im eigenen Installationsordner speichern wollen.

Soetwas kann man z.B. mit dem Application Compatibility Toolkit umgehen. Die Anwendung will zwar nach wie vor in ihrem Installationsordner speichern, darf sie aber nach wie vor nicht, stattdessen wird der Schreibzugriff in einer nachgebildeten Ordnerstruktur innerhalb des Profilverzeichnisses umgeleitet. Die Anwendung bekommt davon aber nichts mit und läuft einwandfrei weiter, auch ohne Adminrechte.

[Talla]

Zitat (DK2000: 08.02.2006, 13:21)

Soetwas kann man z.B. mit dem Application Compatibility Toolkit umgehen. Die Anwendung will zwar nach wie vor in ihrem Installationsordner speichern, darf sie aber nach wie vor nicht, stattdessen wird der Schreibzugriff in einer nachgebildeten Ordnerstruktur innerhalb des Profilverzeichnisses umgeleitet. Die Anwendung bekommt davon aber nichts mit und läuft einwandfrei weiter, auch ohne Adminrechte.

Aber das ist auch nur Symptome bekämpfen und nicht die Ursache angehen! Gerade viele Hobbientwickler halten sich nicht an solchen Vereinbarungen wo was wie geschrieben werden sollte. Eventuell sollte man da mal mehr aufklären.

[DK2000]

Gut, das ist richtig, aber man hat damit zumindestens die Möglichkeit, das Problem zu umgehen und die Anwendung dann doch noch ohne Adminrechte zu benutzen.

Allerdings betrifft das Problem nicht nur Hobbyprogrammierer. Es gibt genug kommerzielle Software, welche zwar das Logo "Designed for Windows XP" trägt, aber von %USERPROFILE%\Anwendungsdaten bzw. %USERPROFILE%\Lokale Einstellungen\Anwendungsdaten haben die dennoch nichts gehört. Die Anwendugen wollen munter in ihrem Installationsverzeichnis schreiben und einige sogar in %WINDIR% bzw. %WINDIR%\System32. Das sind dann die Anwendungen, die mich am Meisten nerven. Aber was solls, vielleicht wird es ja mit Vista besser und die Programmierer lernen etwas dazu...

[Sina]

@ Talla @ DK2000 herzlichen Dank für Eure Antworten, werde mal Application Compatibility Toolkit und http://www.sysinternals.com ausprobieren.

 Zitat (DK2000: 08.02.2006, 13:34)

vielleicht wird es ja mit Vista besser und die Programmierer lernen etwas dazu...

„Die Worte hör` ich wohl, es sei, es fehlt der Glaube“

Sina

EDIT
Wenn man dieses Application Compatibility Toolkit benutzen will, braucht man
(Zitat Anfang) Systemanforderungen
Unterstützte Betriebssysteme: Windows Server 2003, Windows XP, Windows XP Professional Edition Etwa 30 MB Festplattenspeicher für die vollständige InstallationMicrosoft .NET Framework 1.1
Microsoft SQL Server 2000 SP3a oder MSDE 2000 Release A (erforderlich für den Application Analyzer) (Zitat Ende)

Ich habe aber nur Microsoft NET Framework 2.0 und einen SQL Server habe ich meines Wissens schon grad gar nicht, es sei denn, der versteckt sich sonst wo...

Wenn man den Link MSDE 2000 Release A anklickt, kommt das da:

SQL Server 2005 Express Edition: Make it Easy
Watch this demo to see how easy it is to get, learn, and use SQL Server Express.

SQL Server 2005 Express Edition Features
Review the features in SQL Server Express Edition that make it ideal for developers of all levels to get started with creating productive data-driven applications.

How to Obtain SQL Server 2005 Express Edition
Locate licensing information for the different types of licenses available for SQL Server Express Edition.

SQL Server 2005 Express Edition Overview
Learn more about how SQL Server Express is engineered for data-driven applications, client applications that need an embedded database, and basic Web sites.

System Requirements for SQL Server 2005 Express

Ich nehme mal an, das kostet?

Dieser Beitrag wurde von Sina bearbeitet: 08. Februar 2006 - 14:24

[DK2000]

Den SQL Server braucht man ur für den Application Analyzer, den braucht man aber wiederum nicht zwingend für das Toolkit. Für den Hausgebrauch reicht das Modul Compatibility Administrator des Toolkits vollkommen, welches keine SQL Datenbank benötigt.

Beim .NET Framework 1.1 mir da jetzt nicht sicher, ob das 2.0 ausreicht. Müsste aber theoretisch.