Seit Windows XP SP2 hat sich die Sicherheit grundlegend verbessert. Leider war und ist unter Windows XP das allgemeine Arbeiten ohne Admin-Rechte nicht immer möglich. Das liegt zum einen an doofen Programmen, welche irgendwelche Rechte in der Registry oder geschützten Verzeichnissen Schreibzugriff wählen. Andrerseits wird unter XP leider nicht standardmäßig angeboten, dass man das Programm mit erhöhten Rechten (nach Eingabe des Admin-Passwortes natürlich) starten möchte. Das geht bei Linux mit "sudo" schon relativ lange und wird dort auch bei grafischen Interaktionen angeboten.
Entweder sind da die Programmierer einfach so schlau oder das Rechte-System vom Kernel ist einfach ausgereifter. Unter XP gibt es natürlich auch immer die Möglichkeit mit "runas" ein Programm mit erhöhten Rechten auszuführen. Doch meistens ging dann hinterher wieder irgendwas nicht mehr... Vielleicht sind die Programmierer von Windows Programmen auch einfach generell der Meinung, dass der Benutzer sowieso immer standardmäßig mit vollen Rechten arbeitet und daher alles darf. 
Mit Windows 7 (Windows Vista war ja nur das Preview-Windows 7) hat sich die Situation doch wieder verbessert. Es wird meistens immer angeboten, dass man erhöhte Rechte gewähren kann (Admin-Kennwort eingeben). Doch habt ihr schon mal versucht, den nervigen Java-Updater als normaler Domänen-Benutzer erfolgreich auszuführen? Oracle ist einfach immer noch der Meinung, dass die meisten Leute sowieso als Standard-Admin Nutzer arbeiten und somit immer volle Rechte haben. Man bekommt hier einfach eine Aufforderung für erhöhte Rechte. Wenn man dann den Admin-Account eingibt, bricht der Updater wieder ab und sagt, dass er die Datei nicht gefunden hat. Gut, vielleicht führt in dem Fall auch Windows 7 den Updater mit falschen Pfaden in die Irre. Es ist aber trotzdem immer noch ein "Pain in the Ass" und verursacht Zeitaufwand für mich. Ich muss mich nämlich wieder als Administrator anmelden.
Da hat sich Adobe doch um einiges verbessert: Wenn der Updater kommt und nach erhöhten Rechten frägt, lädt der Updater hinterher auch weiter und bricht nicht einfach ab. Windows 7 ist in Punkto Sicherheit um einiges besser geworden, aber die gute Umsetzung von "sudo" oder "runas" ist leider noch nicht gegeben. Vermutlich sind aber auch ein paar inkompetente Entwickler großer Firmen an diesem Desaster schuld. Vorrangig sei hier mal Oracle erwähnt. Wäre Sun nicht aufgekauft worden, wäre das Problem wohl schon längst gefixt.
Der absolute Hammer in Sachen Fahrlässigkeit finde ich folgendes: (schon etwas älter aber immer noch interessant) Man verschafft sich physischen Zugriff auf einen Firmenserver oder ein Laptop, auf welchem kein BIOS / EFI Kennwort gesetzt ist und die Festplattenverschlüsselung auch erstmal nicht genutzt wird. Dann kann man sich mit relativ einfachen Mitteln Zugriff auf den Server beschaffen:
1. Server von einer Windows 7 oder Windows 2008 CD booten.
2. In den Reparaturoptionen wählt man sich die Konsole aus.
3. Man wechselt ins Windows Verzeichnis der Serverplatte und benennt einfach die Utilman.exe im System32 nach Utilman.exe.bak um. Alternativ kann man die Datei auch einfach löschen...
4. Man kopiert sich die lokale CMD.exe ins System32 und benennt diese nach Utilman.exe um.
5. Man startet Windows von der eingebauten Festplatte.
6. Sobald Windows 7 oder eben auch Windows 2008 R2 gestartet ist, kann man die Eingabehilfen öffnen und hat damit eine normale Kommandozeile vor sich.
Die Möglichkeiten dürften damit relativ klar sein. Man kann sich beispielsweise einen neuen Administrator-Account anlegen und sich mal in aller Ruhe das AD oder die Inhalte der Festplatte anschauen. Falls es sich um einen DC handelt, kann man diesen Server nach ein paar Tagen wieder an den ursprünglichen Platz stellen und sich im Firmennetz nach ein paar Leckerbissen umschauen. Wenn die lokalen Administratoren nicht misstrauisch werden und den zusätzlichen Administrator nicht bemerken, hat man auch für eine Weile domänenweit "Root".
Das ist eigentlich ein schwerwiegender Bug und sollte von Microsoft irgendwie unterbunden werden können. 
Einen Schutz gegen diese Art von Manipulation gibt es momentan noch nicht. Gruppenrichtlinien würden nichts bringen, da der Zugriff von "außen" erfolgt.
Der einzig wirksame Schutz ist folgendes: Den Server in einen verschließbaren Raum abstellen und den Schlüssel nur an vertrauenswürdige Personen austeilen. Bei Laptops mit sensiblen Daten einfach die Festplattenverschlüsselung aktivieren. Wenn der Laptop dann geklaut wird oder verloren geht, sind wenigstens keine Firmendaten abhanden gekommen.
Ansonsten finde ich Windows 7 trotz allem ein sehr robustes und gutes Betriebssystem. Die Sicherheit und die Möglichkeiten zur Härtung haben sich gegenüber Windows XP doch um einiges verbessert und es gibt für dieses System einfach die meisten Anwendungen. Und wenn man sich mal mit der Konsole näher beschäftigen möchte ist PowerShell auch eine gute Lösung. Fast alles, was per GUI ausgeführt werden kann, ist auch über die Konsole möglich (wenn man es denn auch so will 
).
Oftmals liegt dies am verstecktem assembly Ordner im Windows Verzeichnis. Dort legt .NET auch einen Temp Ordner an, der leider scheinbar nicht automatisch geleert wird. So kommt es, dass mit der Zeit eine beachtliche Menge an Daten angesammelt werden, die aber nur unnötig Platz belegen. Mit TreeSize Free kann man sich die Speicherbelegung anzeigen lassen und sobald es der Temp Ordner ist, kann man diesen bedenkenlos löschen. Bei anderen Ordner sollte man natürlich vorsichtig sein. Unter Umständen kann man sich damit auch mal sein System zerschießen. Also Kopf einschalten. Wenn man unsicher ist, den Ordner lieber bestehen lassen!
Damit man in den Assembly Ordner mit dem Windows Explorer kommt, sind ein paar "Hacks" mit der Konsole nötig. Dazu eine cmd.exe mit Administrator aufmachen und nachfolgende Befehle eingeben. Ich gehe davon aus, dass man Anfangs im Pfad: "C:\Windows\system32" befindet. Dann machen die folgenden Befehle Sinn:
