Viel Neues beim Active Directory

Unter Windows Server 2008 lassen sich jetzt mehrere Richtlinien für Kennwörter definieren,
sodass Anwender in besonders sensiblen Bereichen des Unternehmens komplexere Kennwörter verwenden
können als andere. Insbesondere lassen sich Kennwortrichtlinien nun auch einzelnen OUs
(Organizational Units) zuweisen. Wichtig für diese neue Funktion ist die OU "Passwort Setting
Container". In dieser OU speichert Windows Server 2008 nach Erstellung die "Passwort Settings
Objects" (PSO). Eine PSO enthält alle notwendigen Einstellungen zur Konfiguration von
Kennwortrichtlinien. Sicherheitsrichtlinien für Kennwörter unterstützen jetzt auch globale
Sicherheitsgruppen. Spezielle Kennwortrichtlinien für einzelne Anwender, Gruppen oder OUs,
überschreiben automatisch die Einstellungen in der "Default Domain Policy".

Neue Domänen-Controller

Eine weitere Neuerung stellen die schreibgeschützten Domänen-Controller dar (Read-only Domain
Controller, RODC). Diese Domänen-Controller erhalten die replizierten Informationen der normalen
Domänen-Controller und nehmen selbst keine Änderungen entgegen. Durch diese neue Funktion lassen
sich auch Domänen-Controller in kleineren Niederlassungen betreiben, ohne das Sicherheitskonzept
eines Unternehmens zu beeinträchtigen. Ein RODC kennt zwar alle Objekte im Active Directory (AD),
speichert aber nur die Kennwörter vorher definierter Benutzer. Versucht ein Angreifer die
Kennwörter aus der Datenbank des Controllers auszulesen, sind die Konten der restlichen Domäne
geschützt. Schreibende – also normale – Domänen-Controller richten keine Replikationsverbindung zu
RODCs ein. Auch wenn diese Rolle an den von Windows NT 4.0 bekannten Backup-Domänen-Controller
(BDC) erinnert, so hat sie nichts mit dieser alten Funktion gemeinsam, sondern stellt eine
komplette Neuentwicklung dar.

Haben Systemverwalter auf einem RODC das DNS (Domain Name System) installiert, so handelt es
sich bei diesem Server um einen Read-only-DNS-Server. Dabei gelten die gleichen Einschränkungen wie
für einen RODC. Ein Read-only DNS nimmt nur Änderungen von normalen DNS-Servern entgegen und
akzeptiert selbst keine Änderungen. Ein solcher Server steht für Benutzer als normaler DNS-Server
für Abfragen zur Verfügung, unterstützt aber keine dynamische DNS-Registrierung. Versucht sich ein
Client zu registrieren, erhält er vom DNS-Server eine Rückinformation, dass dieser keine
Aktualisierung akzeptiert. Im Hintergrund kann der Client versuchen, sich an einem normalen
DNS-Server zu registrieren, der die Änderungen dann wieder zum Read-only-DNS-Server repliziert.
Schreibgeschützte Domänen-Controller unterstützen auch Gesamtstrukturen, die noch
Windows-Server-2003-Domänen-Controller enthalten.

Ebenfalls neu: Unter Windows Server 2008 ist es möglich, den Systemdienst für das Active
Directory im laufenden Betrieb zu stoppen und wieder zu starten. Durch diese Funktion können
Systemverwalter das AD auf einem Server neu starten, während die anderen Dienste des Servers
weiterfunktionieren. Dies kann zum Beispiel für die Offline-Defragmentierung der AD-Datenbank
sinnvoll sein, oder für die Installation von Updates. Mit dem neuen "Active Directory Snapshot
Viewer", lassen sich versehentlich gelöschte Objekte der Domäne anzeigen. Anwender können mit
dieser Funktion zwar keine Objekte wiederherstellen, erkennen aber gelöschte Objekte. Dazu können
Systemverwalter mit "ntdsutil.exe" einen Snapshot des ADs erstellen.

Neuerungen bei den Gruppenrichtlinien

