Es gibt wahrscheinlich tausende Einträge über Google bzgl. dieses Thema’s, aber ich hatte heute wieder einen Fall – daher dieser Niederschrieb 😉
In einem Active Directroy (AD) von Windows lassen sich ganz bequem Kennwortrichtlinien erfassen und einstellen.
Allerdings muss man hierbei zwingend unterscheiden zwischen „konfigurieren“ und „nicht definieren“.
In meinem Beispiel dreht es sich um einen Windows Server 2012 R2 als DC und einen Exchange 2013 (auf einem sep. Win2012R2).
Als die 2012er Domäne installiert wurde, hatte die Default-Domain-Policy die Grundeinstellung, das die AD-Passwörter nach 42 Tagen auslaufen und geändert werden müssen – das war mir zu kurz.
Leider habe ich dann darauf hin die beiden betroffenen Punkte auf „nicht definiert“ geändert und dachte, das dies korrekt sei – leider falsch.
Die Richtlinie sah nun wie folgt aus:
Die hatte leider zur Folge, das die Standardeinstellungen des AD’s von 42 Tagen griffen, da die Richtlinien ja nicht definiert wurden ;-(
Nach ca. 35 Tagen wurde ich wieder erneut aufgefordert, mein Kennwort erneut zu ändern – hä?
Nunja, nach genauerer Überlegung kam mir dann, das ich die Richtlinie falsch konfiguriert hatte.
Nach meiner Änderung sah die Richtlinie wie folgt aus:
Nun war die Einstellung korrekt, d.h. das Kennwort läuft nun nicht mehr ab.
Vielleicht hilft es ja dem ein oder anderen auch mal, wenn er über so etwas stolpert …
Während die Downloads laufen, können auf dem zukünftigen Exchangeserver schon mal die erforderlichen Rollen/Features installiert werden. Das geht einfach über den Servermanager – oder über die Powershell mit …
Nach dem erforderlichen Neustart des Servers können nun die 3 Komponenten (FilterPack, FilterPack SP + UCMA) installiert werden.
Installation:
Nun folgt die eigentliche Installation des Exchangeservers. Zunächst sollten dazu die Setupdateien extrahiert werden. Einfach einen Doppelklick auf den 1,5 GB großen Download machen und einen Ordner (z.B. D:\_ex2013\entpackt) angeben.
Anschließend kann die „setup.exe“ ausgeführt werden (ich habe dies sicherheitshalber als „Administrator“ ausgeführt).
exchange 2013
Man wird nun gefragt, ob nach Updates gesucht werden soll, welche beim Setup bereits berücksichtigt werden – ich würde dies empfehlen und stimme dem daher zu …
exchange 2013
Momentan gibt es zwar noch keine, aber in Zukunft wird sich das wohl ändern …
exchange 2013
Nun kann es losgehen …
exchange 2013
Lizenzvertrag zustimmen…
exchange 2013
Hier muss jeder selbst entscheiden, ob Daten an Microsoft (und/oder NSA 😉 ) gesendet werden sollen.
exchange 2013
Da ich nur einen Exchange Server plane (und betreibe), kommen alle Serverrollen auf die Kiste …
exchange 2013
Pfad für die Exchangeserver Installation auswählen.
exchange 2013
Geben Sie nun den Namen der neuen Exchangeserver Organisation an…
exchange 2013
Die neue Prüfung auf Schadsoftware soll aktiv bleiben. Hier die Standardeinstellung Nein übernehmen.
exchange 2013
Nun prüft das Setup die Vorrausetzungen (dauert ggf. ein paar Minuten), welche im Normalfall nur Warnungen aufzeigt, um dann die Installation zu starten. Mit einem Klick auf installieren kann diese gestartet werden.
exchange 2013
Nun arbeitet das Setup und installiert den Exchangeserver – dauerte bei mir ca. 30 Minuten.
exchange 2013
Nun ist der Exchangeserver installiert.
Bevor nun weitergearbeitet wird, sollte nun erstmal der Server rebootet werden.
Nach dem Neustart kann über die neue Exchangeverwaltungskonsole (https://localhost/ecp/) die Konfiguration gestartet werden.
Beim vergangenen MS-Patch-Day wurde nun auch ein Patch (KB2852386) freigegeben, mit welchem es nun auch unter Windows 7 möglich ist, nicht mehr benötigte Windows-Updates zu bereinigen.
Zu finden ist das ganze unter Systemlaufwerk (meistens C) -> RechtsKlick -> Eigenschaften -> Bereinigen ( und dann etwas warten …)
Einzige Vorraussetzung: Windows 7 Service Pack 1 (SP1) muss bereits installiert sein.
Der heutige Tag startete leider nicht ganz so einfach. Ein Kollege kommt nach 2 Wochen Urlaub wieder zurück, startet sein Laptop und meldet sich an seinem Windows 7 an – zur Überraschung findet er nach der Anmeldung ein komplett neues Profil wieder.
Windows zeigt zunächst lediglich den Hinweis, das ein temporären Profil angemeldet wurde. In der Windows Ereignisanzeige fand sich folgendes: „Fehler bei der Anmeldung mit dem Benutzerprofildienst. Das Benutzerprofil kann nicht geladen werden“. Nach einer ersten Analyse war die Ursache dafür ein Update von Skype.
Folgendes hatte ich zunächst, leider erfolglos, versucht:
Anmelden als administrativer User (z.B. Administrator)
Umbenennen der vorherigen Userprofils z.B. C:\Users\<NormalerUser>.defekt
erneute Anmeldung des Users <NormalerUser> (erstellt wieder das Userverzeichnis)
Anmelden als administrativer User (z.B. Administrator)
Löschen des (neuen und leeren) Profilverzeichnisses C:\Users\<NormalerUser>
Umbenennen der Verzeichnisses C:\Users\<NormalerUser>.defekt nach C:\Users\<NormalerUser>
erneute Anmeldung des Users <NormalerUser>
mit Viel Glück ist das Profil ggf. wieder gerettet (bei mir leider nicht)
Leider half dies bei meinem Problem nicht – der User wieder nach wie vor mit einem temporären Profil angemeldet. Nachfolgende Schritte halfen jedoch wieder zu einem funktionierenden Profil.
Anmelden als administrativer User (z.B. Administrator)
Öffnen der „Systemsteuerung“ -> „System“ -> „Einstellungen ändern“
anschließend auf „Erweitert“ -> „Benutzerprofile“ -> „Einstellungen“
wähle nun das Profil aus, welches gelöscht werden soll und lösche es
Öffne nun den Registrierungseditor (Start -> Suchfeld -> regedit)
Wechsle in der Registry auf folgenden Unterschlüssel:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Wähle nun die SID des Users aus, wessen Profil du gerade gelöscht hast. Lösche nn die SID.
erneute Anmeldung des Users <NormalerUser>. Nun wird ein frisches Userprofil erstellt
wieder anmelden als administrativer User (z.B. Administrator).
Kopiere nun noch den Inhalt des alten Profiles in das frische (oder benenne es um). Nach einer erneuten Anmeldung des Users <NormalerUser> sollte das alte Profil wieder verfügbar sein.
Kumulatives Sicherheitsupdate für Internet Explorer (2761451) betrifft: Microsoft Windows,Internet Explorer
Kritisch
MS12-072
Sicherheitsanfälligkeiten in Windows Shell können Remotecodeausführung ermöglichen (2727528) betrifft: Microsoft Windows
Kritisch
MS12-073
Sicherheitsanfälligkeiten in den Microsoft Internetinformationsdiensten (IIS) können Offenlegung von Information ermöglichen (2733829) betrifft: Microsoft Windows
Kritisch
MS12-074
Sicherheitsanfälligkeiten in .NET Framework können Remotecodeausführung ermöglichen (2745030) betrifft: Microsoft Windows, Microsoft .NET Framework
Kritisch
MS12-075
Sicherheitsanfälligkeiten in Windows-Kernelmodustreibern können Remotecodeausführung ermöglichen (2761226) betrifft: Microsoft Windows
Hoch
MS12-076
Sicherheitsanfälligkeiten in Microsoft Excel können Remotecodeausführung ermöglichen (2720184) betrifft: Microsoft Office
Da setzt man sich eine virtuelle Testumgebung auf, konfiguriert seine Systeme wie man sie benötigt – und dann das: man arbeitet längere Zeit nicht mehr damit (aufgrund anderer Prioritäten) oder kommt schlicht weg nicht mehr dazu (längerer Urlaub) und schon hat man das Passwort des Administrator’s nicht mehr parat.
Soll man jetzt die komplette Testumgebung neu installieren und konfigurieren?
Mir ist es leider heute genau so ergangen – allerdings habe ich im Internet eine (zugegeben erschrocken einfache – wenn nicht sogar die einfachste) Methode gefunden, das Passwort eines Users zurückzusetzten.
Ein physikalischer Zugriff (oder bei VMs ein Konsolenzugriff) ist erforderlich.
Geht wie folgt vor:
du brauchst eine original Windows Server DVD (getestet mit Server 2008 R2 und SBS 2011) und boote davon.
Sprache auswählen und weiter.
unten “Repair your Computer” anklicken
aktuelle Instanz auswählen und weiter
als Recovery Option den Punkt “Command Prompt” auswählen
am Command Prompt wechseln nach D:\Windows\system32
Hinweis: Die Recovery Option erkennt die Windowsinstallation meist unter Laufwerk D!
Jetzt kommt der eigentliche „Trick“:
Die Datei utilman.exe (das ist die Eingabehilfe) umbenennen
(move Utilman.exe Utilman.exe.bak)
eine Kopie der cmd.exe erstellen als utilman.exe
(copy cmd.exe Utilman.exe)
Das war der aufwendige Teil – aber das war’s fast schon. Jetzt nur noch DVD raus und Rebooten. Nach dem normalen Start bei der Login-Aufforderung reicht jetzt ein Klick auf das Symbol unten links, und schon öffnet sich statt der Eingabehilfe ein CMD-Fenster. Was jetzt kommt, dürfte klar sein:
[important]net user administrator neuespasswort[/important]
Und schon kann man sich als Administrator mit dem gerade gesetzten Passwort anmelden. Nicht vergessen, später die alte utilman.exe wieder zurückzukopieren, wir wollen doch nicht, dass jemand den Rechner hackt, oder?
