Mit dem Server Performance Advisor (SPA) kann man Performanceprobleme, die unter anderem ein DNS-Server oder IIS hat, aufspüren.

Auch Probleme im Active Directory, z.B. bei einer Active Directory-Abfrage, können damit aufgedeckt werden.

Allerdings erwartet einem während der Installation des SPAs eine kleine Überraschung, die ich im folgenden Artikel beschreibe:

Server Performance Advisor (SPA) auf einem deutschen System

Standorte sind eine (neben Domänencontrollern) physikalische Komponente des Active Directorys. Durch das erstellen von Standorten kann:

1. die Replikation (Inter-Site) zwischen Domänencontrollern (DC) optimiert (standortübergreifend werden die Daten komprimiert) und
2. den Clients, der Zugriff auf Netzwerkressourcen die sich an deren physischen Standort befinden gewährleistet werden, ohne die WAN-Verbindung zu belasten.

Grundsätzlich gilt, durch das Festlegen von Standorten im Active Directory, beeinflusst man den Replikationsverkehr sowie welche Dienste von
den Clients im wesentlichen genutzt werden.
Z.B. wird ein lokaler Domänencontroller eher verwendet (Domänencontroller am Standort), als ein Domänencontroller an einem anderen Standort oder
eine lokale Replik eines DFS-Ordners wird anstelle einer Replik eines anderen Standortes bevorzugt. Weiterhin ist es möglich,
standortabhängig nach Druckern zu suchen.

Der Knowledge Consistency Checker (KCC) erstellt anhand der Standort-Informationen die optimale Replikationstopologie.
Nähere Informationen unter: Active Directory-Replikation

Was ist alles zu beachten und durchzuführen, wenn ein Domänencontroller an einen anderen bzw. neuen Standort verschoben werden soll?

1. Zuerst muss die WAN-Verbindung physikalisch eingerichtet werden. Dazu müssen die jeweiligen Router in ihren Standorten aufgestellt,
   eingestellt sowie das Routing konfiguriert werden.
   
   
2. Wie so oft, ist das DNS ein elementarer Dienst bei diesem Vorgang. Existieren alle Unterordner (_sites, _msdcs, _tcp, _udp) in der Forward Lookup Zone (FLZ)?
   Die interne DNS-Namensauflösung sollte ordnungsgemäß funktionieren und in den TCP/IP-Einstellungen sollte ein autoritativer DNS-Server
   eingetragen sein (Punkt 8 beachten). Die beiden Tools DCDIAG und NetDIAG, sind hilfreiche Werkzeuge um die Ausgangsbasis zu kontrollieren.
   REPADMIN und REPLMON helfen beim Aufdecken von Replikationsproblemen die sich in den Windows Support Tools befinden.
   
   
3. Im MMC Snap-In „Active Directory-Standorte und –Dienste“ muss zuerst ein Standortobjekt erstellt (mit einem Rechtsklick auf Sites) und eine
   Standortverknüpfung für diesen Standort ausgewählt werden. Beim Einrichten des ersten Domänencontrollers in der Gesamtstruktur wird ein
   Standortobjekt mit dem Namen Standardname-des-ersten-Standorts erstellt, sowie die Standortverknüpfung DEFAULTIPSITELINK,
   allerdings ohne ein Subnetzobjekt. Beide Objekte können jederzeit umbenannt werden.
   
   
4. Als nächstes sollte zu einem korrekten Design, das entsprechende Subnetzobjekt erstellt (mit einem Rechtklick auf Subnets) und dem
   Standort zugewiesen werden. Zum erstellen eines Subnetzobjekts werden die Informationen, Netzwerkadresse oder IP-Adressbereich sowie
   die Subnetzmaske benötigt. Ein Standort kann dabei mehrere Subnetze umfassen.
   
   
