Benutzerkontensteuerung (UAC) richtig einsetzen

Kein Feature von Windows Vista ist so umstritten wie die Benutzerkontensteuerung (User Account Control, UAC). Gleichzeitig wird aber auch keine Funktion so stark missverstanden wie diese Sicherheitseinstellung. Da Windows Server 2008 auf demselben Code beruht wie Vista, ist es auch für Netzwerk-Admins an der Zeit, sich mit den Hintergründen dieses Systems zu befassen und sinnvolle Umgangsweisen damit kennenzulernen.

Ein zentrales Missverständnis, das in der Frühphase des Vista-Marketing leider auch aus dem Hause Microsoft oft transportiert wurde, betrifft den Nutzen der Benutzerkontensteuerung (im Folgenden auch kurz UAC). Sie stellt weder einen universellen Schutz vor schädlicher Software wie Viren oder Trojanern dar, noch handelt es sich um ein Mittel, mit dem alte Applikationen, die an dem restriktiven Berechtigungssystem von Vista scheitern, für Benutzer kompatibel gemacht werden können. UAC ist ein Baustein in dem umfassenden Sicherheitskonzept von Windows Vista und Windows Server 2008, das aber immer um weitere Komponenten wie Virenscanner, eine Firewall und natürlich ein aufmerksames Benutzerverhalten ergänzt werden muss. Und: Selbst das stark erweiterte Vista-Schutzkonzept ist natürlich keineswegs vollständig in dem Sinne, dass es den Rechner per se „sicher“ macht. Wie überall sonst auch, muss die Betriebs- und Datensicherheit kontinuierlich geprüft und angepasst werden.

Um UAC sinnvoll nutzen zu können, sollte Klarheit über die Absicht und die Hintergründe bestehen. Darum geht es im Folgenden.

Wie UAC arbeitet: Voraussetzungen

Die Benutzerkontensteuerung nutzt einige Komponenten, die schon im Ursprungsdesign von Windows NT umgesetzt wurden, führt aber zugleich neue Ansätze ein. Schon im ersten NT-Release 1993 wurde ein Fokus auf ein leistungsfähiges Authentifizierungs- und Schutzkonzept gelegt. Bei der Anmeldung eines Benutzers wird seinem Konto ein Access Token zugeteilt, das in der gesamten Arbeitssitzung darüber entscheidet, auf welche Daten und Funktionen der Benutzer zugreifen kann. Dazu enthält das Token die Sicherheitskennung (Security ID, SID) des Benutzers sowie die SIDs aller Gruppen, denen der Benutzer im Moment der Anmeldung angehört. Weiterhin sind im Token alle Systemrechte (auch Privilegien genannt) vermerkt, die dem Benutzerkonto vom Administrator verliehen wurden – beispielsweise das Recht, die Systemzeit zu ändern (damit wurde unter NT noch oft gearbeitet, mittlerweile aber kaum mehr), einen Debugger auf Systemebene einzusetzen oder sich als Dienst an das System anzumelden (dieses Privileg wird normalen Benutzerkonten üblicherweise nicht erteilt, sondern nur den speziellen Dienstanmeldekonten). Bei jedem Zugriff auf eine Funktion oder ein Objekt prüft das Betriebssystem das Access Token, ob die angeforderte Aktivität erlaubt ist. Diese Technik ist sehr effizient, denn sie erfordert zur Prüfung der Berechtigungen keinen Kontakt zum Anmeldeserver – es werden nur die SIDs in der Zugriffsliste (Access Control List, ACL) mit dem Token verglichen. Änderungen an Gruppenmitgliedschaften werden so aber nur wirksam, wenn ein Benutzer sich ab- und neu anmeldet.

Jeder Prozess, der von einem Benutzerkonto gestartet wird (also meistens ein Programm) bekommt das Token des Benutzers übertragen. Dadurch hat ein Prozess nicht mehr, aber (in der Regel) auch nicht weniger Rechte als der Benutzer, der es aufruft. Zwar gibt es auch Spezialitäten, in denen ein Konto das Token und damit die Identität eines anderen Benutzers übernimmt, um in dessen Namen etwas auszuführen, aber diese sogenannte „Delegation“ muss speziell erlaubt und eingerichtet werden.

