User erlauben ein einzelnes Programm mit Administratorrechte zu starten.

???
UAC im Wege?

Hi,
um es kurz zum machen: Sooo wie Du fragst, geht das nicht.
Wenn der Benutzer Anmeldedaten eines Administrators kennt, dann kannst Du kaum verhindern, dass er diese nicht auch für andere Programme nutzt oder sich gar komplett am Desktop mit diesem Benutzer anmeldet.

Was Du machen könntest, wäre z.B. ein Powershell-Script zu schreiben, in welchem Du den Prozess mit alternativen Anmeldedaten startest. Allerdings hättest Du dann eine Datei rumliegen, in welcher die Zugangsdaten eines Administrators drin ständen. Auch wenn Du das so gut es geht verschleiern würdest, sodass z.B. nur ein in Powershell versierter Anwender die Anmeldedaten extrahieren könnte, hättest Du doch dieses Sicherheitsleck.

Lass mich raten: Du hast eine Anwendung, die nur dann richtig funktioniert, wenn Du mit einem lokalen Admin angemeldet bist?
Falls ja:
Der richtige Weg ist hier, herauszufinden, wo der Programm-Prozess mit welchen Rechten zugreifen können muss, und dann für diese Ressourcen auch den Nicht-Admins die erforderlichen Rechte zu erteilen. Meistens ist das im Dateisystem irgendwo unterhalb von %ProgramFiles% oder in der Registry im HKLM. Das kannst Du z.B. mit dem Process Monitor von den Sysinternals feststellen oder einfach beim Hersteller erfragen.
Oder Du nennst uns das konkrete Programm. Vielleicht kennt das hier jemand und kann Dir aus eigener Erfahrung weiterhelfen.

E.


