Mir ist erst in diesem aufgefallen, dass sich das Verhalten von XP gegenüber von 2000 etwas geändert hat. Dazu später mehr im Artikel.
In vielen Netzwerken hat man per Hand die Mitglieder der Lokalen Sicherheitsgruppen auf einer Workstation editiert und somit auf diesem einen speziellen System einen bestimmten Domänen-Benutzer in eine andere Sicherheitsgruppe verlegt, als die der "Benutzer".
Panik-Szenario: Die Manipulation der lokalen Sicherheitsgruppe erfolgte nicht gewollt, sondern war ein gezielter Angriff eines Anwenders, der sich damit lokal zum Administrator gemacht hat.
Sobald eine Rechner Mitglied eines AD oder einer Domäne wird, wird automatisch die Gruppen der "Domänen-Admins" in die lokale Gruppe der "Administratoren" aufgenommen. Die Gruppe der "Domänen-Benutzer" wird in die Gruppe der lokalen "Benutzer" integriert. Ohne dieses Standardverhalten der Gruppenzugehörigkeiten, man verwendet häufig den Begriff des User Mappings, hätte ein "Administrator" der Domäne überhaupt keine administrativen Berechtigungen auf dem Client. Er ist nur deswegen ebenfalls ein "Administrator" der Workstation, weil die Sicherheitsgruppe der "Domänen-Admins" in die Sicherheitsgruppe der "Administratoren" aufgenommen wurde. Gleiches gilt für die Benutzer, denn die angelegten Benutzer einer Domäne oder eines AD haben lokal die Berechtigungen eines "Benutzers", weil die Domänen-Gruppen in diese lokale Gruppe integriert ist.
Im HowTo: Zentrale Vergabe lokaler Berechtigungen ist eine Möglichkeit aufgezeigt, dieses Standardverhalten zu manipulieren. Der Weg führt über die "Eingeschränkte Gruppen" einer Sicherheitsrichtlinie.
Der Nachteil an dieser Lösung über die Gruppenrichtlinie ist, das diese Einstellung für jedes System gilt, das im Verwaltungsbereich der Gruppenrichtlinie liegt. Wollte man, dass ein bestimmter Benutzer nur an seiner eigenen Workstation lokale Administratorberechtigungen hat, so ist das per Gruppenrichtlinie nur möglich, wenn man pro Workstation eine Gruppenrichtlinie definieren würde, die dann jeweils nur den einen Benutzeraccount enthält und als einziges Ziel nur die Workstation adressiert. Dieses Ziel wäre also nur mit extremen Aufwand zu erreichen.
Die einfachste Lösung ist es den gewünschten Benutzer per Hand in die Lokale Gruppe aufzunehmen, in der er zusätzlich zu der der Benutzer Mitglied sein soll. Ob das nun die "Administratoren" oder die "Hauptbenutzer" sind, sei erst mal dahingestellt. Die händische Integration kann in der GUI über die Computerverwaltung - Lokale Benutzer und Gruppen erfolgen oder einfach in der Eingabeaufforderung.
net localgroup Hauptbenutzer MEINEDOM\MeinBenutzer /add
bzw.
net localgroup Administratoren MEINEDOM\MeinBenutzer /add
Diese beiden simplen Kommandozeilen würden den Benutzer "MeinBenutzer" aus der Domäne "MeineDom" in die jeweilige lokale Sicherheitsgruppe integrieren.
Ich behaupte, dass es abgesehen von Software die direkten Zugriff auf die Hardware benötigt (Brenner, Scanner etc.), keinen einzigen Grund gibt in einer Domäne einem Benutzer mehr Rechte einzuräumen, als die eines normalen Benutzers an der Workstation. Wie leicht es ist, die Berechtigungen für ein Programm einzurichten, das sich sträubt als "Benutzer" zu werkeln ergibt sich aus dem Artikel HowTo: Zentrale Vergabe lokaler Berechtigungen . Die fehlenden Berechtigungen für die Benutzer des Programms verstecken sich zu 95% in den Pfaden %ProgramFiles%\NamederAnwendung und HKLM\Software\NamederAnwendung. Manchesmal kommt noch eine *.ini im %systemroot% hinzu oder gar ein Dienst, aber dass ist schnell gefunden. Diese lokalen notwendigen Berechtigungen lassen sich über die GPO in den Sicherheitseinstellungen im Bereich "Dateisystem" und "Registrierung" schnell zentral für die gewünschte Gruppe anpassen.
Ich fürchte, dass aus purer Bequemlichkeit und mangels Wissen viele Administratoren ihre Benutzer zu "Hauptbenutzer" oder gar "Administratoren" gemacht haben, damit die Software funktioniert. Ich hoffe, dass ich mit meinen Artikeln, dieses aus meiner Sicht flashce Prinzip aus der Welt räumen kann und sich viele die Arbeit gemacht haben, für die jeweiligen Programmen die notwendigen Berechtigungen rausgesucht haben und per GPO verteilen.
Jetzt aber steht der Administrator der Domäne vor einem erneuten Problem:
"Wie kriege ich die per Hand eingetragenen Benutzer aus den lokalen Sicherheitsgruppen wieder hinaus?"
Simple Antwort:
"So wie sie über die GPO reinkommen würden, nur mit dem Unterschied, dass ich diesmal keine Benutzer oder Gruppen eintrage ..."
Das ist auch die Rettung für das Panik-Szenario.
Die CSE der Sicherheitsrichtlinienverarbeitung wird im Gegensatz zu anderen CSEs spätestens nach 16 Stunden per /force komplett erneut verarbeitet. Dadurch werden alle per Hand eingetragenen Benutzer automatisch wieder entfernt und es würde sich zumindest das Zeitfenster eines möglichen Angriffs reduzieren. Dass sich ein mit krimineller Energie ausgestatteter Anwender damit nicht aussperren lässt sollte klar sein, aber er muss sich wenigstens jedesmal neu eintragen und das wird ihm (oder ihr ...) vielleicht lästig.
Praktisch sähe es so aus: Wiederherstellung des Default User Mappings
Unter Windows 2000 muss der Administrator als Mitglied der Gruppe Administratoren eingetragen werden, da er sonst zu einem normalen Benutzer degradiert wird. Er wird aus der Gruppe entfernt, da die Einstellungen der Eingeschränkten Gruppe die Lokale Einstellung komplett ersetzen. Damit hätte man ein klassisches Eigentor geschossen und sich selber ausgesperrt. Ab Windows XP kann das nicht mehr passieren. Der Administrator kann über die GPO und damit die Eingeschränkte Gruppen nicht mehr aus der lokalen Gruppe der Administratoren entfernt werden. Unter Windows XP könnte also der Eintrag "Mitglieder" leer bleiben. Dieses ist die Erkenntnis aus dem Workshop und der Grund des Artikels. Ich habe bislang den Administrator immer in dieser Einstellung integriert und habe es mit XP nie ohne diesen probiert. Man lernt ja aus den Fehlern von früher und behält die Lösungen dann bei ...