5. Im nächsten Schritt, gilt es eine Standortverknüpfung für die Inter-Site (standortübergreifende) Replikation zu erstellen.
   Dazu erweitert man Sites, danach Inter-Site-Transports, klickt mit rechts auf den Container IP und wählt Neue Standortverknüpfung.
   Danach vergibt man dieser Standortverknüpfung einen Namen und fügt zwei (oder mehr) Standorte in die Spalte Standorte in dieser Standortverknüpfung hinzu.
   Wobei jede Standortverknüpfung mindestens zwei Standorte enthalten muss. Idealerweise vergibt man Namen, die zeigen welche Standorte verknüpft sind.
   Als Beispiel für eine Verknüpfung zwischen Frankfurt und Berlin: FRA-BER.
   
   
6. In den Eigenschaften der Standortverknüpfung können der Zeitplan (standardmäßig jederzeit), das Intervall (standardmäßig alle 180 Minuten),
   die Kosten (standardmäßig 100) und das Replikationszeitfenster konfiguriert werden. Umso niedriger die Kosten sind, umso höher ist die Priorität.
   
   
7. Bevor der Domänencontroller an seinen neuen Standort verschoben wird, gilt es die IP-Informationen entsprechend dem Ziel-Ort anzupassen.
   Diese wären:
   
                            - IP-Adresse inklusive der Subnetzmaske
                            - Standardgateway
                            - DNS-Server Adresse
                            - WINS-Server Adresse
   
   Für Details siehe: Die IP - Adresse eines Domänencontrollers ändern
   
   
8. Ist auf dem Domänencontroller der DNS Dienst installiert und dieser zeigt in seinen TCP/IP-Einstellungen als Bevorzugter DNS-Server auf sich selbst,
   so sollte (übergangsweise) ein zentraler/anderer DNS-Server dort eingetragen werden (bzw. ein DC/DNS des „alten“ Standorts).
   Diesen Vorgang beschreibt Microsoft als Inseleffekt vermeiden
   Unter Windows Server 2003 kann als Alternativer DNS-Server der DC selbst mit seiner echten IP-Adresse dort eingetragen werden.
   Stattdessen wird unter Windows Server 2000 als „Bevorzugter DNS-Server“ ein zentraler DNS-Server und als „Alternativer DNS-Server“
   ein anderer DNS-Server empfohlen einzutragen DNS Server becomes an island when a domain controller points to itself for the _msdcs.ForestDnsName domain
   
   
9. Wenn von einer übergeordneten DNS-Zone eine Zonen Delegierung auf diesen DC/DNS-Server existiert,
   so gilt es die IP-Adresse für diese Delegierung zu aktualisieren.
   
   
10. Es sollte kontrolliert werden, ob dieser Domänencontroller ein bevorzugter Bridgeheadserver an seinem alten Standort ist.
    Im Kontextmenü (Rechtsklick) des Servers (im Snap-In "Active Directory-Standorte und -Dienste", unter Sites-seinem Standort-Servers) wählt man
    die Eigenschaften aus. Danach kann in der Spalte Server ist ein bevorzugter Bridgeheadserver für folgende Transporte: überprüft werden,
    ob dort der Eintrag IP existiert. Mit markieren von IP und anschließend durch klicken auf Entfernen, kann der Server so konfiguriert werden,
    dass er kein bevorzugter Bridgeheadserver ist. Welche Server in der Gesamtstruktur als Bridgeheadserver fungieren, kann mit ADSIEdit.msc aus den
    Windows Support Tools, auf einen Blick im Configuration Container eingesehen werden.
    Dort im Pfad CN=Configuration,DC=NamederRootDomäne,CN=Sites,CN=Inter-Site-Transports,
    gilt es mit einem Rechtsklick auf CN=IP die Eigenschaften auszuwählen. Danach mit einem Doppelklick auf bridgeheadServerListBL sieht man
    unter Values die Distinguished Names (DN) der jeweiligen Serverobjekte.
    
    
11. Zum Verschieben eines Serverobjekts in einen anderen Standort, navigiert man im Snap-In „Active Directory-Standorte und –Dienste“ unter Sites auf
    den Standort in dem sich das Serverobjekt befindet, erweitert Servers und klickt mit rechts auf den zu verschiebenden Server und wählt Verschieben…
    Im anschließend erscheinenden Dialogfeld wählt man den Zielstandort aus und bestätigt mit OK. Danach sollte der neue Standort ausgewählt und der
    Container Servers erweitert werden um zu kontrollieren, ob das Serverobjekt (sowie unterhalb dessen, dass NTDS Settings Objekt) vorhanden ist.
    Verschieben eines Domänencontrollers zwischen Standorten
    
    