Der Zugriff auf Systemfunktionen wird von Windows über die Mitgliedschaft in speziellen Gruppen gesteuert: Nur wer Mitglied der lokalen Gruppe „Administratoren“ eines Systems ist, hat tatsächlich Administratorrechte. Wer Mitglied der Gruppe „Backup-Operatoren“ ist, kann Daten auch dann sichern, wenn er eigentlich gar keine Zugriffsrechte darauf hat. Ähnlich funktionieren zahlreiche andere Gruppen, die unter Windows vorhanden sind. Dabei gilt das Prinzip des Kumulierens: Ist ein Benutzer Mitglied mehrerer Gruppen, so entsprechen seine effektiven Berechtigungen der Kombination aller Berechtigungen der verschiedenen Gruppen.

Windows konnte schon immer sicher sein

Von der ersten NT-Version an hatte Windows ein Sicherheitssystem, das in vielen Aspekten State of the Art war oder andere Produkte sogar übertraf. Die Zugriffskontrolle schützt nicht nur das Dateisystem, sondern auch die Registrierungsdatenbank, Netzwerkdrucker und viele andere Objekte. Problematisch war aber besonders die Standardeinstellung direkt nach der Installation: Das einzige vorhandene Konto ist zunächst das vordefinierte Administrator-Konto, das wesensgemäß „alles“ im System tun darf. Da das natürlich ausgesprochen bequem ist, arbeiteten (und arbeiten) viele Benutzer auf ihren Heimrechnern, aber auch in professionell betriebenen Netzwerken stets mit diesem Konto oder mit einem anderen Konto, das über Administratorrechte verfügt.

Wie nicht anders zu erwarten, arbeiten auch zahlreiche Softwareentwickler stets mit administrativen Rechten. Da ihre Applikationen so fast niemals vom Betriebssystem an Aktionen gehindert werden, fällt es während der Entwicklung nicht auf, wenn eine Anwendung mit einem normalen Benutzerkonto nicht lauffähig ist. In der Folge sehen sich Netzwerkadministratoren oft gezwungen, den Benutzern administrative Rechte zu erteilen, wenn sie mit solchen Applikationen arbeiten müssen.

Zwar gibt es oft einen recht einfachen Weg, den Benutzern gezielt nur die Berechtigungen zu geben, die sie für eine Applikation benötigen, weil in den allermeisten Fällen die Entwickler recht einfache Verstöße gegen das Windows-Sicherheitssystem begehen: Meist genügt es, gezielt Schreibzugriff auf den Applikationsordner im Programme-Verzeichnis des Systems sowie ggf. im entsprechenden Pfad unter HKEY_LOCAL_MACHINE\Software in der Registry zu erteilen. Doch dieser Aufwand ist vielen zu hoch, weil das Arbeiten als Admin so schön bequem ist.

Wenn Benutzer als Administratoren arbeiten, entstehen aber schnell Folgeprobleme: Jede Applikation hat so auch Adminrechte, also auch ein Virus oder Trojaner, der sich so ungehindert im System austoben kann. Gleichzeitig können Admins das System umkonfigurieren, den Virenscanner und die Firewall abschalten, die Anwendung von Gruppenrichtlinien verhindern – und was ihnen sonst noch so einfällt.

Wie UAC arbeitet: Der Ansatz

