Verwaltung/Änderung der lokalen Administratoren-Kennworte
Problem: Ihr verwendet für alle Workstations das Gleiche Kennwort. Das spricht sich irgendwann rum, weil man es dem einen gibt, dann dem anderen, alle geloben Verschwiegenheit, am Ende kennt es jeder.
Das Kennwort auf den Workstations lässt sich ganz einfach für alle Computer in regelmässigen Abständen ändern und zurücksetzen:
Vorab das Wichtigste: Stichwort Sicherheit
Die Kennworte im GPP XML im cpassword Attribut sind mit AES256 Bit verschlüsselt, das gilt als Sicher. Ärgerlicherweise ist die Methode veröffentlicht, wie man das verschlüsselte Kennwort wieder in Text auflösen kann. Der Client kann das ja auch, sonst könnte er das Kennwort nicht setzen. Mehr dazu am Ende des Artikels. Trotzdem denke ich, es gibt 1000 schlechtere Wege das Adminkennwort zu ändern, zB per Batchdatei, dann liegt das Kennwort als Plaintext vor und man muss sich garnicht anstrengen, oder man übermittelt es mit Tools vom Server aus, aber die RPC Connection ist ja auch nicht verschlüsselt solange man kein IPSec einsetzt, also kann das Kennwort über das Netzwerk mitgelesen werden. So gesehen ist ein AES verschlüsseltes Kennwort im XML die wesentlich bessere Alternative, denn der "Hack" ist weniger bekannt.
Meine Empfehlung zum Umgang: Ihr ändert das Kennwort alle 6 Monate, lasst aber die GPO immer nur für einen kurzen Moment aktiv, bis alle Rechner die GPO übernommen haben und dann löscht ihr die Konfiguration. Jetzt ist das XML im SYSVOL als Angriffsziel nicht länger als Notwendig lesbar, zudem filtern wir die GPO. Wir entfernen die Gruppe der Authentifizierte Benutzer und fügen die Domänen-Computer hinzu. Jetzt muss sich der Angreifer schon anstrengen, da er als Mitglied der Authentifizierten Benutzer nicht mehr das Recht hat das XML zu Lesen.
Siehe auch: Filtern von Gruppenrichtlinien
- Computerkonfiguration\Einstellungen\Systemsteuerungseinstellungen\Lokale Benutzer und Gruppen
-> Neuer Benutzer - Benutzer Administrator (integriert) über das Dropdown auswählen, das funktioniert für jede Sprache, denn dieser "Integriert" Benutzer wird automatisch über die Wellknown SID ausgelöst.
- Kennwort vergeben und bestätigen
- Kennwort läuft nie ab und Konto läuft nie ab aktivieren
- Da der Computer Mitglied einer Domäne ist, kann der Account selbst gesperrt werden, wenn er das nicht schon längst ist. Er wird nicht gebraucht und ist schon seit Vista per Defaultverhalten deaktiviert.
Ab Server 2012 erscheint nun ein Warnhinweis:
Kurze Historie: Die Group Policy Preferences sind ein gekauftes Produkt. Das ist (war) der PolicyMaker von Desktopstandard. Diese haben sich damals die einfachste Möglichkeit überlegt, wie man verschlüsselte Passworte von Rechts nach Links transportieren kann:
Zur Wahl standen:
- per PKI und Zertifikat? Nein, das wäre zu Aufwendig, kein Kunde hat ne PKI, oder führt sie ein, nur um Kennworte in einem XML File zu verschlüsseln. Der Weg scheidet aus.
- Das Kennwort zur Verschlüsselung wird bei Installation generiert und dann verteilt? Hä? Das macht ja keinen Sinn ein Kennwort zu verteilen um anschliessend Kennworte verschlüsseln zu können. Wie soll das Kennwort selbst denn verschlüsselt und damit geschützt übertragen werden? -> Henne und Ei :-(
- Auf jedem Rechner per Hand eintippen? Seit ihr wahnsinnig? Management by Turnschuh ist keine Lösung
- Ok, beste Methode: Wir schreiben die Vektor und den Key hardcodiert in die DLL. BINGO! Das haben sie gemacht.
In der DLL des Produkts steckt nun Schlüssel und Schloss und ist auf jedem Computer gleich. DesktopStandards Argument war: Es sind ja nicht so viele Kunden und "sehen" tun sie sich nicht, also ist es egal, daß jeder über den Selben Schlüssel und Schloss Mechanismuss verfügt. Es ist von allem Übel das Kleinste und sicherheitstechnisch überschaubar, anhand der geringen Anzahl von Kunden/Installationen.
Dummerweise hat nun Microsoft das Produkt erworben und die Technik beibehalten und wie wir wissen, hat Microsoft "ein paar" Kunden mehr ... Jetzt kommt die Stolperfalle: Die EU Importrichtlinie zwingt die Hersteller von Verschlüsselungstechnologien ausserhalb der EU dazu, ihre Technik offenzulegen, wenn sie diese Produkte in die EU exportieren möchten. Jeder der einen Individuellen Schlüssel bei der Installation erzeugt (Beispiel: Truecrypt) kann ruhig schlafen, denn seine Offenlegung betrifft nur den Algorythmus, nicht den Schlüssel, der ist ja individuell nach Installation. Bei Microsoft ist aber nun mal der Schlüssel Bestandteil des Produkts und damit ist er Bestandteil der Technik und jetzt muss der Schlüssel offen gelegt werden.
Unglaublich, aber wahr
Group Policy: Preferences Extension Data Structure
- 2.2.1.1.4 Password Encryption
All passwords are encrypted using a derived Advanced Encryption Standard (AES) key.<2>
The 32-byte AES key is as follows:
4e 99 06 e8 fc b6 6c c9 fa f4 93 10 62 0f fe e8
f4 96 e8 06 cc 05 79 90 20 9b 09 a4 33 b6 6c 1b - 6 Appendix A: Product Behavior
<2> Section 2.2.1.1.4: The seed value used to generate the key is the sequence of characters:
0x71 0x46 0x32 0x0f 0x64 0x10 0x00
... und so wirds gemacht: GPP Password Retrieval with PowerShell