Entwerfen einer Verzeichnisdienstinfrastruktur
Entscheidungsfindung:
Als erstes bestimmt man die Ziele einer Organisation, damit man
das Verwaltungsmodell analysieren kann. Ebenfalls muss ein evtl. Neu- oder
Zukauf von weiteren Firmen oder das Wachstum innerhalb des Unternehmens bedacht
werden. Diese Informationen sollten dokumentiert werden. Am Besten erstellt man
einen Ist-Soll-Vergleich.
Unter den Entwurfsoptionen zählen Punkte wie die Auswirkungen
(Kosten, Zeit, Manpower), die Risiken, die entstehen können und deren
Alternativpläne (Rollbackstrategie) sowie eingehbare Kompromisse. Desweiteren
ist natürlich eine gewisse Grundstruktur, sogenannte Eckpfeiler, einzuplanen,
ohne die das AD-Konzept nicht wünschenswert funktioniert.
Das Verwaltungskonzept ist ein nicht unerheblicher Faktor in der
Planung. Dazu muss man die vorhandene Verwaltung analysieren.
Man sollte als Richtlinien die Unternehmensanforderungen
berücksichtigen, einen klaren Überblick behalten und fundierte Entscheidungen
bei Kompromissen treffen. Dann kann man einen einfachen Entwurf erstellen und
diesen möglichst testen. Hier ist ebenfalls eine Rollbackstrategie
unverzichtbar.
Architektonische Elemente von Active Directory sind:
-
die Benennungsstrategie (DNS)
-
Delegierung von Verwaltungszuständigkeiten
-
Berücksichtigen von Schemaänderungen (Planung,
Vorbereitung)
-
Gruppenrichtlinien (Benutzerumgebung, Software,
Strukturierung der OU's und Domänen für die GPO's, Sicherheit)
-
AD-Domäne entwerfen
-
GS entwerfen
-
Planung der Standorte
Als hauptsächliches Ziel gelten natürlich die
Unternehmensanforderungen.
DNS-Strategie (Benennungsstrategie)
Die Entscheidungskriterien beziehen sich auf:
-
Internetpräsenz (ja/nein; evtl. Registrierung bei der ICANN
notwendig; interner Name gleich dem externen)
-
Reichweite (Firma, Tochterunternehmen, Übernahmen,
Fusionen, Joint-Venture)
DNS und ADS:
-
DNS stellt für ADS den Namensraum bereit (AD verwendet
DNS-Namensraum, DNS stellt Serviceeinträge bereit, Namensauflösung)
-
ADS benötigt DNS
-
AD kann mit DNS-BIND (Berkeley Internet Name Domain / ab
Version 8.2.1)-Servern zusammenarbeiten (z.B UNIX)
| Feature |
W2k |
8.2.1 |
4.9.7 |
| SRV-Einträge |
ja |
ja |
ja |
| dyn. Aktualisierung |
ja |
ja |
nein |
| "Nur gesicherte Übertragung" |
ja |
nein |
nein |
| IXFR (inkr. Zonentrans.) |
ja |
ja |
nein |
| UTF-8 ZeichenCodierung |
ja |
nein |
nein |
| negative Caching |
ja |
ja |
nein |
DNS-Benennungsstrategie:
- eindeutigen, aussagekräftigen, unveränderlichen und erweiterbaren Namen
für die AD-Stammdomäne verwenden
- Registrierung im Internet (ICANN)
- Umbenennung der ADS-Stammdomäne nicht möglich
- einhalten der DNS-Standardnamenskonventionen (nicht UTF-8!)
- evtl. vorhandenen DNS-Namen benutzen
Implementierungsstrategien:
1. eine Internet-DNS-Zone (test.de), der eine weitere Unterdomäne
hinzugefügt wird (AD.test.de). Dazwischen eine Firewall. Die Unterdomäne ist
delegiert und enthält Active Directory.
- Durchgehender Namensraum
- Längere Domänennamen
- DNS-Server für delegierte Zone nötig
- externer DNS-Server benötigt keine Aktualisierung
- AD-Daten sind getrennt von den öffentlich-zugänglichen Daten
2. Eine Domäne (test.de), die mit einer externen und einer internen Zone
ausgestattet ist. Dazwischen eine Firewall. Die interne Zone ist mit Active
Directory ausgestattet.
- Benutzer verwenden nur einen Namen
- nur ein registrierter Name notwendig
- Firewallkonfiguration ist komplexer
- Synchronisierung
- höherer Verwaltungsaufwand
3. Eine Internet-DNS-Zone, die einen völlig anderen Namen als die
Intranet-DNS-Zone besitzt. Dazwischen befindet sich eine Firewall. Die interne
DNS-Zone ist mit Active Directory ausgestattet.
- höhere Sicherheit durch
- strikte Trennung der Ressourcen
- vorhandene DNS-Infrastruktur (Server, Zonen) kann weiterverwendet werden
- Verwirrung der Benutzer möglich
Übung: "Firma.de"
Anforderungen:
- geringer Verwaltungsaufwand
- Trennung von priv. / öffentlichen Ressourcen
- DNS-Name beibehalten (u.a. zur Identifikation)
- Mitarbeiter sollen auf Internetserver der Firma zugreifen können
Bei dieser Übung würde man das erste Beispiel ansetzen.
Übung2:
Anforderungen:
Bei dieser Übung würde man das dritte Beispiel ansetzen.
Übung3:
Ist:
-
Website vorhanden
-
BIND 4.1.1
Anforderungen:
-
Weiterverwendung der BIND-Server, Aktualisierung erlaubt
-
interne von externen Ressourcen trennen
-
Mitarbeiter sollen die Internetserver der Firma erreichen
-
keine Registrierung eines weiteren DNS-Namens
-
interner Name = externer Name
Verwaltungsdelegierung:
-
auf Ebene von Standorten, Domänen, OU's (bevorzugt)
-
Delegierung ist möglich auf
-
Container (empf.)
-
bestimmte Objekttypen (innerhalb eines Container)(empf.)
-
Eigenschaften eines Objekts (verm.)
-
Attribute eines Objekts (verm.)
-
=> Objektverwaltungsassistent auf OU-Ebene
-
Rechte über Gruppenmitgliedschaften (MS-Gruppenstrategie, vordef.
Gruppen)
-
Nicht mehr Rechte als nötig vergeben
Verwaltungmodelle:
- zentrale IT-Organisation (eine Person oder Gruppe ist für das gesamte
Unternehmen zuständig)
- zentrale IT-Organisation mit dezentralisierter Verwaltung (eine Person
oder Gruppe ist für die Unternehmensplanung zuständig, aber
alltägliche Aufgaben werden delegiert)
- dezentralisierte IT-Organisation (unabhängig arbeitende
Personen/Gruppen, die für übergreifende Aufgaben temporär
zusammenarbeiten)
- ausgelagerte IT-Organisation (Teile oder der gesamte IT Bereich werden
von einer Fremdfirma verwaltet)
Hilfsaufgaben (z.B. Kennwörter zurücksetzen)
können in allen Modellen delegiert werden
Lösungsansätze:
-
Standortbasiert
- leicht erweiter- bzw. veränderbar
- kann die phys. Struktur des Netzes darstellen (WAN-Replikation!)
- evtl. Probleme bei der Sicherheitskonfiguration (keine Differenzierung)
- Organisationsbasiert
- leicht erweiterbar
- Änderungen können Modifikationen erfordern
- kann die Geschäftsstruktur abbilden
- leichte Sicherheitskonfiguration
- keine Berücksichtigung der physischen Struktur
- Funktionsbasiert
- leicht erweiter- bzw. veränderbar
- leichte Sicherheitskonfiguration
- keine Berücksichtigung der physischen Struktur
- evtl.
tiefere OU-Verschachtelung => komplex bei grösseren Unternehmen
- Erst Standort, dann Organisation
- kann die phys. Struktur des Netzes darstellen (WAN-Replikation!)
- leichte Sicherheitskonfiguration
- leicht
erweiterbar
- bei Änderungen der Firmenstruktur sind Änderungen
der unteren OU-Ebene möglich
- Erst Organisation, dann Standort
- leichte Sicherheitskonfiguration
- keine Berücksichtigung der physischen Struktur
- Standortbasierte
Verwaltung
Planung einer Domäne:
Namensfestlegung: (Stamm-Domänenname nicht änderbar, Weitergabe des Namens in der Struktur)
Gruppen:
Benutzer => Globale Gruppe => (universal Gruppe) => lokale Domänengruppe
<= Rechte
Universal Gruppe:
- nur einheitlicher Modus
- Replikationsverkehr zum globalen Katalog
- möglichst nur Gruppen als Mitglieder
- statische Mitgliedschaften
Aufbau der OU-Struktur:
- nicht zu tief verschachteln
- obere OU Ebenen sollte statisch gewählt werden
- Wiedergabe der IT Verwaltungsstruktur
- ermöglicht Delegierung von Aufgaben
- insbesondere in den oberen Ebenen
- Einrichten von Gruppenrichtlinien
- typischerweise in den unteren Ebenen
- erweiterbar gestalten