Statt runas: Einzelne Programme als Admin starten mit dem kostenlosen ASAP

    ASAP von ask:usEs ist eine aner­kannte Best Practice, End­benutzer auf ihren PCs nicht mit admini­strativen Privi­legien auszu­statten. Wenn ein­zelne Pro­gramme oder Aktionen erhöhte Rechte erfor­dern, dann würde es aus­reichen, diese nur dafür zu gewähren. ASAP dient genau diesem Zweck und erfüllt ihn besser als runas.

    Während es unter XP noch der Normalfall war, dass Benutzer als lokale Admini­stratoren arbeiteten, entfällt diese Notwendigkeit seit Windows 7 weit­gehend. Gängige Aufgaben lassen sich seitdem nämlich im Kontext eines Standard­benutzers erledigen.

    Erhöhte Rechte fallweise erforderlich

    Dennoch kann auch weiterhin der Fall auftreten, dass Anwender für einfache administrative Aufgaben oder für das Installieren von Software zumindest vorüber­gehend erhöhte Rechte benötigen.

    Microsoft sieht das Dienst­programm runas vor, um einzelne Programme unter einer anderen Kennung auszuführen. Auf diese Weise kann man es auch mit admini­strativen Privilegien starten:

    runas /user:contoso\MyAdmin cmd.exe

    In diesem Beispiel würde die Eingabeaufforderung im Kontext des Kontos von MyAdmin starten. Dies setzt allerdings voraus, dass dem Benutzer das Kennwort für diesen Account bekannt ist, dessen Eingabe runas verlangt.

    Runas verlangt Weitergabe von Passwörtern

    Nachdem man in der Regel keine Admin-Passwörter weitergeben möchte, könnte der Systemverwalter das Kommando am Rechner des Mitarbeiters selbst eingeben und zusätzlich den Schalter /savecred verwenden, so dass sich Windows das Passwort merkt und es der Benutzer nicht kennen muss, um runas für dieses Konto auszuführen.

    Die mit runas /savecred gespeicherten Anmeldedaten kann man in der Systemsteuerung wieder entfernen.

    Der gravierende Nachteil dieses Vorgehens besteht aber darin, dass der betreffende Mitarbeiter künftig beliebige Programme im Kontext dieses admini­strativen Kontos starten kann. Erst wenn man die Anmelde­daten in der System­steuerung unter Benutzer­konten => Anmelde­informations­verwaltung löscht, erwartet runas die erneute Eingabe des Passworts.

    ASAP als Alternative

    Wesentliches Anliegen der Heilbronner ask:us GmbH ist es, mit ASAP genau diese Nachteile von runas zu vermeiden. Entsprechend muss man ein Admin-Password weder weitergeben noch permanent für den unbeschränkten Einsatz im System speichern.

    Hinzu kommt, dass es sich bei runas um ein Tool für die Kommando­zeile handelt, das für die meisten Endbenutzer nicht praktikabel ist. Auch in dieser Hinsicht bietet ASAP eine bessere Alternative.

    Verschlüsselte Verknüpfungen erstellen

    Das Konzept des Tools besteht darin, dass der System­verwalter eine Verknüpfung für ein Programm erstellt, in der das Kennwort des privilegierten Kontos verschlüsselt abgelegt wird. Der Benutzer erhält dann typischer­weise ein Icon auf seinem Desktop, mit dem er das zugeordnete Programm wie gewohnt durch Doppelklick startet.

    Um eine solche verschlüsselte Verknüpfung erstellen zu können, bietet ASAP einen Wizard, wahlweise kann man direkt zu einem Dialog springen, der alle Einstellungen enthält. Das Tool muss natürlich auch auf all jene PCs verteilt werden, auf denen eine Verknüpfung vom Typ .eLnk gestartet werden soll.

    Wenn man den Wizard überspringt, kann man alle Einstellungen für die Verknüpfung in einem Dialog eingeben.

    Die Eingaben, die das Tool erwartet, sind überschaubar. So muss man ihm den Pfad zum gewünschten Programm inklusive eventueller Parameter, die Anmeldedaten des privilegierten Kontos und den Speicherort der Verknüpfung mitteilen.

    Hinzu kommen einige Optionen, wie etwa die Verwendung von Umgebungs­variablen in Parametern oder von relativen Pfadangaben. Weitergehende Features wie etwa die Beschränkung der Verknüpfung auf bestimmte User bzw. Gruppen oder das bloß einmalige Starten eines Programms bleiben für die kostenpflichtige Version reserviert.

    Die kostenlose Version des Tools lässt zudem nur die Eingabe eines lokalen Admin-Kontos zu, Domänen-User sind ebenfalls ASAP for Enterprise vorbehalten.

    Besitzer des Prozesses mit PowerShell anzeigen

    Nach dem Start eines Programms kann man sich mit Hilfe von PowerShell davon überzeugen, dass es unter dem korrekten Account läuft:

    Get-CimInstance Win32_Process -Filter "name = 'regedit.exe'" |
    Invoke-CimMethod -MethodName GetOwner

    Dieses Beispiel prüft, ob der Registriereditor unter dem angegebenen administrativen Konto gestartet wurde.

    Preis und Verfügbarkeit

    ASAP kann kostenlos von der Website des Herstellers heruntergeladen werden. ASAP for Enterprise gibt es dort auf Anfrage, die Lizenzkosten betragen zwischen 3 und 5 Euro pro PC. Es enthält auch eine Komponente, mit der sich verschlüsselte Verknüpfungen im Unternehmen bereitstellen und anzeigen lassen.

    7 Kommentare

    Bild von Michael Biber
    Michael Biber sagt:
    23. März 2017 - 16:00

    Vielen Dank für die Präsentation dieser Lösung! Dies würde in der Tat einen Teil erleichtern.

    Leider sehe ich aber die Notwendidgkeit erhöhter Rechte in einem anderen Bereich notwendiger: Die eigenen Updater einiger Programme (z.B. jusched, AV-Programmupdates). Diese benötigen für die Installation meist erhöhte Rechte (schreiben nach C:\Programme erfordert die meines Wissens bereits). Dazu sind die Zahl der Neuinstallationen zumindest bei uns im Vergleich sehr gering.

    Solange dieses Problem nicht behoben ist, sehe ich leider keine andere Möglichkeit, als den meisten Anwendern tatsächlich Adminrechte zu gewähren.

    Bild von Iris Wolff
    Iris Wolff sagt:
    28. März 2017 - 14:30

    Hallo Herr Biber,

    Ihrem Kommentar können wir nur zustimmen: selbst wenn Unternehmen ihre Updates über eine zentrale Softwareverteilung verwalten, kann es immer wieder Situationen geben, in denen die Mitarbeiter administrative Rechte benötigen. Diese Adminrechte sind aber in der Regel nur temporär erforderlich.

    Damit die Anwender nach der Durchführung administrativer Aufgaben wieder unter normalen Benutzerrechten arbeiten, haben wir unsere Software GARDEN entwickelt.

    Über GARDEN kann ein Anwender für einen gewünschten Zeitraum lokale Adminrechte beantragen. Diese Rechte werden über einen GARDEN Server verwaltet und können mittels GARDEN Monitor überwacht werden. Die Einrichtung der lokalen Adminrechte kann dabei entweder vollkommen automatisch erfolgen, oder erst nach Freigabe durch einen verantwortlichen Mitarbeiter. Nach Ablauf der beantragten Zeit werden die lokalen Adminrechte automatisch wieder entzogen. Dieser Mechanismus funktioniert sowohl online als auch offline.

    Eine ausführliche Beschreibung von GARDEN finden Sie unter: http://www.askus.biz/de/software.html

    Bild von Sebastian Taraba
    Sebastian Taraba sagt:
    25. April 2017 - 16:21

    Hallo Herr Biber,
    hier noch was einfaches, wenn Sie bereits Server 2016 DFL haben:
    http://woshub.com/temporary-membership-in-active-directory-groups/
    https://blogs.technet.microsoft.com/askds/2016/03/09/previewing-server-2...

    Damit können Sie Usern für eine bestimmte Zeit (TTL) in eine von Ihnen ausgewählte AD-Gruppe verschieben. Danach wird der User selbstständig aus dieser entfernt. Bestimmt gibt es hier (WindowsPro) auch einen Artikel dazu ;) Bestimmt

    Bild von Wolfgang Sommergut
    25. April 2017 - 23:12

    Ist schon länger in Planung, aber momentan gibt es hier noch keinen Artikel dazu ;-)

    Bild von Jürgen Krüger
    Jürgen Krüger sagt:
    28. April 2017 - 17:54

    @Hr. Biber, Hr. Taraba, Fr. Wolff: Die Anforderung, Anwendern kurzfristig lokale Admin Rechte zu geben, kann aus meiner Sicht nicht befriedigend über Temporary Group Memberships gelöst werden: Selbst wenn es ausreichen würde, den Anwender für wenige Minuten zum Admin zu machen, müsste ich immer noch zentral für jeden PC eine separate Gruppe vorhalten, oder alternativ (über eine einzige Gruppe) alle Anwender auf allen PCs gleichzeitig zu Admins machen. Ein aussichtslos komplizierter Tanz. Da ist es viel besser, eine klassische Softwareverteilung zu verwenden, die automatischen Updates zu deaktivieren und die Software zentral verwaltet zu verteilen. Oder alternativ - um im Kontext zu bleiben - folgendes Szenario: Der Anwender bekommt ein (signiertes) PowerShell Script, welches ihn auf seinem PC zum Admin macht, xx min schläft, und ihn dann wieder entfernt (ein Reboot / logoff müsste über SchTasks abgefangen werden) - kompliziert, aber ohne weltweite Koordination der Updates machbar. Einfacher wäre es da noch, das andere Tool von Frau Wolff einsetzen: Garden. Gibt es da schon etwas auf Windows Pro? (@Hr. Sommergut: ;-) Danke für Ihre exzellente Arbeit - muss ja auch einmal gesagt werden)

    Bild von Sebastian Taraba
    Sebastian Taraba sagt:
    28. April 2017 - 19:41

    Hallo Herr Krüger, gute Ansätze. Sie haben vollkommen Recht. Nur kurz nochmal zu den temporary Group memberships. Ich glaube Sie denken da zu komplex. Im Prinzip geht es per GPP in die lokalen Gruppe der Administratoren eine Gruppe aus der Domäne einzutragen. Ich nenne sie jetzt Clientadmins. Dieser wird dann per temporary Group membership der user zugewiesen. Da gibt es aus meiner Sicht keinen Aufwand, da die Gruppe auf jedem Client implementiert ist und nur das Membership dann per Script oder manuell durch Admin gesteuert wird. VG

    Bild von Jürgen Krüger
    Jürgen Krüger sagt:
    3. Mai 2017 - 12:32

    Hallo Herr Taraba, nur kurz, um nicht den ganzen Blog mit Kommentaren zu überfrachten: Die Thematik der Temporary Group Memberships kenne ich gut, ebenso die MS Technologien (MS Partner seit 1998x). Ihr Ansatz ist der klassische, statische Ansatz: Da es um das Hinzufügen eines Accounts zu einer LOKALEN Gruppe geht, müssten Sie PRO RECHNER eine AD Gruppe erstellen, die JEWEILS auf dem Rechner Mitglied der lokalen Admins wäre. Ansonsten fügen - wenn auch temporär - immer den jeweiligen temp. Admin zu den Administratoren auf ALLEN Rechnern der Domain hinzu. Um das weiter zu diskutieren lade ich Sie aber gern einmal zu einem Kaffee ein :-) jk