Leider sind die Bemühungen, Benutzer, Administratoren und insbesondere Softwareentwickler der bequemen Kategorie davon zu überzeugen, dass „normale“ Aufgaben (also die alltägliche Arbeit) immer nur mit einem normalen Benutzerkonto ausgeführt werden sollten, nicht immer von Erfolg gekrönt. Microsoft entschied sich daher bei der Entwicklung von Windows Vista für einen radikalen Weg: Die Benutzerkontensteuerung erzwingt, dass alle Benutzer (zunächst) ohne Administratorrechte arbeiten – selbst dann, wenn sie Mitglied der Gruppe „Administratoren“ sind. Sollte es tatsächlich notwendig sein, eine Aktivität mit erhöhten Rechten auszuführen, so bietet UAC an, solche Rechte verfügbar zu machen. Wie funktioniert das?

Bei aktivierter Benutzerkontensteuerung wird aus dem Access Token eines Benutzers, der sich anmeldet, jede Mitgliedschaft in einer der kritischen Systemgruppen entfernt. Auch einige direkt zugewiesene Systemprivilegien werden aus dem Token gestrichen. Auf diese Weise wird aus einem Administratorkonto in der Arbeitssitzung ein Benutzerkonto. Mitgliedschaften in Nicht-Systemgruppen, die den Zugriff auf Daten steuern, sind davon natürlich nicht betroffen.

Sobald nun das System feststellt, dass ein Prozess nur dann gestartet oder fortgesetzt werden kann, wenn erhöhte Rechte (meist Administratorrechte) vorhanden sind, hält es die Ausführung an und fragt den Benutzer, ob er sich diese Rechte verschaffen will. In diesem Moment kommt die (von manchen als nervig empfundene) UAC-Nachfrage: Windows dunkelt den Bildschirm ab und blendet ein Dialogfenster ein. Der Benutzer kann in dieser Situation nichts anderes tun und muss die Frage beantworten. Technisch wird dies durch einen Trick erreicht: Windows schaltet auf einen anderen Desktop um und blendet das Aussehen des „eigentlichen“ Benutzer-Desktops als abgedunkelte Bitmapgrafik ein. Da dieser UAC-Desktop speziell geschützt wird, kann die UAC-Abfrage nicht durch Schadsoftware ferngesteuert werden – manuelles Eingreifen ist nötig.

Je nachdem, wie weit der Benutzer vor dem Computer bzw. der für den Rechner verantwortliche Admin das Sicherheitskonzept bereits verinnerlicht haben, kann eine von zwei Situationen vorliegen: Das angemeldete Benutzerkonto ist ein „normales“ Konto, das gar nicht Mitglied der Administratoren-Gruppe oder einer anderen Gruppe mit erhöhten Rechten ist. Oder aber das Konto hat eigentlich die nötigen Rechte, aber durch das von UAC beschränkte Access Token kann es diese Rechte nicht einsetzen. Hier sind in der Folge unterschiedliche Aktivitäten nötig, die von UAC mit unterschiedlichen Abfragen eingeleitet werden.

Fall 1: Benutzer ist kein Admin

Im eigentlich gewünschten Fall ist der angemeldete Benutzer tatsächlich ein „normaler“ Benutzer. Da diesem Konto nicht einfach so Adminrechte verliehen werden können, bietet UAC in seiner Nachfrage an, dass der Benutzer den Namen und das Kennwort eines anderen Benutzerkontos angibt, das über die nötigen Rechte verfügt. Gelingt dies, so startet Windows den angeforderten Prozess mit diesem Konto (der Prozess verfügt dann also über das Access Token des anderen Kontos). Die Technik dahinter entspricht im Wesentlichen der „Run as“-Funktion („Ausführen als“), die mit Windows 2000 eingeführt wurde und auf dem Systemdienst „Sekundäre Anmeldung“ beruht. Sie ist hier allerdings für die meisten Situationen komfortabler ausgeführt, weil der Benutzer nicht erst eine Eingabeaufforderung mit dem „runas“-Kommando starten oder den Link zu seinem Programm ändern muss.

