Entwerfen einer Active Directory Struktur


 

Stichpunkte zur Entscheidungsfindung:

- Unternehmensanforderungen

- Analyse des Verwaltungsmodell

- Einplanung von Wachstum, Reorganisation (Zyklus: 2-5 Jahre)

- Dokumentation

- Eckpfeiler, Kompromisse, Auswirkungen, Risiken, Alternativen, [Kosten]

- Beginn mit einfachem Entwurf, Teste den Entwurf (Praxis), Roll-Back-Strategie

 

Der Entwurf sollte folgende Elemente berücksichtigen:

- DNS Strategie (Benennungsstrategie)

- Verwaltungsdelegation

- Schemaänderungen

- Gruppenrichtlinien

- (Inner-) Domänenstruktur

- Gesamtstruktur

- Standorttopologie

Wobei als letztliches Ziel immer die Unternehmensanforderungen gelten.

 

DNS Strategie (Benennungsstrategie):

Entscheidungskriterien:

- Internetpräsenz (ja/nein, evt. Registrierung bei ICANN, intern/extern gleicher Name?)

- Reichweite (Firma, Tochterunternehmen, Übernahmen, Fusion, Joint-Venture)

DNS und ADS:

- DNS stellt für ADS den Namensraum bereit (AD verwendet DNS Namensraum, DNS stellt Service Einträge bereit, Namensauflösung)

- ADS benötigt DNS

- AD kann mit DNS BIND (Berkley Internet Name Domain) Servern (z.B. UNIX) zusammenarbeiten

- Beachten: - BIND 8.2.1 aufwärts empfohlen

o
Feature W2K 8.2.1 4.9.7

o
SRV-Einträge x x x

o
Dyn. Akt. x x -

o
„Nur gesichert“ x - -

o
IXFR x x -

o
UTF 8 Zeichen x - -

o
Neg. Caching x x -

DNS Benennungsstrategie:

- eindeutigen, aussagekräftigen, erweiterbaren, unveränderlichen Namen für die ADS Stammdomäne verwenden (z.B. übergeordneter Firmenname)

- Registrierung im Internet (ICANN)

- Umbenennung der ADS Stammdomäne nicht möglich

- Einhalten der DNS Standardnamenskonvention

- evt. vorhandenen DNS Namensraum weiterverwenden

Implementierungsstrategien:

- Internet DNS Zone (extern) ist durch Firewall von einer delegierten DNS Zone (intern) getrennt. ADS Stammdomäne verwendet interne DNS Zone.

o
Durchgehender Namensraum

o
Längere Namen

o
DNS Server für delegierte Zone nötig

o
Externer DNS Server (falls bereits vorhanden) muss nicht aktualisiert werden

o
AD Daten von öffentlich zugänglichen Daten getrennt

- Internet DNS Zone (extern) ist durch Firewall von einer gleichnamigen DNS Zone (intern) getrennt. ADS Stammdomäne verwendet interne DNS Zone.

o
Benutzer verwenden nur einen Namen

o
Nur ein registrierter Name

o
Firewallkonfiguration ist komplexer

o
Synchronisierung

o
Mehr Verwaltungsaufwand

- Internet DNS Zone (extern) ist durch Firewall von einer andersnamigen DNS Zone (intern) getrennt. ADS Stammdomäne verwendet interne DNS Zone.

o
Mehr Sicherheit

o
Strikte Trennung öffentlicher und interner Ressourcen

o
Vorhandene DNS Infrastruktur (Server, Zonen) kann weiter verwendet werden.

o
In interner Zone evt. Aktualisierung des DNS Servers nötig

o
Verwirrung der Benutzer möglich

 

Verwaltungsdelegierung:

[auf der Ebene von (Standorten), Domänen, Organisationseinheiten (bevorzugt)]

Delegierung ist möglich auf:

- Container (empf.)

- bestimmte Objekttypen (innerhalb eines Containers) (empf.)

- Eigenschaften eines Objektes (vermeiden)

- Attribute eines Objektes (vermeiden)

