Tags: Rechteverwaltung, Sicherheit, Authentifizierung
Es ist eine anerkannte Best Practice, Endbenutzer auf ihren PCs nicht mit administrativen Privilegien auszustatten. Wenn einzelne Programme oder Aktionen erhöhte Rechte erfordern, dann würde es ausreichen, 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 Administratoren arbeiteten, entfällt diese Notwendigkeit seit Windows 7 weitgehend. Gängige Aufgaben lassen sich seitdem nämlich im Kontext eines Standardbenutzers 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übergehend erhöhte Rechte benötigen.
Microsoft sieht das Dienstprogramm runas vor, um einzelne Programme unter einer anderen Kennung auszuführen. Auf diese Weise kann man es auch mit administrativen 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.
Der gravierende Nachteil dieses Vorgehens besteht aber darin, dass der betreffende Mitarbeiter künftig beliebige Programme im Kontext dieses administrativen Kontos starten kann. Erst wenn man die Anmeldedaten in der Systemsteuerung unter Benutzerkonten => Anmeldeinformationsverwaltung 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 Kommandozeile 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 Systemverwalter eine Verknüpfung für ein Programm erstellt, in der das Kennwort des privilegierten Kontos verschlüsselt abgelegt wird. Der Benutzer erhält dann typischerweise 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.
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 Umgebungsvariablen 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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Ähnliche Beiträge
- Vorzeitiges CU1, CU12, CU22 für Exchange 2019 / 2016 / 2013 wegen Security, Rollup für Version 2010
- NTLM-Authentifizierung überwachen oder blockieren mit Gruppenrichtlinien
- Exchange Server und IIS mit Windows Extended Protection (WEP) absichern
- User Account Control (UAC): Mit PIN anmelden, Einstellungen per GPO konfigurieren
- KrbRelayUp: Domänen-Controller gegen Angriffe auf Resource-based constrained Delegation absichern
Weitere Links
7 Kommentare
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.
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
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
Ist schon länger in Planung, aber momentan gibt es hier noch keinen Artikel dazu ;-)
@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)
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
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