Ein Aspekt wird an dieser Stelle aber gern vergessen: Ein normaler Benutzer sollte natürlich nicht das Kennwort eines Administratorkontos verfügen. Gedacht ist dieses Verfahren also einerseits für den Fall, dass ein anwesender Administrator einem Benutzer hilft, indem er gezielt seine Anmeldedaten in den UAC-Dialog eingibt, um einmalig eine bestimmte Aktion zu ermöglichen. Man nennt diese Technik daher auch „Over-the-shoulder (OTS)“, weil der Admin dem Benutzer gewissermaßen über die Schulter hinweg hilft. Andererseits ist der Ansatz aber natürlich auch für den Admin selbst interessant: Gängige Empfehlungen lauten, dass Admins (mindestens) zwei Benutzerkonten haben sollten: Ein normales für die alltäglichen Arbeiten (Office, Internet usw.) und ein separates für administrative Aufgaben. Gewöhnt man sich an diese Arbeitsweise und meldet sich in der Arbeitssitzung stets mit dem normalen Konto an, so lässt sich komfortabel arbeiten, weil UAC es schnell ermöglicht, einzelne Aufgaben oder Programme mit Adminrechten auszuführen.

Über diesen Weg ist es übrigens grundsätzlich auch möglich, ein Programm mit einem anderen Benutzerkonto zu starten: Der UAC-Dialog im OTS-Modus lässt die Eingabe eines beliebigen Anmeldenamens zu, es muss sich nicht zwingend um einen Admin handeln. Sofern das aufgerufene Programm keine Adminrechte benötigt, startet es auch im Kontext eines anderen „normalen“ Kontos – also ein komfortabler Ersatz für „runas“. Diese Möglichkeit besteht im AAC-Modus (siehe unten, „Fall 2: Benutzer ist Admin“) nicht!

Völlig ungeeignet hingegen ist diese Methode, wenn Benutzer mit Applikationen arbeiten sollen, die nicht an das Windows-Sicherheitssystem angepasst sind und daher mit normalen Benutzerrechten nicht funktionieren. Sobald eine solche Applikation mit einem anderen Konto gestartet ist und dem Benutzer zur Verfügung steht, kann er aus diesem Prozess heraus natürlich weitere Aktivitäten ausführen (z.B. über den Datei-speichern-Dialog, der in der Regel ein Explorer-Fenster ist und das Aufrufen beliebiger Programme erlaubt). Schnell wäre der Benutzer also in der Lage, eben doch wieder sein System zu manipulieren oder ungewollt in Gefahr zu bringen.

Fall 2: Benutzer ist Admin

Der prinzipiell unerwünschte Fall ist der, in dem der Benutzer über lokale Adminrechte verfügt. Genau dieser Fall ist aber der Grund, warum UAC überhaupt entwickelt wurde. In dieser Situation wird, wie oben beschrieben, das Access Token für die Arbeitssitzung um die kritischen Rechte bereinigt. Ruft der Benutzer nun eine Funktion auf, die erhöhte Rechte benötigt, so schaltet UAC ebenfalls auf seinen geschützten Desktop um. Der angezeigte Dialog ist aber ein anderer: Er erlaubt nicht die Angabe eines anderen Kontos, sondern er fordert nur zur Bestätigung der Aktion auf. Der Grund liegt auf der Hand: Eigentlich hat das Konto ja ausreichende Rechte, es kann nur nicht darauf zurückgreifen. Der Administrator bestätigt also, dass er die Aktion angefordert hat, daher nennt sich dieser Modus „Admin Approval Mode (AAM)“.

Je nachdem, wie gut die aufgerufene Applikation an UAC angepasst ist, gibt sie nun die gewünschte Funktion frei und führt sie mit dem vollständigen Access Token aus. Es kann aber auch sein, dass die Applikation mit diesem System nicht umgehen kann und daher ausdrücklich mit dem vollständigen Token neu gestartet werden muss. Dies lässt sich im Zweifel erledigen, indem man mit der rechten Maustaste auf das gewünschte Programm klickt und im Kontextmenü auswählt „Als Administrator ausführen“.

Die Ausnahme: Der „Administrator“