à
Objektverwaltungsassistent auf OU Ebene

Rechte über Gruppenmitgliedschaften (MS-Gruppenstrategie, vordefinierte 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:

o
Leicht Erweiter- bzw. Veränderbar

o
Kann die physische Struktur des Netzes darstellen (WAN-Replikation!)

o
Evt. Probleme bei der Sicherheitskonfiguration (keine Differenzierung)

- Organisationsbasiert

o
Leicht Erweiterbar

o
Änderungen können Modifikationen erfordern

o
Kann die Geschäftsstruktur abbilden

o
Leichte Sicherheitskonfiguration

o
Keine Berücksichtigung der physischen Struktur

- Funktionsbasiert

o
Leicht Erweiter- bzw. Veränderbar

o
Leichte Sicherheitskonfiguration

o
Keine Berücksichtigung der physischen Struktur

o
Evt. tiefere OU Verschachtelung => komplex bei größeren Unternehmen

- Erst Standort, dann Organisation

o
Kann die physische Struktur des Netzes darstellen (WAN-Replikation!)

o
Leichte Sicherheitskonfiguration

o
Leicht Erweiterbar

o
Bei Änderungen der Firmenstruktur können Änderungen der unteren OU Ebenen erforderlich werden

- Erst Organisation, dann Standort

o
Leichte Sicherheitskonfiguration

o
Keine Berücksichtigung der physischen Struktur

o
Standortbasierte Verwaltung

 

Planen von Schemaänderungen:

Gründe für Schemaänderungen:

- Unternehmensanforderung erzwingt neue Objektklasse oder eine vorhandene Objektklasse weitere Attribute

- Installation einer verzeichnisfähigen Anwendung, die eine Schemaänderung erfordert (z.B. Exchange 2000)

Durchführung von Schemaänderungen:

- manuell: AD-Schema Snap-In

- automatisch: per Skript

- Installation einer verzeichnisfähigen Anwendung (evt. Aufteilung in 2 Phasen:

a) Schemaänderung, b) Installation der Software)

 

Auswirkungen von Schemaänderungen:

- ungültige Objekte (z.B. falls ein Objekt ein nicht für seine Klasse

definiertes Attribut enthält)

- Replikationsverzögerungen (Objekt wird vor Schema repliziert)

- Netzwerkverkehr (z.B. weiteres Attribut für globalen Katalog

=> vollständige Neuerstellung)

 

=> die Möglichkeit für Schemaänderungen sollte eingeschränkt werden!

=> da nur Schema Admins diese Änderungen durchführen dürfen,

sollte die Mitgliedschaft überwacht/eingeschränkt werden.

Infos zum Schema:

- Objektklassen Attribute (Attributwerte)

- Objektklassen setzen sich aus Attributen zusammen (verbindlich, optional)

- Objektklassen und Attribute werden nicht gelöscht sondern deaktiviert

- Standardschemaobjekte können nicht deaktiviert werden

 

Gruppenrichtlinienstrategie:

Einsatz:

- durchsetzen von Sicherheitseinstellungen

- vereinheitlichen und optimieren (vorkonfigurieren) der Arbeitsumgebung von Benutzern und Rechnern (Software, Destop, Einschränkungen, usw.)

Verknüpfungsebenen:

- lokal

- Standort (Org. Admin, da evt. Domänenübergreifend)

- Domäne (Vererbung nicht Domänenübergreifend)

- OUs

à
Kennwortrichtlinien können nur auf Domänenebene (sinnvoll) zugewiesen werden.

Techniken:

- Verknüpfen (zwischen Domänen vermeiden)

- Vererbung

- blockieren der Vererbung (vermeiden)

- Kein Vorrang (minimieren (1x))

- filtern mit Gruppen (vemeiden - besser zusätzliche OUs erstellen)

- deaktivieren (empf. für ungenutzte Teile (Benutzer/Computer))

- Anzahl der GPOs einschränken

 

 

 

 

 

 

 

 

 

GPO Delegierung:

- erstellen