12. Nach dem Verschieben, aktualisiert der Domänencontroller die SRV-Records im DNS entsprechend seiner neuen IP- sowie Standort-Informationen.
    Genauer gesagt, aktualisiert der Netlogon-Dienst die Einträge. Dieser Vorgang kann auch manuell vollzogen werden (net stop netlogon && net start netlogon).
    Falls sich der DC nicht mit seinen neuen Standort-Informationen im DNS einträgt, könnte es hilfreich sein, die Datei NETLOGON.DNS im Verzeichnis
    %windir%\system32\config zu überprüfen. Zur Kontrolle hilft ein Blick in die Ereignisanzeige auf dem verschobenen Domänencontroller.
    Dort sollte im Verzeichnisprotokoll nach kurzer Zeit, nicht der Netlogon-Fehler mit der Ereignis-ID 5774 erscheinen.
    SRV Records Cannot Be Registered on a DNS Server
    
    
13. Das DNS sollte zwingend bereinigt werden. Denn nach dem verschieben des DCs, bleiben die Einträge vom alten Standort weiterhin im DNS bestehen.
    Dazu sind die SRV-Records aus dem Pfad _tcp.<Name des Standorts>._sites.dc._msdcs.Domäne.TLD vom alten Standort zu entfernen.
    Ansonsten könnten sich die Clients weiterhin versuchen, an dem DC der an einen anderen Standort verschoben wurde, zu authentifizieren.
    Das Resultat wären langsame Anmeldevorgänge.
    

Nach einem Domänencontroller-Neustart läuft die Konsistenzprüfung (KCC) zum ersten Mal nach fünf, anschließend alle 15 Minuten.
Dieser erstellt und löscht nach Bedarf die Replikationsverbindungsobjekte um die Intra- (standortintern) sowie Inter-Site (standortübergreifend)
Replikationstopologie den neuen Anforderungen anzupassen. Daher ist es wichtig, im Snap-In „Active Directory-Standorte und –Dienste“
die Standortstruktur (sowie die Subnetze) vollständig zu konfigurieren (Zeitplan+Intervall+Kosten), damit der KCC mit den eingetragenen Informationen,
die ideale Replikationstopologie berechnen kann.

Das Intervall kann mit einem Eintrag in der Registry verändert werden. Standardmäßig existieren die folgenden beiden Schlüssel nicht.
Durch erstellen dieser Schlüssel, kann Einfluss auf das Verhalten des KCC genommen werden:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Repl topology update delay (secs)
Default: 300 Sekunden (5 Minuten)
Data type: REG_DWORD
Repl topology update delay (secs)

sowie im gleichen Pfad:

Repl topology update period (secs)
Default: 900 Sekunden (15 Minuten)
Data type: REG_DWORD
Repl topology update period (secs)

Zum Schluss sollten die Dienste DNS sowie WINS kontrolliert werden.
Sind die Einträge im DNS aktualisiert worden, vor allem in dem _sites Ordner unterhalb der FLZ bzw. in der _msdcs.<FLZ> Zone?
Stimmen die Einträge im WINS, falls nicht, sind diese Registrierungen per nbtstat –RR zu forcieren oder im Ausnahmefall manuell zu korrigieren.
Zeigen die anderen Domänencontroller in den anderen Standorten den verschobenen Domänencontroller in ihren eigenen MMC Snap-Ins
"Active Directory-Standorte und –Dienste" im neuen Standort an?

Mit REPLMON sowie REPADMIN kann die Replikation überprüft werden.
Die Replikationstopologie des verschobenen Domänencontrollers sollte ebenfalls überprüft werden. Dieses kann im Snap-In „Active Directory-Standorte und –Dienste“
mit einem Rechtsklick auf die NTDS-Settings des verschobenen DCs, dann nach Auswahl von Alle Aufgaben mit einem Klick
auf Replikationstopologie überprüfen geprüft werden.