Edit:
Was auch noch gehen würde:
- im AD alternativen Benutzer erstellen ohne Roaming Profile
- im AD GPo erstrellen, welche nur für die betreffenden Workstations wirkt und dort diesen alternativen Benutzer zum lokalen Admin macht (Stichwort: "Eingeschränkte Gruppen" -> Aber aufpassen, wenn Du das zum erstem Mal machst dann vorher belesen!
- im AD GPO erstellen welche nur für diesen alternativen Benutzer wirkt und für diesen einstellt, dass er nur zugelassene Anwendungen starten darf und dann diese eine Anwendung dort eintragen.
- auf den Workstation die GPOs aktualisieren (gpupdate oder booten)

Dann müsste folgendes passieren:
Wenn der Benutzer sich am PC anmeldet, sei es nun komplett am Desktop oder über "ausführen als", dann ist er dort zwar lokaler Admin, kann aber bloß diesen einen Prozess starten. Theoretisch. Habe das so noch nie mit einem Admin-User gemacht. Kann auch sein, dass das Einschränken der Prozesse mit Mitgliedern der "Administratoren" gar nicht geht.

E.

Nicht ganz. Das habe ich auch schon mit VB Scripten gemacht. Diese sollte man dann aber mit gewissen Freeware-Tools (Bsp.: VBS to EXE) in eine Exe-Datei verpacken, die dann alles Startet, uns schon ist das ganze Fertig ohne viel Aufwand.

Guten Abend,
das ähliche Problem haben wir vor wenigen Wochen im Thread Anwendung starten ohne lokale Admin-Rechte aufgearbeitet.


Gruß,
Dani

@Dani: dort hat der Threadersteller ja irgendwann aufgehört, mitzuwirken. Es ist bei dieser häufigen Frage nur allzuoft so, dass der Fragesteller etwas sucht, um sein Gewissen zu beruhigen. Dass es dann "nicht perfekt" sicher ist, stört ihn nicht. Dass "nicht perfekt" leider genau genommen sogar abschließend betrachtet "vollkommen unsicher" heißt, ist dann seltsamerweise häufig egal.

Zu den Kommentaren hier:
@templier: Dein vbs2exe hat keinen großen Schutzeffekt. Es wird zur Laufzeit entpackt und die temporäre vbs-Datei ist dann sichtbar mit Klartext-Kennwort.

In dem von Dani verlinkten Thread habe ich hier Anwendung starten ohne lokale Admin-Rechte viel dazu geschrieben. Fazit: es geht nicht auf sichere Weise. Man kann lediglich 3rd-party-Programme nutzen, wie zum Beispiel Powerbroker Desktop, der kommt der Ideallösung nahe.

@DerWoWusste
Habe ich leider hinterher auch gesehen. Aber es gibt nochmals 2-3 Threads zu dem Thema. Ich meine bei meiner Hinweis auf den Patch sollte man natürlich davor noch einspielen.


Gruß,
Dani

Moin Dani.

Nö, die Aufgabenplanung ist non-interactive, wenn sie mit hohen Rechten benutzt wird, also das damit gestartete Programm ist unsichtbar und erlaubt dem User keine Interaktion.

Das ist schon so - Da ich aber eine gewisse Grundsicherheit (Firewalls, Virenscanner, DMZ, etc....) in einem Firmennetzwerk voraussetze ist das ein gangbarer Weg ohne viel Aufwand. Ein anderer Weg wäre sicherlich noch eine EXE in einer Programmiersprache (Visual Basic, etc.) zu schreiben in welcher diese Informationen "verpackt" sind.

@templier
Wie können die genannten Mechanisen dafür sorgen, dass das Script samt Kennwort im Klartext nicht lesbar ist? Klär uns bitte auf.


Griß,
Dani

Hi Dani,

was soll ich denn hier "Aufklären"? Das waren doch einfach nur Securitiy Beispiele um sich generell gegen Angriffe (externe/interne) zu schützen?

Starte doch mal ein Programm einfach mit VBS. Beispiel:

set var = CreateObject("Wscript.shell")
var.run "notepad.exe"

Wie willst Du denn da innert von Millisekunden das Script auslesen können? Kläre DU mich bitte doch erst einmal hier auf? Selbst wenn Tools wie "VBS to Exe" dieses Script temporär Öffen/Abspeichern, dann wird es ja sowieso sofort wieder geschlossen und gelöscht? Und da man als Benutzer noch nicht mal den Namen des Scriptes kennt, weil dies ja innert der EXE-Datei verpackt ist, was soll daran also schlecht sein? Zumal sie das Script niemals auf der Festplatte finden können?

Grundsätzlich tendiere ich persönlich dazu, hier eine EXE in einem Programm (Beispiel. Visual Basic) zu schreiben, was auch nicht viel Aufwand ist.

Aber, ich bin nach wie vor der Meinung das dies ein gangbarer Weg ist um genau solche Dinge unkompliziert durch die Administration zur Verfügung stellen zu können. Zumal eure Argumente hier, für mich, nicht ziehen (Script auslesen).

Hier kläre DU mich bitte mal auf, wie das Script gefunden werden kann/könnte und wie es dann ausgelesen wird? Bedenke, das es bis zum "Start" immer in der EXE-Datei verpackt ist. Hier bin ich mal auf Deine/Eure Antworten gespannt. Und keine Bange: Ich lerne auch immer wieder gerne mal dazu

Viele liebe Grüsse
Ralph

Hi,

du könntest es wie folgt versuchen:

1. Kopiere die Anwendung in ein Verzeichnis außerhalb von ‚Programme‘ oder ‚Programme(x86)‘.
2. Öffne die Eigenschaften des ‚neuen Verzeichnis‘, wechsel in den Reiter Sicherheit und klicke ‚bearbeiten‘.
3. Klicke ‚hinzufügen‘ und füge den Benutzer hinzu, der die Anwendung (als Admin) ausführen soll. In den Berechtigungen für den User setze den Haken bei ‚vollzugriff‘.
4. Öffne ‚start‘ – ausführen (cmd) – regedit
5. Suche (STRG + F) nach dem Namen der Anwendung (Beispiel.exe).
6. Rechtsklick auf die gefundene Anwendung, Berechtigungen auswählen.
7. Hier nochmal den Usernamen eingeben und erneut ,vollzugriff‘ geben.
8. Erstelle eine Verknüpfung der Anwendungs-EXE, öffne mit Rechtsklick deren Eigenschaften und setze den Haken bei ‚immer als Administrator ausführen‘.
9. Fertig!

Hi Templier.

Später. Man kann undelete-Tools benutzen und wird recht bald Erfolg haben. Natürlich brauchen diese Adminrechte, aber mit ein wenig Fantasie lässt sich auch das regeln, offline zum Beispiel oder einfach von dem über die vbs gestarteten Programm aus, das hat ja bereits alle Rechte (shell-breakout/Shatter-Attack und Konsorten machen es möglich).

Sicher ist das nicht und deswegen nicht empfehlenswert. Man kann so handeln, klar ist das besser als nichts, nur würde ich auch Risiken ausdrücklich benennen. Die genannte "Grundsicherheit" ändert daran eben nichts.

Womit wir dann aber schon wieder bei den internen Sicherheitsmechanismen wären, oder nicht? Und vormachen brauchen wir uns alle nichts: Wenn genug kriminelle Energie vorhanden ist, lässt sich alles umgehen. Da die Mehrheit der Benutzer diese Energie aber nicht hat, bleibe ich weiter bei meiner Meinung

Risiken hat mal (leider) immer noch überall. Bisher schafft man es eben noch nicht ein absolut "sicheres" System hinzustellen, da gewisse Benutzer immer wieder mal erhöhte Rechte brauchen. Und wenn man einem Benutzer hinter einer Verknüpfung eine "neue EXE" platziert - Wie will der denn erst auf den Gedanken kommen, das diese ein Script startet? Das ist für den "normalen" Benutzer doch gar nicht Transparent? Denn er klickt darauf und sein Programm startet? Wie will er auf den Gedanken kommen, das sich hier irgendwo, vor dem eigentlichen Start, ein Adminkonto mit Passwort verbirgt?

Viele Grüsse
Ralph

Warum? Startet es denn dann auch noch - Es könnte ja sein, das bei der Installation Registryeinträge gemacht wurden die genau diesen Pfad einschliessen?
Warum nicht gleich auf dem "Original Ordner"?
Stimmt, das eignet sich aber dann eher als "@bettlektuere". Mach das mal mit etlichen Anwendungen/Benutzern? Das wird ja gar nicht mehr Überschaubar, geschweige denn Administrierbar? Von einer Dokumentation erst überhaupt nicht zu Reden. Zumal der/die Benutzer dann volle Rechte auf den gesamten(!) Ordner haben? Was Löschen/Editieren/Umbenennen...usw. von Dateien mit einschliesst? Und das "nur" um ein Programm zu starten? Finde ich etwas Overdressed.

Ok... lass mal lieber diese Diskussion nicht ausweiten, nur soviel: ich bin kein Freund von "security by obscurity"

An @AlexanderME: wann kehrst Du eigentlich zu Deinem Thread zurück?