Es gibt eine Ausnahme in der Benutzerkontensteuerung: Das vordefinierte Konto „Administrator“ wird niemals durch UAC eingeschränkt. Unter Windows Vista hat das normalerweise keine Auswirkungen, denn dieses Konto kann nicht für die Anmeldung ans System verwendet werden. Stattdessen werden bei der Installation ein oder mehrere neue Konten angelegt, die der Gruppe „Administratoren“ angehören. Solche neu angelegten Konten werden durch UAC geschützt. Windows Server 2008 hingegen lässt die Anmeldung mit dem „Administrator“ zu und erzeugt beim Setup keine zusätzlichen Konten. Das ist auch gut so, denn Server werden völlig anders genutzt als Vista-PCs. Auch unter Windows Server 2008 arbeitet aber die Benutzerkontensteuerung: Meldet sich ein anderes Konto an (lokal oder in der Domäne), das „Administratoren“-Mitglied ist, so wird dieses über UAC eingeschränkt.

Wie man’s einsetzt

Die Benutzerkontensteuerung ist in Windows Vista und Windows Server 2008 standardmäßig aktiviert. Um sie aktiv zu nutzen, sollte man einige Einsatzfälle unterscheiden.

Geschützte Systemeinstellungen

Die Systemeinstellungen, die nicht nur für den aktuellen Benutzer gelten, sondern das Verhalten des gesamten Betriebssystems oder einer seiner Komponenten steuern, werden automatisch durch UAC abgesichert. Erkennbar ist dies an dem bunten Schutzschild-Symbol, das die entsprechende Funktion oder den zuständigen Button ziert. Klickt man darauf, so erscheint der UAC-Dialog, und danach geht es weiter.

Angepasste Vista-Programme

Anwendungen oder Hilfsmittel, die im Bewusstsein der UAC für Vista oder Windows Server 2008 entwickelt wurden, verfügen über ein sogenanntes „Manifest“, in dem angegeben ist, wofür evtl. eine Rechteerhöhung durch UAC nötig ist. Hierüber ermöglicht also der Entwickler einer Software, UAC sinnvoll und komfortabel einzusetzen. Nachträglich lässt sich ein solches Manifest nicht erzeugen.

Installationsprogramme

Die Installation von Software erfordert in den meisten Fällen erhöhte Rechte. Daraus folgt, dass die meisten Installationsprogramme immer mit einem Administratorkonto aufgerufen werden müssen, damit sie ordentlich funktionieren. Um dies zu vereinfachen, enthält die UAC einige Erkennungsmechanismen für solche Programme: Wenn ein Programm etwa „setup“ oder „install“ im Namen hat, übernimmt UAC die Kontrolle. Dies ist nur der einfachste Mechanismus, es gibt aber noch Weitere (Näheres dazu auf den MSDN-Seiten).

Da aber natürlich nicht jedes Installationsprogramm sich als solches ausgibt, kann es durchaus vorkommen, dass UAC nicht nach einer Rechteerhöhung fragt. In manchen Fällen bietet es daher nachträglich an, die (mutmaßlich fehlgeschlagene) Installation mit den passenden Rechten zu wiederholen.

Allgemein dürfte es der sinnvollste Weg sein, ein Installationsprogramm gleich ausdrücklich mit Adminrechten zu starten: Rechtsklick/“Als Administrator ausführen“.

Eingabeaufforderung

Administratoren stolpern gern darüber, dass auch das Fenster der Eingabeaufforderung (cmd.exe, oft fälschlich als „DOS-Fenster“ bezeichnet) standardmäßig mit eingeschränkten Rechten geöffnet wird. Folgerichtig werden administrative Vorgänge verweigert. Die Abhilfe ist auch hier, das CMD-Fenster per Rechtsklick als Administrator zu öffnen. Der schnellste Weg, dies zu tun, ist in den meisten Fällen dieser: Windows-Taste, tippen: cmd, Rechtsklick auf die erste Fundstelle.

Kritik und Grenzen

„Das nervt“

