12 KiB
AD
Mittwoch, 3. Januar 2018
08:54
Daraus ergibt sich folgende Faustregel:
-
Benutzer fasst man in globalen Gruppen zusammen.
-
Ressourcenberechtigungen weist man lokalen Gruppen zu.
-
Globale Gruppen werden Mitglied in lokalen Gruppen.
-
Globale Gruppen werden nicht über Domänengrenzen hinweg repliziert.
-
Domänenübergreifend funktionieren Universelle Gruppen
Universal Group Membership Caching
| Gruppenbereich | In dieser Gruppe können Mitglied werden | Verwendung |
|---|---|---|
| Lokal (in Domäne) |
|
|
| Global |
|
|
| Universal |
|
|
Das Schema ist übrigens für eine Active Directory-Gesamtstruktur einzigartig (d. h. überall gleich). Um dies sicherzustellen, werden Änderungen am Schema nur auf einem DC vorgenommen, und zwar auf demjenigen mit der Betriebsmasterrolle Schemamaster
-
Klassen sind Objekte wie Accounting, Computer und dergleichen mehr.
-
Mit Attributen wird eine Klasse genauer beschrieben, d. h., es werden Eigenschaften wie ein Name definiert
Arbeiten mit dem Schema-Manager
Wer noch intensiver mit dem Schema arbeiten möchte, benötigt das Schema Manager-Snap-In. Dieses taucht nicht standardmäßig in der Liste der Administrations-Snap-Ins auf, ist aber auf Windows Server 2008 ff. bereits vorhanden und muss lediglich registriert werden. Dazu öffnen Sie die Eingabeaufforderung, navigieren in das Verzeichnis c:\windows\system32 und geben folgenden Befehl ein:
regsvr32 schmmgmt.dll
Globaler Katalog :
Die Aufgabe bei der Planung ist nun, die beste Anzahl und Positionierung für globale Kataloge zu ermitteln:
-
Wenn ein Außenstandort keinen eigenen GC hat, werden die entsprechenden Anfragen über WAN-Strecken abgewickelt.
-
Da der GC natürlich über die notwendigen Daten verfügen muss, findet ein permanenter Replikationsverkehr zu diesem statt.
-
Globale Kataloge sollen/müssen redundant vorhanden sein. Der Ausfall des einzigen GCs führt zu schweren Einschränkungen der Funktion! Ein Exchange-System ist beispielsweise ohne Global Catalog nicht funktionsfähig!
-
Redundanz lässt sich einfach dadurch erreichen, dass mehrere globale Katalogserver vorhanden sind.
-
Es sollte nach Möglichkeit an jedem Standort ein globaler Katalogserver vorhanden sein.
-
Ist dies nicht möglich, kann zur Schonung der WAN-Verbindungen das Zwischenspeichern der universellen Gruppenmitgliedschaft (Universal Group Membership Caching) aktiviert werden. Dies wird,
-
im Konfigurationswerkzeug Active Directory-Standorte und -Dienste vorgenommen. Wählen Sie den entsprechenden Standort aus, und rufen Sie dessen NTDS Site Settings auf.
-
Falls nach bestimmten Attributen häufig gesucht wird, können diese in den globalen Katalog aufgenommen werden.
Es gibt zwei Anmerkungen zum Thema Bridgeheadserver und globaler Katalog:
-
Wenn es an einem Standort einen globalen Katalogserver gibt, sollte dieser einer der bevorzugten Bridgeheadserver sein.
-
Wenn ein Standort einen globalen Katalogserver hat, aber nicht mindestens einen Domänencontroller von jeder Domäne der Organisation enthält, dann muss mindestens ein Bridgeheadserver ein globaler Katalogserver sein.
FSMO :
Es gibt pro Domäne jeweils einen Domänencontroller für folgende Betriebsmasterrollen (FSMO = Flexible Single Master Operations):
-
PDC Emulator
-
RID Master
-
Infrastrukturmaster (DARF KEIN GC SEIN !!!!)
Pro Forest, also einmal je Active Directory-Gesamtstruktur, gibt es noch folgende Betriebsmasterrollen:
-
Domain Naming Master
-
Schemamaster
-
Wenn in einer Domäne sämtliche Domänencontroller auch Global Catalog Server sind, kann einer von ihnen Infrastrukturmaster werden. Das Problem mit verwaisten Einträgen existiert dann ohnehin nicht, da es diese auf einem Global Catalog Server nicht gibt.
-
Sind in einer Domäne nicht sämtliche DCs auch Global Catalog Server, muss der Infrastrukturmaster auf einem Non-GC-DC laufen.
-
Die beiden forest-weiten Betriebsmasterrollen sollten in der Forest Root Domain (also der ersten installierten Domäne) verbleiben.
-
Die beiden forest-weiten Betriebsmasterrollen sollten weiterhin auf einem Global Catalog Server liegen.
-
Alle drei domänenweiten Rollen sollten auf demselben Domänencontroller eingerichtet werden.
-
Wenn in einem Forest mehrere Domänen vorhanden sind, dürfen die domänenweiten Rollen nicht auf einem Global Catalog Server liegen, es sei denn, alle Domänencontroller dieser Domäne sind Global Catalog Server (siehe auch den vorherigen Abschnitt).
-
Der Domänencontroller mit den Betriebsmasterrollen sollte durchaus leistungsstärker als ein »normaler« DC sein. Quantitative Angaben müssen individuell durch Messen und Analyse gewonnen werden. Es ist an dieser Stelle unmöglich, wirklich verlässliche Aussagen zu Speicherausbau und Prozessorleistung zu treffen.
RODC
Ein solcher Domänencontroller verfügt nicht über eine beschreibbare Datenbankkopie, und -- was noch wichtiger ist -- er verfügt auch nicht über die Passwörter der Benutzer
Ein RODC kann auch ein globaler Katalogserver sein
Ein RODC funktioniert wie folgt:
-
Wenn eine Anwendung nur lesenden Zugriff auf das Verzeichnis benötigt, kann der RODC-Domänencontroller alle gewünschten Informationen liefern.
-
Möchte eine Anwendung schreibend auf den RODC-Domänencontroller zugreifen, erhält sie eine LDAP-Weiterleitungsantwort und wird zu einem DC mit einer beschreibbaren Active Directory-Datenbank geleitet.
-
Wenn ein Benutzer sich authentifizieren möchte, sendet der RODC die Anfrage an einen beschreibbaren Domänencontroller, in dessen Datenbank auch die Passwortinformationen enthalten sind. Je nach Richtlinie zur Kennwortreplikation (Password Replication Policy) erhält der RODC eine Kopie der Anmeldeinformationen -- oder eben auch nicht.
Die Password Replication Policy auf einem RODC beschreibt, welche Anmeldeinformationen auf diesem Domänencontroller gespeichert werden dürfen. Die Informationen werden nicht durch Replikation übertragen, sondern werden gespeichert, wenn der Anwender sich zum ersten Mal über diesen DC authentifiziert hat. Ein guter Kompromiss aus Sicherheit und Performance ist folgende Vorgehensweise:
-
Die Speicherung der Kennwörter von den Benutzergruppen, die sich an dem Standort mit RODC-Domänencontroller befinden, wird zugelassen.
-
Die Speicherung der Kennwörter sämtlicher anderen Konten, inklusive der lebenswichtigen Konten von Administratoren und dergleichen, wird unterbunden.
Abbildung des Unternehmens
{width="0.15625in" height="0.15625in"}
Anmerkungen aus der Praxis
-
Die meisten mir persönlich bekannten mittelständischen Kunden (500 bis 10.000 PCs) benötigen nicht mehr als eine Domäne. Teilweise werden autark agierende Tochtergesellschaften in eigenen Domänen administriert, was dann aber »nur« ein Tribut an deren Eigenständigkeit ist.
-
Häufig wird gern eine leere Root-Domäne angelegt. Die Idee ist, dass eventuell hinzukommende Tochtergesellschaften in einen separaten Tree unterhalb der Root-Domäne migriert werden können. Dies hat zwar keine technischen Vorteile, bringt aber eine gewisse »Ordnung« in den Namensraum.
-
Es müssen nicht an jedem Standort zwingend Domänencontroller vorhanden sein. Wenn nur wenige Mitarbeiter an dem Standort arbeiten, kann der Zugriff auf die Domänencontroller im Allgemeinen problemlos über WAN-Verbindungen realisiert werden. Insbesondere »voluminöse« Login-Skripts, die zig Komponenten laden, müssen aber gegebenenfalls entrümpelt werden.
Replikation
Namenskontext = Partition
-
Jeder Domänencontroller verfügt über einen Namenskontext mit den Daten »seiner« Domäne. Dieser Namenskontext ist in vielen Werkzeugen unter der Bezeichnung Default Naming Context zu finden. Jeder DC speichert nur einen Domänennamenskontext, also niemals den einer fremden Domäne. Dementsprechend wird er nur innerhalb der Domäne repliziert.
-
Weiterhin gibt es zwei organisationsweite Namenskontexte, die über den gesamten Forest repliziert werden. Dies sind der Configuration-Namenskontext und der Schema-Namenskontext.
repadmin /showutdvec alphadc3.alpha.intra dc=alpha,dc=intra