Windows Server 2008 unterstützt – als Neuerung bei den Gruppenrichtlinien – zum Beispiel die
Konfiguration der Energiesparoptionen für Windows Vista. Auch der Zugriff auf USB-Sticks lässt sich
bei Windows Server 2008 – in Kombination mit Windows Vista – konfigurieren. Beide Betriebssysteme
verwenden dabei so genannte Geräteidentifikations-Strings und Geräte-Setup-Klassen, um die
angeschlossene Hardware zu identifizieren.

Unter Windows XP und Windows Server 2003 gab es für unterschiedliche Sprachversionen des
Betriebssystems noch unterschiedliche Versionen von Vorlagendateien (*.adm-Dateien). Windows Server
2008 verwendet hingegen für seine neuen Vorlagendateien sprachneutrale *.admx-Dateien. Diese bauen
auf XML auf. Die *.admx-Dateien hinterlegt Windows nicht mehr für jede einzelne Gruppenrichtlinie,
sondern zentral im "Policy"-Ordner (C:WindowsPolicyDefinitions). Dies spart Bandbreite, da
Windows nur noch die Einstellungen in den Gruppenrichtlinien repliziert und nicht mehr alle
Vorlagendateien bei jeder Replikation. Unter Windows Server 2003 hat der Domänen-Controller in
allen Gruppenrichtlinienobjekten stets alle verwendeten *.adm-Dateien gespeichert, was zu einem
unnötigen Datenverkehr bei der Replikation und unnötigem Speicherplatzverbrauch führte. Zudem
hatten die *.adm-Dateien auch Schwierigkeiten beim Einsatz unterschiedlicher Windows-Versionen im
Netzwerk.

Die Gruppenrichtlinien-Tools – der Gruppenrichtlinienobjekteditor und die
Gruppenrichtlinienverwaltungskonsole (GPMC) – sind im Vergleich zu Windows Server 2003
weitestgehend unverändert. Der Gruppenrichtlinienobjekteditor liest jetzt automatisch alle unter
C:WindowsPolicyDefinitions gespeicherten *.admx-Dateien, ein Import wie bei Windows Server 2003
ist nicht mehr notwendig. Im Verzeichnis der Gruppenrichtlinienvorlagen speichert Windows auch die
installierten Sprachversionen. Für jede installierte Sprache ist ein eigener Ordner vorhanden. In
diesem liegen spezielle *.adml-Dateien, die an die entsprechende Sprache angepasst sind. Die neuen
Richtlinieneinstellungen für Windows Server 2008 lassen sich nur über Computer mit Windows Server
2008 oder Windows Vista und deren Gruppenrichtlinienobjekteditor oder die
Gruppenrichtlinienverwaltungskonsole bearbeiten. Zur Migration bisheriger ADM-Vorlagen aber auch
für das Erstellen neuer Vorlagen existiert ein Snap-in für die Managementkonsole: der "ADMX
Migrator". Das Tool ist über das Download-Center von Microsoft zur Verfügung. Es kann bestehende
*.adm-Dateien in *.admx umwandeln oder neue ADMX-Vorlagen erstellen.

Kompatibilität mit Windows 2000/2003/XP und Core-Servern

Computer mit Windows Server 2008 können Mitglied einer Windows-2000– oder einer
Windows-Server-2003-Domäne sein. Aber auch Computer mit Windows 2000 Server und Windows Server 2003
können Mitglied einer Windows-Server-2008-Domäne werden. Windows-Server-2003-Domänen-Controller
lassen sich auf Windows Server 2008 aktualisieren. Windows-XP- und
Windows-2000-Professional-Arbeitsstationen können problemlos Mitglied einer Domäne mit Windows
Server 2008 sein. Windows Server 2008 kann auch als Domänen-Controller in einer Windows-2000– oder
Windows-Server-2003-Domäne dienen. Die neuen Funktionen von Windows Server 2008 lassen sich
meistens aber erst dann nutzen, wenn alle Domänen-Controller auf Windows Server 2008 umgestellt
sind. Core-Server können ebenfalls als Domänen-Controller fungieren. Wollen Systemverwalter auf
einem Core-Server ein Active Directory installieren, dann läuft die Installation über eine
Antwortdatei ab.