Einer der häufigsten Kritikpunkte an der Benutzerkontensteuerung ist, dass die vielen UAC-Aufforderungen nervten und ein geordnetes Arbeiten nicht zuließen. Diese Kritik ist in der Regel aber unberechtigt. Für die Arbeit, die an einem üblichen Vista-PC verrichtet wird, sind fast nie Adminrechte nötig. Nur wenn Systemeinstellungen geändert werden sollen oder etwa neue Programme zu installieren sind, benötigt UAC eine Bestätigung. Für die weit überwiegende Anzahl der Benutzer dürften dies seltene Ausnahmesituationen sein (meine Frau beispielsweise arbeitet seit vielen Monaten sehr intensiv mit Vista, hat aber noch nie einen UAC-Dialog gesehen). Hier könnte es sich um ein Problem des ersten Eindrucks handeln: Wer Windows Vista manuell installiert und einrichtet, wird zunächst tatsächlich sehr viele dieser administrativen Aufgaben ausführen und hat daher natürlich oft die UAC-Abfrage zu bestätigen. Erfahrungsgemäß ist dies aber eine Aufgabe, die in wenigen Stunden (meist noch viel schneller) erledigt ist. Und wer ehrlich ist, wird zugeben, dass bei üblichen Installationsprogrammen derart viele Mausklicks nötig sind, dass es auf jeweils einen UAC-Klick mehr eigentlich nicht ankommt.

Update April 2008: Übrigens ist ein gewisser Nerv-Faktor durchaus beabsichtigt. Dadurch soll Druck auf die Softwarehersteller ausgeübt werden, ihre Software (endlich) nach den Windows-Sicherheitsrichtlinien zu entwickeln.

[Microsoft Exec: UAC Designed To ‚Annoy Users‘ – Software – IT Channel News by CRN and VARBusiness]
http://www.crn.com/software/207100934?cid=CRNFeed

Anmeldeskripte und Netzlaufwerke

Besonders in den ersten Wochen nach der Vista-Freigabe wurde dann oft behauptet, dass in einer Windows-Domäne die vorhandenen Anmeldeskripte mit Vista nicht funktionieren würden, wenn UAC aktiviert ist. Bei näherem Hinsehen zeigte sich aber in den meisten Fällen, dass es tatsächlich nur Laufwerksverbindungen waren (Netzlaufwerke, auch „Mappings“ genannt), die für manche Benutzer nicht gesetzt wurden. Noch näheres Hinsehen zeigte, dass die betroffenen Benutzer lokale Administratoren waren – bei allen normalen Benutzern funktionierten die Mappings wie gewünscht. Woran liegt nun dies? Tatsächlich ist dies eine Einschränkung, die durch UAC verursacht wird: In den betreffenden Situationen werden die Laufwerksverbindungen in Wirklichkeit korrekt ausgeführt, allerdings geschieht dies, bevor UAC das Access Token reduziert hat und der Windows-Desktop erzeugt wurde. Wenn der Desktop dann fertig ist, verfügt der Benutzer bereits über das eingeschränkte Access Token. Nun darf der Explorer aber aufgrund interner Sicherheitseinschränkungen nicht mehr auf die Mappings zugreifen, weil sie ja mit einem anderen Token versehen sind. Die Auswirkung dieses Umstands ist tatsächlich unangenehm: Der Admin bekommt seine Netzlaufwerke nicht verbunden. In der Praxis ist die Abhilfe für die meisten Benutzer aber einfach: Die normale Arbeit sollte mit einem normalen Benutzerkonto erfolgen, denn dieses erhält die Mappings korrekt. Administrative Arbeiten werden dann, wie oben beschrieben, mit einem separaten Konto angestoßen.

Eine Lösungsmöglichkeit beschreibt dieser Artikel:

[After you turn on User Account Control in Windows Vista, programs may be unable to access some network locations]
http://support.microsoft.com/kb/937624/en-us

