Jan 21 2010

Microsoft User Account Control

Category: Diversesadmin @ 12:04 am

Wir haben heute in der Firma einen Fileserver umgezogen – von Server 2003 auf Server 2008 R2. Dabei hatte ich wiedermal ein Erlebnis der 3. Art mit der beschissensten Idee, die Microsoft je hatte: Der User Account Control, kurz UAC.

Erstmal eine kurze Erklärung, was die UAC überhaupt ist:

Die UAC ist Microsofts Antwort auf den Schrei nach Sicherheit. Leider ist das Konzept dahinter grundlegend falsch aufgebaut. Windows ist ab NT 3.1 aufwärts ein Multiuser-Betriebssystem, das eine recht ausgefeilte Steuerung von Benutzerrechten zuläßt. Man kann Benutzer mit fast jeder beliebigen Kombination von Rechten auf alles mögliche bauen. Zu den von daheim bekannten Standard-Typen Administrator, Hauptbenutzer, Benutzer und Gast kommen in Active-Directory-Umgebungen noch unzählige weitere dazu, da gibt es dann z.B. Backup-Operatoren oder Schema-Administratoren. Das würde es prinzipiell erlauben, Benutzer zu bauen, die genau die Rechte haben, die sie brauchen. Zudem kann man jedem Benutzer die Rechte auch erweitern, indem man auf entsprechende Objekte (Dateien, Registry-Keys, Dienste, etc.) einzeln Rechte gemäß den Anforderungen einer Anwendung selektiv vergibt.

Microsoft hat leider aber in der Vergangenheit schon bei der Installation alle Benutzer zu „Administratoren“ gemacht. Unix/Linux-Admins lächeln darüber schon, seit es Windows gibt, unter Unix ist es nämlich üblich, daß „root“ nur ausgewählte Personen bekommen, und selbst die nutzen „root“ nur im Ausnahmefall. Alle anderen bekommen normale Benutzerrechte, die ggf. erweitert werden.

Um jetzt möglichst „rückwärtskompatibel“ zur „Alle sind Admin“-Ära zu bleiben, hat Microsoft was neues erfunden: Die UAC.

Die UAC ist ein Dienst, der überwacht, welche Rechte ein User zu verwenden versucht. Will er Administrieren, dann fragt die UAC „Wollen Sie das wirklich?“ und erlaubt oder verweigert das Ausführen der Funktion. Microsoft geht hier also den Weg, daß der User Administrator ist, dann aber diese Rechte doch nicht ausüben darf.

Das hat zur Folge, daß zum einen sehr seltsame Verhaltensweisen des Betriebssystems entstehen (kommt später, das hatten wir heute…) und zum anderen der User noch immer zu viele Rechte hat – sie werden ihm ja nicht genommen, nur das Ausführen eines Programmes, das sie anfordert, wird ggf. verhindert.

Viel besser wäre es gewesen, echte eingeschränkte Benutzer zu erstellen – Ab Vista kann man sich problemlos zweimal anmelden, mit der schnellen Benutzerumschaltung kein Problem. Will man was installieren, meldet man sich als Admin an, installiert, meldet sich wieder ab und macht mit der anderen Sitzung einfach da weiter, wo man aufgehört hat. Kein Problem. Alternativ hätte auch Microsoft ein Tool wie SuRun entwickeln können, das bei Bedarf für einzelne Applikationen Admin-Rechte aktiviert, auch wenn der Benutzer nur eingeschränkte Rechte hat, analog einem „SU“ unter Unix. Die Funktionen, um es richtig zu machen, sind seit NT 3.1 da, also warum nutzen sie sie nicht, sondern erfinden was neues?

In meinen Augen ist die UAC die dämlichste Erfindung, die Microsoft jemals gemacht hat. Man doktort im Namen der heiligen Rückwärtskompatibilität wieder nur an den Symptomen rum, statt das zugrundeliegende Problem zu beheben. Was ist so schwer daran, es einfach richtig zu machen und den Supprt für Uralt-Apps endlich mal über Bord zu werfen? Zumal es für die ja seit Windows 7 den äußerst praktischen XP-Mode gibt, über den man das ja auch elegant lösen könnte. Also hätte man es ja wenigstens mit Windows 7 endlich richtig machen können.

So, jetzt zu meinem Erlebnis. Wir haben wie gesagt die Fileserver von 2003 R2 auf 2008 R2 umgezogen. Das ging soweit auch glatt. Wir haben die alten Maschinen runtergefahren, die Maschinenaccounts in der Domäne zurückgesetzt, die neuen Server mit den Accounts verbunden, im SAN die LUNs (Platten) umgehängt. Alles soweit kein Problem. Server neugestartet, Platten da. Soweit sah alles gut aus – noch schnell die Laufwerksbuchstaben umgebaut, fertig. Shares anlegen.

Soweit kamen wir. Der erste Klick im Explorer brachte die Ernüchterung: Die Platten waren zu sehen, aber beim Klick drauf: „Access Denied“. Hm. Wieso jetzt das? Wir haben die Maschinenaccounts – also auch die SID – übernommen. Das muß gehen. Wir haben alles probiert, inklusive ändern des Besiters der Dateien. Kein Zugriff.

Zum Glück hatte ich einen Consultant vorgewarnt, daß wir evtl. Hilfe brauchen. Er schaute sich das an, hat kurz nachgedacht, ein paar Sachen probiert und meinte dann: „Habt ihr die UAC abgeschaltet“?

Ich wäre nicht mal drauf gekommen, daß es die auf einem Server überhaupt gibt, geschweige denn, daß sie für einen Domänen-Admin-Account aktiv ist. Aber: Sie ist es. Und sie verhindert zuverlässig jeglichen Zugriff auf korrekt eingebundene und berechtigte Laufwerke, nur, weil sie nicht mit diesem Rechner erzeugt wurden.

Ich habe daraus wieder etwas gelernt: Ich werde morgen als erstes eine Domänenrichtlinie bauen, die die UAC für Server zwangsweise deaktiviert. Nochmal passiert mir das nicht.

Auf dem Arbeitsplatzrechner ist die UAC schon fragwürdig, aber auf einem Server ist sie störend und verursacht nur Probleme. Das ist in etwa wie die unselige „Verstärkte Sicherheitskonfiguration“ für den Internet-Explorer. Das Ding macht auch mehr Probleme, als es löst, weil man – ist die Option aktiviert und installiert man danach einen IE7 oder IE8 – plötzlich einiges nicht mehr tun kann, was im ersten Moment nicht mit dem IE in Verbindung zu bringen ist, z.B. das Ausführen von Executables auf einem Netzlaufwerk im LAN.

One Response to “Microsoft User Account Control”

Leave a Reply

*