Wer kennt das nicht? Dateien, die ein bestimmtes Alter überschritten haben, sollen automatisch gelöscht werden. Im aktuellen Fall ging es um automatisch generierte Backupdateien einer Datenbankanwendung. Die Anforderung besagte, dass diese für 14 Tage aufbewahrt werden sollen. Mit Hilfe eines VB-Skripts lässt sich die Anforderung lösen.
Nachdem der IMF (Intelligent Message Filter) mit SP2 für Exchange 2003 installiert wurde und die Konfiguration des IMF im ESM (Exchange System Manager) unter den Eigenschaften der Nachrichtenübermittlung und Aktivierung auf dem Virtuellen SMTP Server abgeschlossen wurde, ist es natürlich auch wichtig, dass ein regelmäßiges Update des IMF erfolgt. Microsoft stellt jeden ersten und dritten Mittwoch im Monat Updates für den IMF bereit.
4. September 2006, 19:14 Uhr
Kategorie: Sicherheit, Vista, Windows, Windows Server 2008
Mit NAP, der Network Access Protection, möchte Microsoft die Sicherheit von Netzwerken dadurch erhöhen, dass jedes Windows-System erst dann Zugang zum Netzwerk erhält, wenn es vorher festgelegte Sicherheitsanforderungen erfüllt. NAP ist also eine Richtlinien-Durchsetzungs-Komponente des Windows-Servers, welche jedes System prüft und ggf. Anpassungen automatisch durchführt. IT-Verantwortliche haben nun die Möglichkeit Richtlinien einzurichten, die den Zugriff auf das Netz so lange verhindern, bis der Client die Einhaltung dieser Richtlinien nachweist.
Weiterhin soll mit NAP das „Zusammenspiel“ zusätzlicher Technologien gefördert sowie der Schutz gegen Spy-/Malware und Viren erhöht werden, sobald Computer auf Unternehmensnetzwerke zugreifen. NAP wurde also entworfen, um dem Administrator ein weiteres Hilfsmittel im täglichen Berufsleben zur Verfügung zu stellen. NAP kann aber nicht verhindern, dass sich nicht autorisierte Anwender unerlaubten Zugang zum Netzwerk verschaffen, um somit evtl. Viren einzuschleusen oder Angriffe zu starten.
Eigentlich sollte NAP schon in Windows Server 2003 R2 integriert sein, kommt nun aber vermutlich erst mit Windows Server 2008 auf den Markt. NAP ist allerdings bereits in Windows Vista und den aktuellen Betas von Windows Server 2008 enthalten. Mit NAP werden die folgen drei Aspekte berücksichtigt:
1. Die Gültigkeit der Netzwerkrichtlinien
Wenn ein Computer eine Verbindung mit dem Netzwerk aufbauen möchte, wird zuerst der aktuelle Sicherheitsstatus des Clients überprüft, und zwar anhand der Zugangsrichtlinien, die der Administrator festgelegt hat. Kommt lediglich die NAP-Überwachung zum Einsatz, so wird eine Verletzung der Richtlinien zwar notiert, aber dem unsicheren Client trotzdem der Zugang zum Netzwerk gewährt. Ist stattdessen das NAP für die strikte Isolation konfiguriert, wird dem Client bei Nichterfüllung der Zugangsrichtlinien der Zugriff auf das Netzwerk verwehrt.
2. Die Einhaltung und Erfüllung der Netzwerkrichtlinien
NAP stellt dem Administrator diverse Werkzeuge zur Verfügung, womit sich die gewünschten Unternehmensrichtlinien leicht einrichten bzw. erreichen lassen. Computer, die diese Richtlinien nicht erfüllen, werden zunächst isoliert und in einen Quarantänebereich verschoben (sog. Netzwerkisolation).
3. Die Netzwerkisolation
Erfüllt ein Client die gewünschten Richtlinien nicht, so kann der Client in einen Quarantänebereich verschoben werden, um nachträglich die gewünschte Sicherheitskonfiguration nachzuholen. Alternativ kann dem Client aber auch der Zugriff auf das komplette Netzwerk oder auf bestimmte Bereiche verweigert werden. Schließlich ist es ebenfalls möglich einen Quarantänebereich für Gast-PCs zu erstellen, die somit keinen Zugriff auf das Unternehmensnetzwerk haben, aber z.B. ins Internet dürfen.
Bisher hat der Administrator eine Überprüfung des Benutzernamens und/oder der IP vorgenommen. Mit NAP bekommt er nun darüber hinaus die Möglichkeit, die folgenden festgelegten Policys (Richtlinien) zu prüfen:
Mit diesen Möglichkeiten wird eine weitere Hürde für den Zugang zu einem Netzwerk errichtet und dieses auf der anderen Seite natürlich weiter abgesichert. Zum Beispiel ist es nun möglich festzulegen, dass auf den Systemen der vorgeschriebene (und sich auf dem aktuellen Stand befindende) Virenscanner, das vorgeschriebene Betriebssystem und/oder die korrekt konfigurierte lokale Firewall installiert sein müssen. Diese Einstellungen sind gerade für Laptop-Anwender bzw. Heim-Arbeitsplätze sehr wichtig. So kann man sicherstellen, dass sich jedes System, das sich am Netzwerk anmelden möchte, sei es per VPN/RAS oder direkt, den Firmenrichtlinien entspricht. Anderenfalls ist eine Anmeldung nicht möglich. Durch diese Sicherheitsrichtlinien ist die Netzwerkkommunikation wesentlich sicherer, denn so ist gewährleistet, dass sich von einem Heimarbeitsplatz oder einem HotSpot kein Virus/Wurm/Trojaner/Mal-/Spyware sich ins Firmennetz einschleusen kann. NAP kann ebenfalls um Anwendungen von Drittanbietern erweitert werden, so dass ggf. noch andere Voraussetzung erfüllt werden müssen, wie z.B. Update-Stand der einzelnen Programme usw.
NAP umfasst Server- und Client-Komponenten:
Die Client-Komponente besteht aus dem SHA (= System Health Agent), der z.B. dafür sorgt, dass die Virenscannersignatur oder die Stände des Betriebssystemupdates an den Richtlinienserver übermittelt werden. Ein weiterer Teil der Client-Komponente ist der Quarantäneagent. Dieser ist für den Pflegestatus des NAP–Clients zuständig und kommuniziert diese Information an die darüber liegenden (SHA) und an die darunter liegenden (QEC = Quarantine Enforcement Client) Dienste. Die dritte und letzte Komponente des Clients ist die QEC (= Quarantine Enforcement Client )-Komponente. Es gibt für jeden Netzwerkverbindungs-Dienst einen Agenten der z.B. für DHCP, VPN-Verbindungen oder IPSec zuständig ist. Die SHAs übergeben SoHs (Statement of Health), die z.B. den Status der zuletzt installierten Betriebssystemupdates oder des Virenscanners prüfen und an die Quarantäneagenten übermitteln.
Screenshot von Windows Vista:
Die Server-Architektur von NAP besteht aus dem NAP-Server, dem IAS-Server, dem Quarantäneserver und einer Schicht mit SHV (= System Health Validators)-Komponenten. Der IAS-Server empfängt vom NAP-Server bzw. von der Komponente QES eine Liste mit den SoHs, die der Client über RADIUS an den Server übermittelt hat. Der IAS vermittelt zwischen dem NAP-Server und dem Quarantäneserver. Der Quarantäneserver erstellt Systemanalysen anhand der vorgegebenen Richtlinien und ist für die Kommunikation zwischen jeder SHV und dem IAS zuständig.
Die SHV-Komponente ist wie beim Client der SHA (= System Health Agent) für die Aktualität der Virenscannersignatur und der Betriebssystemupdates verantwortlich und übermittelt diese an den jeweiligen Richtlinienserver. Beispielsweise übermittelt ein bestimmter SHV die Informationen über den Virenscanner an einen bestimmten Richtlinienserver und eine andere SHV übermittelt die Stände des Betriebssystemupdates an einen anderen bestimmten Richtlinienserver.
Des Weiteren gestaltet sich der Quarantänebereich von NAP folgendermaßen:
Diese Überprüfungsarten können erweitert werden, indem Softwarehersteller SHAs für den NAP-Client und SHVs für den IAS-Server, den NAP-Server und ggf. für den Richtlinienserver herstellen.
Um in einer Active-Directory-Umgebung einen auf Windows 2000/2003 basierenden DHCP-Server zu integrieren, muss man Organisationsadministratorrechte besitzen. Gerade in größeren Netzwerken ist dies problematisch, da mehrere Domänen in einer Gesamtstruktur existieren können. Hier müssten die einzelnen Domänenadministratoren bei jeder Installation eines DHCP-Servers den Organisationsadministrator bitten, diesen neuen Server zu autorisieren.Um dieses Problem zu umgehen, müssen Berechtigungen in der Konfigurationspartition angepasst werden.
Gibt es eine Möglichkeit einen Snapshot von allen Benutzern zu machen, die eine Anwendung in Citrix geöffnet haben?Ja – zum Beispiel per Skript.
Das Script „Citrix_Dump.vbs“ liest die angemeldeten Benutzer einer Citrixfarm und gibt das Ergebnis in einer übersichtlichen HTML-Datei aus. Das Visual-Basic-Script lässt sich leicht für administrative Zwecke erweitern, um zum Beispiel direkt nur auf einem Benutzer zu prüfen, ob er eine Anwendung gestartet hat und wenn ja, auf welchem Server. Es ist daher eine schnelle Alternative zur Citrix-Konsole. Für die Hotline kann man die Funktionen auch in ASP abbilden, falls sie darüber schon andere Aufgaben wahrnimmt.
Am 23. August 2006 habe ich für Microsoft TechNet einen einstündigen Webcast gehalten zum Thema: „Active Directory richtig sichern und wiederherstellen“. Darin habe ich die wichtigen Hintergründe und Techniken vorgestellt, die beim Backup und Restore berücksichtigt werden sollten. Der Download ist möglich über:
… sorry, leider ist der Webcast nicht mehr erhältlich.
(Dieser Artikel beruht auf der Beta 2 von Exchange 2007. Einige Details können daher überholt sein.)
Microsoft Exchange 2007 führt zwei neue Techniken ein, die auf die Steigerung der Verfügbarkeit zielen. Es handelt sich hier um "Local Continuous Replication" und "Clustered Continuous Replication".
(Dieser Artikel bezieht sich auf Windows Server 2003 R2; die meisten Hinweise sind aber auch für andere Versionen anwendbar.)
DCDIAG überprüft den Status der Domänencontroller in Active Directory auf ihre Funktionsfähigkeit. Es prüft die Replikation, die Topologie und Funktion von Active Directory und liefert eine Zusammenfassung der Ergebnisse mit detaillierten Informationen zu jedem getesteten Domänencontroller und eine Diagnose etwaiger Sicherheitsfehler. Des Weiteren wird DNS (Domain Name System) bezüglich der folgenden Punkte geprüft: Konnektivität, Verfügbarkeit von Diensten, Weiterleitungen und Stammhinweise, Delegierung, dynamische Updates, Registrierung von Locatoreinträgen, externe Namensauflösung und Unternehmensinfrastruktur.
Images sind sehr beliebt. Die Technik, eine ganze Festplatte oder Partition sektorweise zu kopieren, ist schon recht alt und hat sich in vielen Fällen bewährt: Ein Image von einer Workstation lässt sich gut nutzen, um den Rechner zu „klonen“ und so zahlreiche gleich aufgebaute PCs zu erhalten. Viele Anwender nutzen Images auch, um ihren PC zu sichern – sollte etwas mit der Maschine sein, so lässt sich das letzte „gute“ Image einfach wieder zurückspielen, und das Problem ist verschwunden. Da liegt es doch nahe, diese 1:1-Technik auch für die Datensicherung von Servern einzusetzen. Oder?
Darauf gibt es nur eine klare Antwort: Nein. Ein Image ist fast nie zur Datensicherung eines Servers geeignet. In nahezu allen Situationen ist eine Wiederherstellung mit einem Image Ursache für schwer lösbare Probleme. Dasselbe gilt übrigens auch für „Snapshots“ von Servern auf Basis von SAN-Techniken oder auf Basis virtueller Maschinen. Warum ist dies so?
Ein Image konserviert einen bestimmten historischen Zustand einer Maschine: Die Daten auf der Platte werden genau so „eingefroren“, wie sie im Moment des Image sind (mit „Image“ sind im Folgenden auch alle verwandten Techniken gemeint wie SAN-Snapshots, VMware-Snapshots oder ähnliche). Darin sehen viele Anwender einen unschätzbaren Vorteil, weil sich so ja eben dieser historische Zustand problemlos wiederherstellen lasse – vorausgesetzt, die Image-Software arbeitet sauber, könne es ja gar keine Probleme geben, denn der Zustand nach der Wiederherstellung sei ja derselbe, als würde der Server einfach an der „eingeforenen“ Stelle weiterarbeiten. Dass dies für die meisten Serversysteme nicht ohne Weiteres zutrifft, liegt an der Komplexität moderner Serveranwendungen. Einige der zahlreichen Stolperstellen werden im Folgenden beleuchtet. Zur besseren Verständlichkeit werden einige Zusammenhänge dabei vereinfacht.
Eine Datensicherung muss sicherstellen, dass die gesicherten Daten konsistent sind. Online-Image-Techniken laufen Gefahr, an offenen Dateien oder an Transaktionen zu scheitern: Komplexe Applikationen, aber auch normale Dateioperationen umfassen mehr als nur die Daten auf der Festplatte. Oft stehen zusätzliche Daten im Arbeitsspeicher oder im Cache des Plattencontrollers. Wird hier ein einfaches Image angelegt, können diese Daten fehlen und eine scheinbar „gesicherte“ Applikation bei der „Wiederherstellung“ beschädigen. Zwar setzen moderne Image-Programme hier einige Techniken ein, um dieses Problem zu umgehen, das Risiko besteht aber trotzdem – insbesondere bei Online-Images.
Viele Anwendungen, vor allem Datenbanken, verteilen ihre Daten auf mehrere Speicherorte, die oft auf verschiedenen Partitionen oder sogar auf verschiedenen Servern liegen. In solchen Fällen kann die Wiederherstellung einer Partition per Image direkte Schäden hervorrufen, wenn die Zustände aller beteiligten Speicherorte nicht exakt gleich sind: Befindet sich etwa Partition 1 mit der Datenbank auf dem Stand von 11:01 Uhr, Partition 2 mit den Transaktionsprotokollen aber auf dem Stand von 11:12 Uhr, so sind Inkonsistenzen sehr wahrscheinlich. Abhilfe kann hier, wenn überhaupt, nur bei Einzelservern durch ein Offline-Image geschaffen werden (also: der Server wird heruntergefahren und das Image dann mit einem separaten Betriebssystem erzeugt). Ein solcher Ansatz taugt aber in der Regel nicht für eine laufende Datensicherung. Zwar arbeiten manche Image-Programme mit Applikationsschnittstellen zusammen, die die Konsistenz der Daten sicherstellen sollen (z. B. Windows VSS), doch stehen solche Schnittstellen nicht für alle Applikationen bereit.
Relativ unbekannt ist die Tatsache, dass ein Computer in einer Windows-Domäne über ein Anmeldekonto verfügt, das praktisch einem Benutzerkonto entspricht. Daraus folgt, dass auch ein Computer sich mit einem Kennwort an die Domäne anmelden muss. Dieses Kennwort wird zwischen dem Computer und dem Domänencontroller ausgehandelt und in bestimmten Zeitabständen erneuert. Wann dies geschieht, ist nicht ohne Weiteres nachvollziehbar. Genau hieraus erwächst aber ein Problem: Ein Image sichert natürlich auch das gerade aktuelle Kennwort des Computers mit. Es ist nun leicht möglich, dass nach dem Herstellen des Images das Computerkennwort neu gesetzt wird. Wenn die Maschine durch das Image auf den alten Stand zurückgebracht wird, kann sich der Computer nicht mehr an die Domäne anmelden. Die Lösungsmöglichkeit, den Computer aus der Domäne zu nehmen und neu hinzuzufügen, dürfte bei einer Workstation noch tolerabel sein, bei einem Server aber in der Regel nicht: Macht ein einfacher Terminalserver dies meist noch mit, werden ein Exchange-Server oder gar ein Domänencontroller das schon ganz anders sehen.
Diese Problematik ist nicht auf Windows-Rechner beschränkt, denn das Prinzip von lokal gespeicherten Kennwörtern, die ohne direkten Benutzereingriff geändert werden, gibt es plattformübergreifend in vielen Applikationen.
Eine Serverklasse, bei der vollständig vom Einsatz von Image-Techniken jeder Art abzuraten ist, sind Domänencontroller. Der Grund liegt in der Komplexität des sehr leistungsfähigen Replikationssystems: Alle Domänencontroller einer Domäne verfügen durch die Replikation über denselben Datenbestand. Dabei verwaltet jeder einzelne Domänencontroller seine Daten selbst und gleicht sie mit seinen Replikationspartnern ab. Damit die Replikation leistungsfähig und robust ist, wissen die Domänencontroller sehr viel über ihre Partner: So werden etwa die Seriennummern einzelner Objektänderungen gespeichert und den Replikationspartnern übermittelt, damit jeder Server zweifelsfrei feststellen kann, ob er auf dem aktuellen Stand ist oder noch Daten ändern muss. Genau an dieser Stelle wirkt eine Image-Wiederherstellung oft fatal. Warum das so ist, beleuchtet das folgende (vereinfachte) Beispiel:
Die Datensicherung und Wiederherstellung des Active Directory kann nur über den System State erfolgen. Mehr dazu:
Hinweis Es gibt eine Methode, einen DC, der mit einem Image wiederhergestellt wurde, zur ordentlichen Replikation mit seinen Partnern zu bewegen. Der Ansatz erzwingt das Erzeugen einer neuen „Invocation ID“, mit der die AD-Datenbank von den Replikationspartnern identifiziert wird. Diese Technik wird angeblich auch von einigen moderneren Imaging-Programmen verwendet (wohlgemerkt: Nur von wenigen – und die Nutzung von VSS hat damit nichts zu tun. Vor allem aber wird die Technik nicht von Snapshots à la VMware oder SAN genutzt).
Hebelt dies nun meine Argumentation aus? Nein, das tut es nicht:
Aus diesen Gründen bleibe ich dabei, Images von Domänencontrollern abzulehnen.
Hier übrigens einige erhellende Artikel:
Das Directory-Service-Team bei Microsoft meint:
Acronis, Hersteller eines der beliebtesten Imaging-Programme, sagt zu dem Thema:
Claus Greck stellt die Problematik ausführlich dar:
Viele komplexe Anwendungen bieten eigene Schnittstellen für die Datensicherung an, z. B. Exchange Server oder SQL Server. Wenn diese Schnittstelle von einem Datensicherungsprogramm angesprochen wird, werden oft zusätzliche Vorgänge ausgeführt, etwa eine Prüfung der Datenbanken oder eine Defragmentierung. Werden solche Prozesse nicht ausgeführt, weil statt eines „ordentlichen“ Backups nur Images hergestellt werden, kann dies Beschädigungen der Datenbestände zur Folge haben, die unter Umständen erst bemerkt werden, wenn es viel zu spät ist und bereits zusätzliche Probleme entstanden sind. Ein klassisches Beispiel für dieses Problem ist der gefürchtete „-1018“-Fehler in Exchange (vgl. http://www.msxfaq.net/notfall/-1018.htm).
Es gibt noch zahlreiche weitere Gründe, die gegen den Einsatz von Images oder Computer-Snapshots als „Sicherungsstrategie“ sprechen. Daher die Empfehlung: Finger weg von Images! Server müssen mit einer ordentlichen Online-Datensicherung gesichert und mit einem herstellerunterstützten Verfahren wiederhergestellt werden.
Wer mit Gruppenrichtlinien arbeitet, sollte sich auch Gedanken über die Sicherung sowie Wiederherstellung der GPOs (Group Policy Object) machen. Das Sichern von GPOs ist zwar möglich, das Rücksichern einzelner Richtlinien gestaltet sich da schon schwieriger. Durch das Sichern eines Gruppenrichtlinienobjektes werden die Daten des GPOs in das Dateisystem kopiert. Folgende Informationen sind darin enthalten:
Translate EN