Mit REPADMIN /SHOWREPL kann ebenfalls überprüft werden, ob sich der DC an seinem neuen Standort mit den anderen Domänencontrollern repliziert.

Weiterhin kann nach dem verschieben erneut mit DCDIAG sowie NetDIAG der Domänencontroller überprüft werden. Mit beiden Tools kann sichergestellt werden,
dass der Domänencontroller seine Dienste im Active Directory nun unter der aktuellen IP-Adresse anbietet sowie erreichbar ist.
Ein Blick in das Verzeichnisdienstprotokoll das in der Ereignisanzeige enthalten ist, wäre ebenfalls sinnvoll um sicherzugehen, dass keine etwaigen Probleme bestehen.

Falls auf dem verschobenen Domänencontroller der DHCP-Dienst installiert ist, so sollte die konfigurierte IP-Bereichsoption den aktuellen IP-Informationen des neuen
Standorts angepasst werden. Die korrekte DHCP Autorisierung im Active Directory sollte jetzt ebenfalls überprüft werden.

Weitere Informationen:
Einen Standort umbenennen
Gründe für das Einrichten eines Einzelstandortes oder separater Standorte
Replikation: Standorte & Standortverknüpfungsbrücken
Konfigurieren einer Replikation zwischen Standorten
Entwerfen der Standorttopologie
KCC and Topology Generation
Using Repadmin.exe to troubleshoot Active Directory replication

Das Authentifizierungsprotokoll das Microsoft seit Windows 2000 in einer Active Directory-Domäne einsetzt, heißt Kerberos in der Version 5  (RFC 1510 [1]).

Es wurde ursprünglich Ende der 70er Jahre entwickelt [2]. Microsoft Windows-Betriebssysteme vor Windows 2000 verwenden eine

der Lan Manager (LM) -Authentifizierungsmethoden, die keine Unterstützung für Kerberos bieten.

Jeder Benutzer der eine Authentifizierungsanforderung sendet, sowie der Server, der die angeforderte Authentifizierung bereitstellt,

wird vom Kerberos V5 Protokoll auf seine Identität überprüft. Diese beidseitige Überprüfung, wird auch als „gegenseitige Authentifizierung“ bezeichnet.  

Wenn ein Client auf einen Fileserver zugreifen möchte, sind an diesem Vorgang, der Client selbst, der Fileserver und schließlich der Kerberos-Server beteiligt.

Beim Kerberos V5 – Authentifizierungsverfahren werden Tickets verwendet, um den Zugriff auf die entsprechenden Netzwerkdienste zu gewährleisten.

Ein essentieller Dienst von Kerberos, stellt der KDC (Key Distribution Center, Schlüsselverteilungscenter) dar.

Dieser Dienst wird standardmäßig auf jedem Domänencontroller ausgeführt und speichert durchweg die Clientkennwörter sowie weitere Kontoinformationen.

Der Client stellt eine DNS-Abfrage [3] um den nächstgelegenen Domänencontroller ausfindig zu machen.
Daraufhin verwendet der Benutzer diesen Domänencontroller als den bevorzugten KDC.
Während der Benutzeranmeldung fordert der Client beim Kerberos-Server ein Ticket Granting Ticket (TGT) an.

Damit ist es dem Client möglich, ohne eine erneute Authentifizierung, dass eigentliche Sitzungsticket vom Ticket Granting Service (TGS) für

diverse Dienste (z.B. für den Fileserver etc.) anzufordern.

Darüber hinaus wird ein Sitzungs-Schlüssel zwischen dem Client und Kerberos-Server ausgehandelt,

der zum verschlüsseln des Datenverkehrs verwendet werden kann.

Kerberos V5-Authentifizierung

Die im Netzwerk übertragenen Kerberos-Nachrichten, werden sicher transportiert und mit einer Vielzahl von Verschlüsselungsschlüsseln verschlüsselt.

Dadurch wird sichergestellt, dass die Kerberos-Nachrichten von niemanden unerlaubt verändert werden. 

Ferner wird beim Einsatz von Kerberos nie das tatsächliche Kennwort übertragen, sondern nur ein Hash.

Das bedeutet aber nicht, dass z.B. ein weniger sicheres Kennwort für die Benutzeranmeldung gewählt werden darf.