o
Grenze: Domäne

o
GPO Ersteller/Besitzer

o
Dom Admins

- bearbeiten bestimmter GPOs

o
Grenze: GPO

o
Recht: +schreiben

- verknüpfen:

o
Grenze: OU, Domäne

o
Rechte: gpoption, gplink oder Objektverwaltungsassistent

Spezielle GPO Einstellungen zur Optimierung:

- Loopbackmodus

- Langsame Verbindungen

o
Keine Auswirkung auf Sicherheitseinstellungen, adm. Vorlagen

o
Kann konfiguriert werden für z.B.

à
Softwareinst.

à
Offline Ordner Synchronisation

à
Ordnerumleitung

- GPO Aktualisierungsintervalle

- Abarbeitung: sychron/asynchron

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

o
möglichst nur Gruppen als Mitglieder

o
statische Mitgliedschaften

 

Aufbau der OU-Struktur:

- nicht zu tief verschachteln

- obere OU Ebenen sollte statisch gewählt werden

- wiedergabe der IT Verwaltungsstruktur

o
ermöglicht Delegierung von Aufgaben

o
insbesondere in den oberen Ebenen

- einrichten von Gruppenrichtlinien

o
typischerweise in den unteren Ebenen

- erweiterbar gestalten

 

 

Planen von Gesamtstrukturen:

Gründe für die Verwendung einer Einzeldomäne:

- einfache Verwaltung

- einfachere Rechtedelegierung (OU)

- hohe Objektanzahl möglich (im Gegensatz zu NT4)

 

Gründe für die Verwendung mehrerer Domänen:

- Unterschiedliche Richtlinien auf Domänenebene (Kennwortrichtlinie)

- Sicherheit (strenge Verwaltungstrennung (Adminbasis), Sicherheitsbarrieren )

- Dezentralisierte Verwaltung

- Reduzierte Replikation (Domänenpartition wird nur innerhalb der Dom. repliziert)

- [Verwendung/Verwaltung von Vertrauensstellungen möglich (in getrennten GS)]

- [rechtliche Gründe (z.B. Überwachungsrichtline)]

Spezialfall leere Stammdomäne:

- Nur das Standard-Adminkonto existiert in dieser Domäne (einziges Konto mit Org. und Schema Admin Rechten), Zugriff auf Konto stark eingeschränkt.

- Getrennte (isolierte) Verwaltung aber gemeinsamer Namensraum

- Nach Update einer NT4 Domänenstruktur

Gründe für die Verwendung mehrerer Strukturen:

- getrennte Namensräume (z.B. mehrere bekannte Firmennamen, die zu erhalten sind)

o
bei gleichzeitiger vollständiger Zusammenarbeit und zentraler Verwaltung (sonst 2 getrennte GS)

Gründe für die Verwendung mehrerer Gesamtstrukturen:

- komplette Zugriffstrennung bzw. Steuerung der Zugriffsrichtung mit Vertrauensstellungen

- kein gemeinsamer globaler Katalog (kein gemeinsames Verzeichnis)

- unterschiedliche Schemata benötigt (z.B. für verzeichnisfähige Anwendungen)

Vertrauensstellungen und Kerberos:

 

Innerhalb einer GS:

- implizit

- gegenseitig

- transitiv

- à zwischen über/untergeordneten Dom. und den obersten Domänen der Strukturen

Innerhalb einer GS:

- explizit

- einseitig

- transitiv

- à ShortCut bzw. verknüpfende Vertrauensstellung (zum verkürzen des Kerberos-Authentifizierungspfades)

Zwischen GS, GS und NT4:

- explizit

- einseitig

- nicht transitiv

- à Ressourcenzugriff ist möglich entgegen der Vertrauensstellung (Richtung !)

 

 

Kerberos:

- Authentifizierungsprotokoll für W2K Domänen

- basiert auf Tickets, Schlüsselverteilungscentern (DC)

- die Transitivität von Vertrauensstellungen basiert auf dem Kerberos-Authentifizierungspfad

 

