Weiterentwicklung des AD beim Windows Server 2012
25. Mai 2012
Vereinfachung beim Erstellen von Domänencontrollern (DCs), Ausräumen von Problemen, die das Virtualisieren von DCs bringt und Verbesserungen im Bereich des Identity Managements – diese Themen adressiert Microsoft mit dem Active Directory (AD), das beim Windows Server 2012 zum Einsatz kommt. Allerdings darf man sich dabei keine revolutionären Schritte erwarten – denn für das AD gilt: Kompatibilitätsproblem dürfen nicht entstehen – dazu ist das AD zu stark verbreitet. Microsoft schätzt, dass weltweit etwa 75 Prozent aller kleineren und mittleren Unternehmen das AD einsetzen. Sean Deuby stellt diese Neuerungen in einer Artikelreihe vor.
Bei der Erwartungshaltung zu den Verbesserungen im Bereich des Active Directory (AD) darf der Ausgangspunkt nicht in Vergessenheit geraten: Revolutionäre Umwälzungen wird es nicht geben, den zu viele Unternehmen haben das AD im Einsatz und daher wird ein Bruch mit der Historie von den Anwendern nicht akzeptiert – Microsoft spricht davon, dass weltweit etwa 75 Prozent aller kleineren und mittleren Unternehmen das AD einsetzen. Daher gab es in Bezug auf das AD von Betriebssystemversion zu Betriebssystemversion beim Windows Server in der Regel nur kleinere Modifikationen zu vermelden.
Doch es sind vor einem derartigen Szenario vor allem die evolutionären Schritte gefordert, die sich an dem aufkommenden Bedarf für das AD ausrichten. Im konkreten Fall – beim Windows Server 2012 – beziehen sich diese Schritte auf drei Felder: die Data Governance, das AD selbst sowie der Bereich der Virtualisierung.
Data Governance
Ehe die Verbesserungen im Bereich des Identity Management von Windows Server 2012 tiefgehender besprochen werden, muss man eine Neuerung hervorheben, die bereits beim Windows Server 2008 Release 2 Einzug gehalten hat: Die File Classification Infrastruktur (FCI). Diese Änderung erscheint auf den ersten Blick so, als wäre es lediglich eine Funktionalität im Bereich des Dateisystems, und weniger ein Feature, das sich um die Identity dreht. Bei der FCI handelt es sich um die Fähigkeit, Eigenschaften auf einem Dateiserver zu vergeben, die eine Klassifizierung von Dateien ermöglichen.
Damit wird eine automatische Kategorisierung der Dateien angestrebt, abhängig von dem Ordner in dem die Datei liegt oder entsprechend des Inhaltes der Datei. So lassen sich Aufgaben in Bezug auf die Dateiverwaltung ausführen. Je nach Dateikategorie kommen dann verschiedene Befehle zur Ausführung. Aber auch Berichte über die Verteilung der Kategorie-Eigenschaften auf einem Dateiserver stehen damit zur Verfügung. Dabei sind sowohl einzelne Benutzer als auch Applikationen in der Lage, eine Datei zu klassifizieren. Wenn es um die Suche nach Informationen geht, kann die FCI ebenfalls helfen – etwa wenn man in den Daten nach sensiblen Worten oder Mustern sucht – wie etwa die Sozialversicherungsnummer. Dann lassen sich diese Dateien auch als sensible Informationen ausweisen, die personenbezogene Daten enthalten.
Auf diese Weise können Administratoren zum Beispiel automatisch Dateien von einem teuren Online-Speicher auf einen billigeren und etwas langsameren Speicher verschieben – abhängig von der Klassifizierung der Dateien und von den Richtlinien, die definiert sind. Es lassen sich damit Lösungen vorgeben, um Dateien nach einer bestimmten Zeit nicht mehr weiter zu führen.
Der Zugang zum FCI erfolgt über den FSRM (File Server Resource Manager) – ein Tool, das über die Rolle eines Dateiservers unter den Verwaltungswerkzeugen zur Verfügung steht. Mit diesem Werkzeug werden auch Kontingente definiert oder Speicher-Reports erstellt. Für das Thema der Identity und die Sicherheits-Features beim Windows Server gilt die FCI als eine wichtige Voraussetzung: Sie erlaubt den Einsatz der Dynamic Access Control (DAC). Bei dieser Funktionalität handelt es sich um eines der neuen Features des Windows Server 2012.
Abstrakt betrachtet dreht sich bei der DAC alles um die Information Governance: Damit wird klassifiziert, welche Daten sich auf den Dateiservern befinden. Dabei wird ein hoher Grad an Kontrolle über die Daten erreicht. Wobei man auch im Rahmen eines Audits belegen kann, dass man diese Kontrolle besitzt. Dieser Aspekt wird in aktuellen IT-Infrastrukturen immer wichtiger, da der Datenbestand enorm anwächst, die externen Bedrohungen für die Daten steigen und zudem die Kosten nach einem Einbruch aus dem Ruder laufen. Auf der Möglichkeit, über die FCI die Daten zu klassifizieren – sie mit Tags zu versehen – kann die DAC aufsetzen, um die dazu nötigen Richtlinien auch durchsetzen zu können.
Active Directory und die Identitäten
Das Kategorisieren der Daten auf einem Dateiserver ist schön und gut, doch es wird kaum nützlich sein, wenn man nicht den Zugriff auf diese Daten kontrollieren kann. Dazu sind eine höhere Granularität und eine detailliertere Zugriffssteuerung nötig. Um hier ansetzen zu können, sind signifikante Änderungen zum einen an der LSA (Local Security Authority) auf dem Dateiserver und zum anderen im AD nötig. Hier sollen nur die Änderungen im Bereich des AD zur Sprache kommen, die beim Windows Server 2012 zum Einsatz kommen.
Um die nötigen Kontrollmechanismen auf den Dateiserver bereit zu stellen – sowie auf allen Ressourcen, die die ACLs (Access Control Lists) in den kommenden Betriebssystemversionen unterstützen – muss das AD eine Funktionalität wie die sogenannten Claims abbilden können. Dabei handelt es sich um eine andere Facette des Zuweisen von Identity:
Ein Claim ist eine Information, wie etwa eine Mailadresse, die von einer vertrauenswürdigen Quelle – wie etwa die lokale Zertifikatsherausgabestelle – über ein Objekt (wie ein Benutzerkonto) ausgegeben wird. Diese Claims erweisen sich dadurch als eine extrem wichtige Größe im Bereich der Cloud Identity. Denn mit ihnen kann im Zuge eines Federation-Konzepts eine lokale Identität bis in die Cloud “ausgedehnt” werden.
Bis zum Windows Server 2012 hatte das AD noch keine Kenntnisse über die Claims. Es standen lediglich die Active Directory Federation Services (AD FS) zur Verfügung, die sich um die Transformation der AD-Attribute zu den Claims kümmerten. Die Claims dagegen wurden in erster Linie von externen Diensten verwendet, denn die herkömmlichen Applikationen in einem Unternehmen können mit ihnen nichts anfangen. Doch diese Situation ändert sich – und das AD ändert sich auch, um damit zu Recht zu kommen. Diese Modifikation im AD ist sehr wichtig und jeder Administrator, der sich um das AD zu kümmern hat, sollte sich mit diesem Claims-basierten Identitätskonzept vertraut machen. Denn das wird die künftige Richtung sein, in die sich das AD bewegen wird.
Einsatzerleichterungen beim AD
Beim Windows Server 2012 hat Microsoft aber auch deutliche Erleichterungen geschaffen, die den Einsatz des AD betreffen. Wer sich schon einmal eine Zeit in den AD-bezogenen Foren herumgestöbert hat, der hat schnell erkennen können, dass die AD-Verantwortlichen viele Fragen haben – etwa zu Adprep, zu Dcpromo, zum Duplizieren und Virtualisieren von Domänencontrollern (DCs) sowie zu allen Einsatzentscheidungen, die das DNS (Domain Name System) betreffen. Diese Verbesserungen im Bereich des AD rangieren alle unter der Rubrik “Evolution” – den sie verbessern die bestehende AD-Funktionalität.
Das Heraufstufen der DCs wurde stark vereinfacht. Das AD-Entwicklerteam von Microsoft gibt dazu die Losung aus: “Adprep und Dcpromo sind tot”. Das Kommando Dcpromo ist nun im “Active Directory Domain Services Configuration Wizard” eingebunden, der seinerseits komplett im Servermanager integriert ist. Damit wird die Aufgabe weitaus einfacher, den der Konfigurations-Assistent erledigt eine enorme Anzahl von Aufgaben – sozusagen unter der Haube – und macht die Arbeit für den Administrator damit so einfach wie möglich.
Dazu gehört zuerst das automatische Abwickeln der Schritte, die mit adprep /forestprep und /domainprep bisher zu vollziehen waren. Wer es nach wie vor “von Hand” machen will, der kann das natürlich auch noch selbst machen. Doch bei Microsoft hat sich in der Praxis gezeigt, dass es ein Fehler war, den Adprep-Prozess für die Administratoren sichtbar zu machen. Denn diese Aufgabe hat die Systembetreuer zurückschrecken lassen und zu einer hohen Zahl von Anrufen beim Support geführt – weitaus mehr, als durch wirkliche Probleme im Zuge von Adprep aufgekommen sind.
Der Prozess des Hochstufens zum DC führt nun eine genaue Validierung der unternehmensweiten Voraussetzungen durch, ehe der Einsatz erfolgt. Wenn man ein größeres Problem in seiner bestehenden AD-Umgebung hat, läuft der Vorgang nicht weiter. Zudem wird der gesamte Prozess nun wesentlich stabiler – vorübergehende Netzwerkausfälle lassen sich nun berücksichtigen und zudem ist der komplette Vorgang aus der Ferne – sprich remote – steuerbar.
Virtualisierung von Domänencontrollern
Eine weitere Vereinfachung beim Einsatz des AD ist das Anlegen von virtuellen DCs. Es sollte ein narrensicherer Vorgang sein und wenn das erreicht ist, wird auch das Klonen eines DC zu einer problemlosen Aufgabe. Das Wiederherstellen eines virtuellen DC aus einem Image-Backup oder aus einem früheren Snapshot war bisher eine fehlerträchtige Aufgabe – den das Rollback der USN bereitete Probleme. Dabei konnte es dazu kommen, dass die komplette AD-Datenbank in einer Domäne oder einer Gesamtstruktur “zerschossen” wurde. Denn anders wie bei einem normalen Wiederherstellungsvorgang, wusste der wiederhergestellte DC nichts davon, dass er von einem “älteren” Backup stammt.
Bei den Active Directory Domain Services (AD DS) ab dem Windows Server 2012 gibt es die sogenannte VM-Gen ID. Es handelt sich dabei um einen 64 Bit großen Identifier (ähnlich einer GUID), die mit dem Hypervisor verknüpft ist. Der Zweck der VM-Gen ID lautet: Snapshots von Instanzen von virtuellen Maschinen (VMs) erkennen und sie an die VM übergeben. Mit diesem Hinweis kann der DC Mechanismen wie die Safeguards einsetzen, um die USN-Rollbacks zu unterbinden.
Das Klonen von DCs wird aufgrund dieser Optimierungen weitaus sicherer und lässt sich damit im realen Betrieb auch sinnvoll einsetzen. Denn das Kloning hat dann auch ein großes Potenzial: Damit wird der eigentliche „Heraufstufenb-Prozess“ zu einer sehr seltenen Angelegenheit – denn man kann ja einen bestehenden DC klonen und daraus einen neuen DC erstellen. Das ist zudem eine sehr schnelle Option – im Verglech mit dem bisherigen Vorgang.
Aber auch in einem anderen Kontext verspricht das Klonen eines DC große Vorteile: Die Wiederherstellung einer Gesamtstruktur nach einem katastrophalen Ausfall. Um in heutigen Gesamtstrukturen eine Wiederherstellung auszuführen, wird zuerst als Ausgangspunkt für jede Domäne in der Gesamtstruktur ein DC wiederhergestellt. Dann werden mit Hilfe von Dcpromo in der Umgebung die weiteren DCs angelegt – solange bis genügend Systeme aktiv sind, um die Arbeitslast zu stemmen.
Doch dabei erweist sich der Dcpromo-Vorgang als das Problem: Diese Vorgehensweise ist sehr zeitaufwändig, selbst wenn man die Software in Form von „IFM“ (Install From Media) aufspielt oder einen Hochstufprozess über das Netzwerk ausführt. Daher ist die Aussage „Die Gesamtstruktur ist ausgefallen“ ein wahrer Alptraum für den AD-Verantwortlichen. Jede Minute, die man diese Situation schneller beheben kann, schlägt sich in eingesparten Kosten nieder – bei großen Gesamtstrukturen können hier erstaunliche Beträge auflaufen. Mit dem sicheren Klonen der DC verliert dieses Szenario allerdings seinen Schrecken.