Angenommen Schlüssel werden von Kennwörtern abgeleitet, dann sollten diese so komplex und lang gewählt werden,

dass ein Brute-Force- oder Wörterbuch-Angriff scheitern würde.

Als weiteren Schutz bietet Kerberos, den Einsatz von Zeitstempeln (Timestamps). Damit wird die Echtheitsbestätigung sichergestellt.

Clients ab Windows 2000 synchronisieren ihre Systemuhr über eine spezielle Form des Network Time Protocol – NTP (genannt NT5DS),

mit ihrem authentifizierenden Domänencontroller. Daher darf die Zeit an den Systemen, standardmäßig nicht mehr als fünf Minuten abweichen,

ansonsten verlieren Kerberostickets ihre Gültigkeit.

Answers to frequently asked Kerberos questions

http://support.microsoft.com/kb/266080/en-us

Falls einem der Zugriff auf einen Server verwehrt bleibt, so kann man mit den beiden Tools „Kerberos Tray (Kerbtray.exe)“ und

„Kerberos List (Klist.exe)“ die sich im Windows Server 2003 Ressource Kit befinden, prüfen, ob ein entsprechendes Sitzungsticket für diesen Server besteht.

Windows Server 2003 Resource Kit Tools

http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en

Weitere Ansätze für eine Fehlersuche finden sich in diesem Artikel:

Troubleshooting Kerberos Errors

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

Weitere Informationen:

[1] http://www.ietf.org/rfc/rfc1510.txt

[2] Kerberos (Informatik)

http://de.wikipedia.org/wiki/Kerberos_%28Informatik%29

[3] Domänencontroller am Standort

http://blog.dikmenoglu.de/PermaLink,guid,ad2ea4b3-0374-4048-8b3d-43623c176328.aspx

[4] Tokensz

http://www.microsoft.com/downloads/details.aspx?FamilyID=4a303fa5-cf20-43fb-9483-0f0b0dae265c&DisplayLang=en

Kerberos Authentication in Windows Server 2003

http://www.microsoft.com/windowsserver2003/technologies/security/kerberos/default.mspx

Kerberos Authentication Tools and Settings

http://technet2.microsoft.com/WindowsServer/en/library/b36b8071-3cc5-46fa-be13-280aa43f2fd21033.mspx?mfr=true

Interactive logon styles and Key Distribution Center account lookup in Windows Server 2003

http://support.microsoft.com/kb/929272/en-us

Addressing Problems Due to Access Token Limitation

http://www.microsoft.com/downloads/details.aspx?familyid=22DD9251-0781-42E6-9346-89D577A3E74A&displaylang=en

New resolution for problems with Kerberos authentication when users belong to many groups

http://support.microsoft.com/kb/327825/en-us

Group Policy may not be applied to users belonging to many groups

http://support.microsoft.com/kb/263693/en-us

TechNet Webcast: Kerberos-Interoperabilität - Authentifizierungstickets für heterogene Clients

http://www.microsoft.com/germany/technet/webcasts/eventdetail.aspx?EventID=1032311283
Users in a trusted external Kerberos realm cannot access resources from a Windows Server 2003-based forest to another forest
by using a forest trust and a Kerberos trust
http://support.microsoft.com/kb/931192/en-us

Seit Windows Server 2003 ist es möglich, zwischen zwei Gesamtstrukturen eine Gesamtstrukturvertrauensstellung zu erstellen.
Das geht allerdings nur, wenn sich die Gesamtstruktur in dem Gesamtstrukturfunktionsmodus „Windows Server 2003“ befindet.
Eine Gesamtstruktur die in den Modus „Windows Server 2003“ gestuft werden soll, setzt voraus, das alle Domänen die sich in
der Gesamtstruktur befinden, auf dem Domänenfunktionsmodus „Windows Server 2003“ befinden.

Ein Zurückstufen der Ebenen, sei es der Domänenfunktionsmodus bzw. Gesamtstrukturfunktionsmodus ist im Nachhinein nicht mehr möglich!