Es gibt hierfür auch einen Workaround, der allerdings zugegebenermaßen nicht den Hauptpreis für Eleganz verdient: Im Anmeldeskript wird ein Geplanter Task eingerichtet, der mit einigen Minuten Verzögerung die Mappings ausführt. Zu diesem Zeitpunkt hat der Benutzer schon das eingeschränkte Token und darf auf die Netzlaufwerke zugreifen. Das Verfahren beschreibt folgender Artikel im Abschnitt „Group Policy Scripts can fail due to User Account Control“:

[Deploying Group Policy Using Windows Vista]
http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx

Angriffsmöglichkeiten

Auch der Schutz des UAC-Dialogs wird kritisiert, teilweise sogar zu Recht. Bisher ist zwar kein Weg bekannt geworden, wie eine Schadsoftware den geschützten Desktop erreichen kann, um den UAC-Dialog selbst zu bestätigen und so wirkungslos zu machen. Im Fall der „Over-the-shoulder“-Technik ist aber ein Angriff denkbar, in dem eine Schadsoftware den UAC-Dialog optisch imitiert, um so die Anmeldedaten eines Administratorkontos auszuspähen. Da die einzige Kontrolle für den Benutzer in diesem Fall eine optische ist und die Schadsoftware nach dem Abgreifen des Kennworts die angeforderte Software mit eben diesem Konto starten kann, besteht in diesem Szenario kaum eine Schutzmöglichkeit für den Benutzer. Hierauf lässt sich nur entgegnen: Ja, dies ist ein denkbares Angrifsszenario. Es bleibt also von wesentlicher Bedeutung, neben UAC weitere moderne Sicherheitsmechanismen (Virenscanner, Firewall usw.) und vor allem aufmerksames Verhalten einzusetzen. – Das Imitieren des AAM-Dialogs ist zwar ebenfalls möglich, aber ein wirksamer Angriff lässt sich hieraus wohl kaum konstruieren, denn hier tut der Benutzer ja nichts weiter, als auf einen Button zu klicken; das Admin-Kennwort gibt er dadurch natürlich nicht weiter.

„Das falsche Konzept“

Daneben gibt es auch die – ebenfalls nicht unberechtigte – Kritik, dass UAC ein Schritt in die falsche Richtung sei: Durch UAC wird es komfortabler, weiterhin als Administrator zu arbeiten. Für viele Netzwerkadministratoren und Entwickler könnte die Versuchung groß sein, auf den Einsatz eingeschränkter Benutzerkonten zu verzichten, denn durch UAC seien die wichtigsten Schadenssituationen ja nun eingegrenzt. Diese Argumentation funktioniert aber überhaupt nur, wenn man den AAM betrachtet, in dem der Benutzer Admin ist und den UAC-Dialog nur durch Klicken bestätigt. Da ein lokaler Admin aber beliebigen Unfug mit seinem System anstellen kann, bleibt es das Ziel, in professionellen Netzwerken den Benutzern keine Administratorrechte zu geben. Entwickler hingegen sollen durch die UAC-Nachfrage daran erinnert werden, dass sie bei der Softwareentwicklung keine Adminrechte beim Benutzer voraussetzen sollten. 

Fazit: UAC richtig einsetzen

UAC ist nur ein Baustein in der technischen Umsetzung von Sicherheitskonzepten – aber ein wichtiger und aus meiner Sicht insgesamt ein guter. Es hat seine Grenzen und Tücken, und es ist nicht der Weisheit letzter Schluss. Meine allgemeine Empfehlung lautet, sich darauf einzulassen und UAC nicht abzuschalten. Ich habe sehr gute Erfahrungen damit gemacht, im Normalbetrieb ein „eingeschränktes“,  nicht-administratives Konto zu nutzen und UAC im „Over-the-shoulder“-Modus als komfortable Methode zu nutzen, gezielt administrative Programme und Funktionen zu nutzen. Es erfordert ein wenig Gewöhnung, bietet so aber ein hohes Maß an Sicherheit und Komfort. (Und: Wenn sogar die c’t den Einsatz von UAC empfiehlt …)