AD-Komponenten im Überblick

Microsoft hat bei Windows Server 2008 auch die Bezeichnung der Komponenten angepasst, die das
System zur Identitätsverwaltung verwendet. Alle diese Funktionen und Serverrollen, erhalten vor der
eigentlichen Bezeichnung noch das Präfix "Active Directory". So ist schnell ersichtlich, welche der
Dienste direkt auf AD aufbauen, oder mit AD einen erweiterten Funktionsumfang erhalten: Die
AD-Zertifikatdienste (Active Directory Certificate Services, ADCS) stellen die neue Version der
Zertifikatsdienste unter Windows Server 2003 dar. AD-Domänendienste (Active Directory Domain
Services, ADDS) sind die Serverrolle, mit der Systemverwalter einen Server zum Domänen-Controller
heraufstufen. Die AD-Verbunddienste (Active Directory Federation Services, ADFS) wiederum bieten
eine webbasierende Single-Sign-on-(SSO-)Infrastruktur. Mit den AD-Rechteverwaltungsdiensten (Active
Directory Rights Management Services, ADRMS) lassen sich Daten mit digitalen Signaturen versehen,
um sie vor unerwünschtem Zugriff zu sichern. Besitzer von Dateien können basierend auf
Benutzerinformationen exakt festlegen, wie andere Benutzer diese nutzen dürfen. Anwender können
Dokumente zum Beispiel als "nur lesen" konfigurieren.

Die AD-Lightweight-Verzeichnisdienste (Active Directory Lightweight Directory Services, ADLDS)
sind der Nachfolger des "Active Directory Application Mode? (ADAM). Vereinfacht ausgedrückt können
mit diesen Diensten Applikationen arbeiten, um Informationen in einer eigenen Verzeichnisinstanz zu
speichern. Diese Dienste benötigen keinen Domänen-Controller und kein Active Directory, sondern
lassen sich vollkommen unabhängig betreiben. Auf einem Server können mehrere Instanzen von ADLDS
parallel laufen. Bei den ADLDS handelt es sich gewissermaßen um ein "kleines" Active Directory. Mit
ADLDS lassen sich unter anderem spezielle Anforderungen von Applikationen an einen
Verzeichnisdienst abbilden. Ein Beispiel dafür wäre die Verwaltung eines Extranets und die damit
verbundene Identitätsverwaltung. Wollen Unternehmen X.500/LDAP-Verzeichnisdienste migrieren, bietet
ADLDS eine hervorragende Schnittstelle zum Verzeichnis des Unternehmens. Auch zur
Identitätsverwaltung in kleineren Niederlassungen oder in DMZs (Demilitarized Zones) können die
ADLDS wertvolle Dienste leisten. Sie verfügen dazu – wie ein normales Active Directory – über eine
eigene Benutzerverwaltung. Die ADLDS unterstützen aber auch lokale Benutzerkonten und Gruppen.

Zur Verwaltung der ADLDS stellt Microsoft eigene Tools zur Verfügung. Mit dem "ADSchemaAnalyzer"
lässt sich das Schema einer AD-Gesamtstruktur in eine ADLDS-Instanz übernehmen. Auch die Migration
des Schemas zwischen verschiedenen ADLDS-Instanzen oder anderen LDAP-kompatiblen
Verzeichnisdiensten zu einer ADLDS-Instanz ist realisierbar. Der "Active Directory to ADLDS
Synchronizer" kann Daten aus einem AD in eine ADLDS-Instanz importieren, was für Testumgebungen
oder die Verteilung von Anwendung sehr hilfreich sein kann. Der "Snapshot Browser" wiederum
ermöglicht eine lesende Ansicht einer ADLDS-Datenbank. ADLDS-Instanzen können Daten über so
genannte "Configuration Sets" replizieren, die eine Gruppe von verschiedenen ADLDS-Instanzen
zusammenfassen. Die Replikation zwischen den Instanzen ist vollkommen unabhängig von der
Replikation im Active Directory.