NT4 Domänenmodelle:

- Einzeldomäne

o
Zentrale Verwaltung

o
Bis zu ~40.000 Objekte

- Hauptdomänenmodell

o
Getrennte Benutzer / Ressourcenverwaltung

- Mehrfachhauptdomänenmodell

o
Zentrale Benutzerverwaltung

o
Dezentrale Ressourcenverwaltung

o
40.000 Objekte pro Domäne

- vollständiges Vertrauen

o
zentrale Verwaltung

o
40.000 Objekte pro Domäne

 

Konsolidieren: zusammenführen von Domänen (vereinfachen des Domänenmodells)

 

Standortplanung:

Standorte werden eingerichtet um:

- die Replikation zu steuern (optimieren à Netzverkehr)

- Zugriffoptimierung für Clients

o
Anmeldung am Standort-DC (bevorzugt)

o
DFS gibt bevorzugt Pfade innerhalb des Standorts zurück

o
NTFRS (repliziert u.a. das SYSVOL)

- [sollte durch DNS pro Standort ergänzt werden, damit Namen lokal aufgelöst werden]

 

 

 

 

 

 

 

 

 

 

 

Einrichten von Standorten:

- wenn eine langsame, unzuverlässige und/oder nicht permanente Verbindung vorliegt

- langsam ~ Grenze des LANs à unter 10 Mbit/s , „verfügbare Bandbreite“

- Abwägung: Anmeldeverkehr/AD-Zugriffe contra Replikationsverkehr

- Mind. ein DC pro Standort (ausser evt. Ministandort)

- DNS pro Standort (ausser evt. Ministandort)

- GC pro Standort (bei vielen Zugriffen: Multi-Domain, einheitlicher Modus, suchen)

o
Standard: nur auf erstem DC der GS

- Vorgehensweise der Einrichtung:

o
Subnet definieren

o
Neuen Standort erstellen

o
Mittels Standortverknüpfungsobjekt mit anderen Standort(en) verbinden

o
Subnet(s) dem Standort zuweisen

o
DC(s) in den Standort verschieben oder installieren

 

Replikation:

- Standortintern:

o
Unkomprimiert

o
Nur über RPC (Repl.partner benötigen direkte Kommunikation)

o
Benachrichtigungsprinzip (5min. Verzögerung an Repl.partner)

o
Kreistopologie + Querverbindungen (max. 3 Hops bzw. 15min. bis zur Konvergenz) von KCC automatisch generiert

- Standortübergreifend:

o
Komprimiert (falls Änderungdaten größer 50KB)

o
RPC möglich

à
Weniger Overhead als SMTP, aber zuverlässige Verbindung nötig

(~>128KB)

o
SMTP möglich

à
Asynchron (Zielrechner muss nicht permanent verfügbar sein)

à
Zertifikate für Sicherheit

à
Keine Replikation der Domänenpartition möglich

o
kein Benachrichtigungsprinzip

à
Zeitsteuerung und Planung (Intervall, Zeitplan) ; Einstellung über Standortverknüpfungsobjekte

o
Topologie: Bridgeheadserver (ISTG)

o
Standortverknüpfungsobjekt:

à
Zeitplan (ausserhalb von Hochlast/Geschäftszeiten)

à
Intervall (min. 15 min, Komprimierung)

à
Kosten (Prioritäten festlegen)(Fehlertoleranz)

·
Schnelle, günstige Verbindung: kleiner Wert

·
Langsame, teure Verbindung: größerer Wert

à
Verbundene Standorte (2 oder mehr)

Betriebsmaster:

- Schema 1x pro GS empf. Schema +Domänennamen auf einem DC

- Domänennamen 1x pro GS empf. Schema +Domänennamen auf einem DC

- RID 1x pro Dom.

- PDC-Emulator 1x pro Dom Position: meiste Benutzer (NT4/W2K)

- Infrastuktur 1x pro Dom nicht auf GC, aber am gleichen Standort wie GC

Standard: Auf dem ersten DC der jeweiligen Instanz