Das Herauf stufen des Domänenfunktionsmodus kann entweder über das Snap-In „Active Directory-Benutzer und –Computer“ oder
„Active Directory-Domänen und -Vertrauensstellungen“ erledigt werden (mit einem Rechtsklick auf den FQDN),
wobei die Gesamtstruktur ausschließlich im Snap-In „Active Directory-Domänen und -Vertrauensstellung“ herauf gestuft werden kann.
Beides lässt sich ebenfalls durch bearbeiten (mit LDP.exe oder ADSIEdit.msc) des Attributs msDS-Behavior-Version herauf stufen. 

Siehe auch:
How to raise domain and forest functional levels in Windows Server 2003

Welche Funktionen in den einzelnen Ebenen de- bzw. aktiviert sind, kann man hier nachlesen:
Funktionalität von Domänen und Gesamtstrukturen

Des Weiteren kann jederzeit, bei einer bereits existierenden Vertrauensstellung z.B. zwischen einer Windows 2000/2003- und einer NT-Domäne,
der Domänenfunktionsmodus der Windows 2000/2003 Domäne herauf gestuft werden.

Dieser Vorgang hat auf die Vertrauensstellung keinen Einfluss.

Unterschiede zwischen einer externen- und Gesamtstrukturvertrauensstellung (Cross-Forest)

1. Externe Vertrauensstellung

Bei einer externen Vertrauensstellung kann eine uni- oder bidirektionale Vertrauensstellung zu einer einzelnen Domäne (in einer separaten Gesamtstruktur)
eingerichtet werden. Diese Art einer Vertrauensstellung, ist nie transitiv. Eine externe Vertrauensstellung kann notwendig sein, wenn Benutzer Zugriff auf
Ressourcen einer „fremden“ Domäne einer anderen Gesamtstruktur brauchen und keine Gesamtstrukturvertrauensstellung besteht.
Dadurch wird eine explizite Vertrauensstellung nur zu dieser einen Domäne erstellt. Wenn diese Domäne weiteren Domänen vertraut,
bleibt der Zugriff auf die weiteren Domänen verwehrt.
Eine externe Vertrauensstellung wird ab Windows 2000 SP4 (und höher) sowie Windows Server 2003 Domänencontrollern,
durch die Sicherheitskennung (Security Identifiers, SIDs) -Filterung abgesichert. Die SID-Filterung verhindert, das z.B. ein Benutzer
mit Domänenadministratorrechten auf die vertrauenswürdige Domäne zugreifen kann und entweder seinem oder anderen Benutzerkonten in der Domäne,
höhere Benutzerrechte für die vertrauende Domäne einrichten kann.

Gründe für das Erstellen einer externen Vertrauensstellung

2. Gesamtstrukturvertrauensstellung

In einer Active Directory-Gesamtstruktur, sind alle Domänen durch eine transitive Zweiweg- Kerberos-Vertrauensstellung miteinander verbunden.
Gesamtstrukturvertrauensstellungen haben den Vorteil, das diese vollständige Kerberos-Integration zwischen Gesamtstrukturen bieten,
nämlich bidirektional und transitiv. 
Bei einer Fusion zweier Unternehmen, wobei jedes Unternehmen seine eigene Windows Server 2003 Gesamtstruktur hat,
könnte eine Gesamtstrukturvertrauensstellung in Frage kommen. Denn damit könnten die Benutzer der Gesamtstruktur1,
auf die Ressourcen der Gesamtstruktur2 zugreifen (Zugriffsberechtigung vorausgesetzt), egal in welcher Domäne sich die Ressourcen befinden.

In Windows Server 2003 wurde eine neue Funktion eingeführt, die Fähigkeit, Konten über Domänenvertrauensstellungen hinweg,
selektiv zu authentifizieren. Beim einrichten einer Vertrauensstellung über das MMC-Snap-In „Active Directory-Domänen und -Vertrauensstellungen“,
gilt es an entsprechender Stelle die Auswahl zwischen einer „domänenweiten Authentifizierung“ oder „selektiven Authentifizierung“ zu treffen
(die später geändert werden kann). Bei einer selektiven Authentifizierung überprüfen Domänencontroller jedes einzelne Konto, ob es berechtigt ist,
auf Ressource in der Domäne zuzugreifen. Diese Variante wäre die sicherere, als z.B. die SID-Filterung.