Single-Sign-on-Szenarien mit ADFS

Die Hauptaufgabe der Active Directory Federation Services (ADFS) besteht darin, Anwendern mit
einer einzigen Anmeldung während einer Onlinesitzung Zugriff auf mehrere Webapplikationen zu bieten
(Single Sign-on). Damit können Unternehmen zum Beispiel Anwendern im internen Netzwerk Zugriff auf
webbasierende Anwendungen in der DMZ gestatten. Dabei ist es unerheblich, ob der Zugriff von intern
oder aus dem Internet stattfindet. Auch die Verbindung von zwei Gesamtstrukturen über einen "
Federation Trust" ist möglich. In diesem Fall können Anwender der einen Gesamtstruktur auf
webbasierende Anwendungen der anderen Gesamtstruktur zugreifen, was vor allem beim Zugang via
Internet eine erhebliche Erleichterung darstellt. So können auf einem Federation-Server die
Gesamtstrukturen und Konten hinterlegt sein, die Zugriff auf ein Extranet haben sollen. Greift ein
Anwender zu, kann der Federation-Server dies genehmigen. Einmal authentifiziert darf der Anwender
alle webbasierenden Anwendungen nutzen, für die er berechtigt ist, ohne sich erneut
authentifizieren zu müssen. Aber auch die Authentifizierung von externen Anwendern, ohne Konto in
einem AD, ist möglich, um eine Single-Sign-on-Infrastruktur aufzubauen.

Active Directory Rights Management Services

Mit den ADRMS lassen sich – wie erwähnt – Dateien über digitale Signaturen schützen. Die
internen Anwender im Unternehmen können auf diesem Weg zum Beispiel spezielle Benutzerrechte für
einzelne Dokumente vergeben. Um solche Dateien zur Verfügung zu stellen, existieren zwei
Möglichkeiten: Die Online- und die Offline-Veröffentlichung. Bei der ersten Verwendung von ADRMS,
erhalten interne Anwender automatisch ein "Rights Account Certificate" (RAC) und ein "Client
Licensor Certificate" (CLC) ausgestellt. Anschließend können Anwender mit kompatiblen Applikationen
Dateien erstellen und Benutzerrechte vergeben. Die Domänen-Controller im AD kennen dazu Standort
und Servernamen der ADRMS-Server. Die Applikation erstellt anschließend einen speziellen
Inhaltsschlüssel, mit dem die ADRMS den Inhalt der Datei verschlüsseln. Der Anwender kann diese
Datei danach veröffentlichen.

Die Daten des ADRMS-Servers – zum Beispiel die Zertifikate, die Schlüsselpaare und Ähnliches –
speichert der Server in einer sicheren SQL-Server-Datenbank. In kleinen Umgebungen, darf der
SQL-Server auch auf dem ADRMS-Server installiert sein. In größeren Infrastrukturen, die stark auf
ADRMS setzen, sollten SQL- und ADRMS- Server getrennt sein. Der Empfänger öffnet ein Dokument über
seinen Webbrowser, idealerweise den Internet Explorer oder eine ADRMS-kompatible Anwendung. Ist auf
dem Client kein Zertifikat vorhanden, fordert der Client vom ADRMS-Server eines an. Die URL zum
ADRMS-Server ist in der Datei hinterlegt – dieser Server muss bei externem Zugriff über das
Internet erreichbar sein. Die Datei sendet eine Benutzungsanfrage zum Server, der die "Publishing
License" ausgestellt hat. Dieser stellt anschließend fest, ob der Empfänger berechtigt ist, die
Datei zu öffnen, und stellt für diesen eine Benutzerlizenz aus. Anschließend entschlüsselt sich der
Inhalt des Dokuments. Auf diesem Weg kann ausschließlich der festgelegte Empfänger auf die Datei
zugreifen.