Ein weiterer Punkt, ist das Namensuffixrouting zwischen Gesamtstrukturen. Dadurch hat man die Möglichkeit zu bestimmen,
wie Authentifizierungsanforderungen zwischen Gesamtstrukturen bei einer bestehenden Gesamtstrukturvertrauensstellung, weitergeleitet werden.
Bei Erstellung einer Gesamtstrukturvertrauensstellung werden zur Vereinfachung, alle eindeutigen Namensuffix weitergeleitet.
Eindeutige Namensuffixe innerhalb einer Gesamtstruktur, wären z.B. ein Dienstprinzipalnamen-Suffix (SPN),
ein Benutzerprinzipalnamen-Suffix (UPN) oder ein DNS-Domänenname [1].

Voraussetzungen um eine Vertrauensstellung unter Windows Server 2003 zu erstellen

Bevor eine Vertrauensstellung erstellt werden kann, muss zuerst eine Namensauflösung zwischen beiden Domänen/Gesamtstrukturen geschaffen werden.
Dies kann entweder über eine „bedingte Weiterleitung“ (conditional Forwarding) im DNS oder durch eine sekundäre DNS-Zone erreicht werden.
Es schadet auch nicht, die Namensauflösung zwischen Domänen (von NT/2000/2003 zu NT/2000/2003 Domänen)
weiterhin durch WINS (Replikation) zu sichern [2].
Bei einer Vertrauensstellung zu einer NT-Domäne, spielt WINS eine elementare Rolle.

Prüfliste: Erstellen einer Gesamtstrukturvertrauensstellung
 

Eine Vertrauensstellung erstellt man entweder über den Assistenten im Snap-In „Active Directory-Domänen und -Vertrauensstellung“ oder über NETDOM.
NETDOM befindet sich in den Windows Support Tools, die sich wiederum auf der Windows Server 2003 CD im Ordner Support/Tools befinden bzw. hier
heruntergeladen werden können:
http://www.microsoft.com/downloads/details.aspx?familyid=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en

Falls die Vertrauensstellung über NETDOM realisiert werden soll, so gilt es den Parameter „Trust“ anzugeben.

Beispiel: Um eine externe bidirektionale Vertrauensstellung einzurichten, gilt es folgenden Befehl in einer Kommandozeile einzugeben:
Netdom Trust <vertrauende Domäne> /d:<vertraute Domäne> /Add /Twoway

Netdom Examples
http://technet2.microsoft.com/WindowsServer/en/library/539c5381-db4f-445f-aac0-2df5448181c11033.mspx?mfr=true
Netdom Syntax
http://technet2.microsoft.com/WindowsServer/en/library/9f921edc-87f5-460e-89ee-9ca56ec1d0961033.mspx?mfr=true

Prinzipiell gilt:

Bevor eine Vertrauensstellung vom Local Security Authority (LSA) Prozess erstellt wird, prüft dieser die Eindeutigkeit folgender Auflistung:

• Den NetBIOS Namen der Domäne
• Den Fully Qualified Domain Name (FQDN) der Domäne
• Die Security Identifier (SID) der Domäne

Diese drei Punkte müssen eindeutig sein, da ansonsten keine Vertrauensstellung zu Stande kommt.
Falls beide Domänen den gleichen Namen haben sollten, ist es unter Windows Server 2003 möglich, eine von beiden Domänen umzubenennen [3].
Wenn die Domänen-SID gleich lautet, so muss eine von beiden Domänen de- und erneut installiert werden.
Diese Szenarien können eintreffen, wenn folgende Vorgehensweisen angewandt wurden:

• Eine Domäne wurde von der anderen geklont
• Nach dem installieren des Betriebssystems „Windows Server 2003“ auf einem Server, wurde dieser geklont und anschließend das SYSPREP nicht angewendet
  

Als Alternative kann eine von beiden Domänen, in eine neue Domäne (mit ADMT) migriert werden. Bei der Migration in eine neue Domäne,
kann dabei nicht auf die sIDHistory-Funktion zurückgegriffen werden. Denn auch nach einer erfolgreich erstellten Vertrauensstellung zur neu
erstellten Domäne, existieren duplizierte SIDs in den Benutzerzugriffstoken (User Access Token) [4].

Weitere Informationen:
[1] Gesamtstrukturübergreifendes Routing von Namensuffixen
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/ec5c297e-7f48-4db3-aae7-655b4b3c186f.mspx?mfr=true
[2] Wie sollte WINS konfiguriert werden?
http://www.faq-o-matic.net/2004/10/23/wie-sollte-wins-konfiguriert-werden/
[3] Windows Server 2003 Active Directory Domain Rename Tools
http://www.microsoft.com/technet/downloads/winsrvr/domainrename.mspx
[4] Access control in Active Directory
http://technet2.microsoft.com/WindowsServer/en/library/2f98f5b2-5e7e-4ff3-83a9-c32cf23329211033.mspx?mfr=true
Administration von Vertrauensstellungen für Domänen und Gesamtstrukturen
http://www.microsoft.com/germany/technet/prodtechnol/windowsserver/technologies/featured/ad/active-directory-betriebshandbuch-01.mspx
Support WebCast: Microsoft Windows Server 2003: Implementing an Active Directory Domain Rename Operation
http://support.microsoft.com/kb/819145/en-us
Error message when you create the trusted side of a trust between Windows Server 2003-based domains: "The parameter is incorrect”
http://support.microsoft.com/kb/930218/en-us
MS02-001: Forged SID could result in elevated privileges in Windows 2000
http://support.microsoft.com/kb/289243/en-us
Sind Vertrauensstellungen ohne NetBIOS-Namensauflösung möglich?
http://www.faq-o-matic.net/2006/07/01/sind-vertrauensstellungen-ohne-netbios-namensaufloesung-moeglich/
Windows Server 2003 Trust Enhancements
http://www.microsoft.com/technet/community/columns/profwin/pw0303.mspx

Ein Antivirusprogramm (Virenscanner) ist dafür da, um das System vor Schädlingen wie es Viren, Würmer und Trojanische Pferde darstellen, zu schützen.
Der Virenscanner spürt diese auf und löscht sie gegebenfalls.
Einen vollständigen Schutz vor Malware bietet ein Virenscanner hingegen nicht.

So hilfreich wie ein Virenscanner auch sein kann, so problematisch könnte der Echtzeitscanner (On-Access) werden.
Dieser agiert im Hintergrund als Systemdienst und scannt im Hintergrund alle Dateien, Programme und den Arbeitsspeicher.
Genau da liegt aber das Problem, denn der Virenscanner greift tief in das System ein und scannt auch Applikationen, die besser davor bewahrt wären.
Datenbanken wie sie z.B. auf einem Domänencontroller (NTDS.DIT) oder Exchange-Server existieren, können bei einem Echtzeitscan einen Schaden bekommen.

Damit dieses nicht passiert, bieten die meisten Virenscanner die Möglichkeit, diese Dateien in eine Art Ausschlussliste aufzunehmen.
Somit werden  die dort eingetragenen Dateien nicht vom Echtzeitscan überwacht.

Auf einem Domänencontroller sollten die Dateien die standardmäßig im Verzeichnis „%systemroot%\ntds“ gespeichert sind, ausgeschlossen werden.
Welche Dateien genau davon betroffen sind, kann man aus diesem Artikel entnehmen:
Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows

Die Dateien, die auf einem Exchange-Server vom Echtzeitscan verschont werden sollten, kann man hier entnehmen:
Recommendations for troubleshooting an Exchange Server computer with antivirus software installed
Exchange and antivirus software

Welche Virenscanner mit dem File Replication Service kompatibel sind, werden im folgenden Artikel aufgelistet:
Antivirus, backup, and disk optimization programs that are compatible with the File Replication Service

Wenn der DHCP-Server nicht startet, könnte es ebenfalls ein Indiz dafür sein, dass der Virenscanner die DHCP-Datenbank überwacht.
Dort sollte das Verzeichnis „%systemroot%\System32\DHCP“ vom Echtzeitscan verschont bleiben.
The DHCP service does not start when you start a Windows Server 2003-based computer