Directory Services-Komponentenupdates
Autor: Justin Turner, Senior Support Escalation Engineer bei der Windows-Gruppe
Hinweis
Dieser Inhalt wurde von einem Mitarbeiter des Microsoft-Kundendiensts geschrieben und richtet sich an erfahrene Administratoren und Systemarchitekten, die einen tieferen technischen Einblick in die Funktionen und Lösungen von Windows Server 2012 R2 suchen, als Ihnen die Themen im TechNet bieten können. Allerdings wurde er nicht mit der gleichen linguistischen Sorgfalt überprüft wie für die Artikel des TechNet üblich, so dass die Sprache gelegentlich holprig klingen mag.
In dieser Lektion werden Updates von Directory Services-Komponenten unter Windows Server 2012 R2 erläutert.
Sie lernen Folgendes
Erläutern der folgenden neuen Updates von Directory Services-Komponenten:
Erläutern der folgenden neuen Updates von Directory Services-Komponenten:
Domänen- und Gesamtstrukturfunktionsebenen
Übersicht
Der Abschnitt enthält eine kurze Einführung in die Änderungen auf Domänen- und Gesamtstrukturfunktionsebene.
Neue Domänen- und Gesamtstrukturfunktionsebenen
In dieser Version gibt es neue Domänen- und Gesamtstrukturfunktionsebenen:
Gesamtstrukturfunktionsebene: Windows Server 2012 R2
Domänenfunktionsebene: Windows Server 2012 R2
Die Domänenfunktionsebene Windows Server 2012 R2 unterstützt Folgendes:
Domänencontrollerseitiger Schutz für geschützte Benutzer
Geschützten Benutzer, die sich bei einer Windows Server 2012 R2-Domäne authentifizieren, ist Folgendes nicht mehr möglich:
Authentifizieren mit der NTLM-Authentifizierung
Verwenden von DES- oder RC4-Suites mit Verschlüsselungsverfahren bei der Kerberos-Vorauthentifizierung
Delegierung mit eingeschränkter oder nicht eingeschränkter Delegierung
Erneuern von Benutzertickets (TGTs) jenseits der ursprünglichen vierstündigen Lebensdauer
Authentifizierungsrichtlinien
Es sind neue gesamtstrukturbasierte Active Directory-Richtlinien verfügbar, die für Konten in Windows Server 2012 R2-Domänen gelten können. Mit diesen kann gesteuert werden, bei welchen Hosts sich ein Konto anmelden kann, und es können Zugriffssteuerungsbedingungen zur Authentifizierung für Dienste angewendet werden, die als Konto ausgeführt werden.
Authentifizierungsrichtliniensilos
Es ist ein neues gesamtstrukturbasiertes Active Directory-Objekt verfügbar, das eine Beziehung zwischen dem Benutzer, verwalteten Dienst und Computer sowie Konten herstellen kann, die zum Klassifizieren von Konten für Authentifizierungsrichtlinien oder die Authentifizierungsisolation verwendet werden.
Weitere Informationen finden Sie unter „Konfigurieren geschützter Konten“.
Zusätzlich zu den oben genannten Features stellt die Domänenfunktionsebene Windows Server 2012 R2 sicher, dass auf jedem Domänencontroller in der Domäne Windows Server 2012 R2 ausgeführt wird. Die Windows Server 2012 R2-Gesamtstrukturfunktionsebene bietet zwar keine neuen Features, stellt jedoch sicher, dass alle in der Gesamtstruktur erstellten neuen Domänen automatisch auf der Windows Server 2012 R2-Domänenfunktionsebene funktionieren.
Bei Erstellung einer neuen Domäne erzwungene Mindestdomänenfunktionsebene
Die Domänenfunktionsebene Windows Server 2008 ist die Mindestfunktionsebene, die bei Erstellung einer neuen Domäne unterstützt wird.
Hinweis
Die Außerbetriebnahme von FRS wird dadurch erreicht, dass die Möglichkeit entfernt wird, eine neue Domäne mit einer Domänenfunktionsebene unterhalb von Windows Server 2008 mit Server-Manager oder über Windows PowerShell zu installieren.
Herunterstufen von Gesamtstruktur- und Domänenfunktionsebenen
Die Gesamtstruktur- und Domänenfunktionsebenen sind bei Erstellung einer neuen Domäne und einer neuen Gesamtstruktur standardmäßig auf Windows Server 2012 R2 festgelegt, können aber mit Windows PowerShell heruntergestuft werden.
Mit dem Windows PowerShell-Cmdlet Set-ADForestMode können Sie die Gesamtstrukturfunktionsebene herauf- oder herunterstufen.
So legen Sie die Gesamtstrukturfunktionsebene von contoso.com auf den Modus Windows Server 2008 fest
Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com
Mit dem Windows PowerShell-Cmdlet Set-ADDomainMode können Sie die Domänenfunktionsebene herauf- oder herunterstufen.
So legen Sie die Domänenfunktionsebene von contoso.com auf den Modus Windows Server 2008 fest
Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com
Das Heraufstufen eines Domänencontrollers, auf dem Windows Server 2012 R2 ausgeführt wird, zu einem zusätzlichen Replikat in einer vorhandenen Domäne mit der Domänenfunktionsebene 2003 funktioniert.
Erstellung einer neuen Domäne in einer bestehenden Gesamtstruktur
ADPREP
In dieser Version gibt es keine neuen Gesamtstruktur- oder Domänenfunktionsebenen.
Diese LDF-Dateien enthalten Schemaänderungen für den Geräteregistrierungsdienst.
Sch59
Sch61
Sch62
Sch63
Sch64
Sch65
Sch67
Arbeitsordner:
- Sch66
MSODS:
- Sch60
Authentifizierungsrichtlinien und Silos
Sch68
Sch69
Abschreibung von NTFRS
Übersicht
FRS gilt unter Windows Server 2012 R2 als veraltet. Die Außerbetriebnahme von FRS wird erreicht, indem die Mindestdomänenfunktionsebene Windows Server 2008 erzwungen wird. Diese Erzwingung erfolgt nur, wenn die neue Domäne mit Server-Manager oder Windows PowerShell erstellt wird.
Sie verwenden den Parameter -DomainMode mit den Cmdlets Install-ADDSForest oder Install-ADDSDomain, um die Domänenfunktionsebene anzugeben. Unterstützte Werte für diesen Parameter können entweder eine gültige ganze Zahl oder ein entsprechender aufgezählter Zeichenfolgenwert sein. Wenn Sie beispielsweise die Domänenmodusebene auf Windows Server 2008 R2 festlegen möchten, können Sie entweder den Wert 4 oder „Win2008R2“ angeben. Wenn Sie diese Cmdlets unter Windows Server 2012 R2 ausführen, sind auch die Werte für Windows Server 2008 (3, Win2008) Windows Server 2008 R2 (4, Win2008R2) Windows Server 2012 (5, Win2012) und Windows Server 2012 R2 (6, Win2012R2) gültig. Die Domänenfunktionsebene kann nicht niedriger als die Funktionsebene der Gesamtstruktur sein. Sie kann jedoch höher sein. Da FRS in dieser Version nicht mehr unterstützt wird, ist Windows Server 2003 (2, Win2003) kein von diesen Cmdlets erkannter Parameter, wenn die Ausführung unter Windows Server 2012 R2 erfolgt.
Änderungen am LDAP-Abfrageoptimierer
Übersicht
Der Algorithmus zur Optimierung von LDAP-Abfragen wurde überarbeitet und weiter optimiert. Das Ergebnis sind Leistungsverbesserungen bei der LDAP-Suche und bessere LDAP-Suchzeiten bei komplexen Abfragen.
Hinweis
Vom Entwickler: Verbesserungen bei der Leistung von Suchvorgängen bis zu Verbesserungen der Zuordnung von LDAP-Abfragen zu ESE-Abfragen. LDAP-Filter, die eine bestimmte Komplexitätsebene überschreiten, verhindern eine optimierte Indexauswahl, was zu drastischen Leistungseinbußen (1.000-fach oder mehr) führt. Mit dieser Änderung wird die Art und Weise geändert, in der wir Indizes für LDAP-Abfragen auswählen, um dieses Problem zu vermeiden.
Hinweis
Eine vollständige Überarbeitung des Algorithmus zur Optimierung von LDAP-Abfragen, was zu folgendem Ergebnis führt:
- Schnellere Suchzeiten
- Effizienzsteigerungen ermöglichen Domänencontrollern mehr Leistung
- Weniger Anrufe beim Support aufgrund von AD-Leistungsproblemen
- Rückportierung zu Windows Server 2008 R2 (KB 2862304)
Hintergrund
Die Möglichkeit der Durchsuchung von Active Directory ist ein zentraler Dienst, der von Domänencontrollern bereitgestellt wird. Andere Dienste und branchenspezifische Anwendungen basieren auf Active Directory-Suchvorgängen. Wenn dieses Feature nicht verfügbar ist, kann der Geschäftsbetrieb zum Erliegen kommen. Als zentraler und stark genutzter Dienst müssen Domänencontroller LDAP-Datenverkehr unbedingt effizient bewältigen. Der Algorithmus zur Optimierung von LDAP-Abfragen versucht, LDAP-Suchen so effizient wie möglich zu gestalten, indem LDAP-Suchfilter einem Resultset zugeordnet werden, das durch bereits in der Datenbank indizierte Datensätze vervollständigt werden kann. Dieser Algorithmus wurde überarbeitet und weiter optimiert. Das Ergebnis sind Leistungsverbesserungen bei der LDAP-Suche und bessere LDAP-Suchzeiten bei komplexen Abfragen.
Details der Änderung
Eine LDAP-Suche enthält Folgendes:
Eine Position (NC-Head, Organisationseinheit, Objekt) innerhalb der Hierarchie zum Starten der Suche
Einen Suchfilter
Eine Liste zurückzugebender Attribute
Der Suchprozess lässt sich folgendermaßen zusammenfassen:
Vereinfachen Sie nach Möglichkeit den Suchfilter.
Wählen Sie einen Satz von Indexschlüsseln aus, der den kleinsten abgedeckten Satz zurückgibt.
Führen Sie eine oder mehrere Schnittmengen von Indexschlüsseln durch, um den abgedeckten Satz zu reduzieren.
Bewerten Sie für jeden Datensatz im abgedeckten Satz den Filterausdruck und die Sicherheit. Wenn der Filter mit TRUE ausgewertet wird und Zugriff gewährt wird, geben Sie diesen Datensatz an den Client zurück.
Die LDAP-Abfrageoptimierung ändert die Schritte 2 und 3, um die Größe des abgedeckten Satzes zu reduzieren. Genauer gesagt wählt die aktuelle Implementierung doppelte Indexschlüssel aus und nimmt redundante Schnittmengen vor.
Vergleich des alten und neuen Algorithmus
Das Ziel der ineffizienten LDAP-Suche in diesem Beispiel ist ein Windows Server 2012-Domänencontroller. Die Suche wird nach ca. 44 Sekunden abgeschlossen, da die Suche nach einem effizienteren Index fehlgeschlagen ist.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfind.txt
Using server: WINSRV-DC1.blue.contoso.com:389
<removed search results>
Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
DNT_index:516615:N
Pages Referenced : 4619650
Pages Read From Disk : 973
Pages Pre-read From Disk : 180898
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Beispielergebnisse mit dem neuen Algorithmus
In diesem Beispiel wird dieselbe Suche wie oben wiederholt, allerdings mit einem Windows Server 2012 R2-Domänencontroller als Ziel. Dank der Verbesserungen am Algorithmus zur Optimierung von LDAP-Abfragen wird die gleiche Suche in weniger als einer Sekunde abgeschlossen.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfindBLUE.txt
Using server: winblueDC1.blue.contoso.com:389
.<removed search results>
Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
idx_userPrincipalName:648:N
idx_postalCode:323:N
idx_cn:1:N
Pages Referenced : 15350
Pages Read From Disk : 176
Pages Pre-read From Disk : 2
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Wenn die Struktur nicht optimiert werden kann:
Beispiel: Ein Ausdruck in der Struktur befand sich über einer nicht indizierten Spalte
Aufzeichnen einer Liste von Indizes, die die Optimierung verhindern
Über ETW-Ablaufverfolgung und Ereignis-ID 1644 verfügbar gemacht
So aktivieren Sie das Steuerelement „Statistik“ in LDP
Öffnen Sie „LDP.exe“, stellen Sie eine Verbindung her, und nehmen Sie eine Bindung an einen Domänencontroller vor.
Wählen Sie im Menü Optionen die Option Steuerelemente aus.
Erweitern Sie im Dialogfeld „Steuerelemente“ das Pulldownmenü Vordefiniert laden. Wählen Sie Statistiken durchsuchen und dann OK aus.
Wählen Sie im Menü Durchsuchen die Option Suchen aus.
Wählen Sie im Dialogfeld „Suchen“ die Schaltfläche Optionen aus.
Stellen Sie sicher, dass das Kontrollkästchen Erweitert im Dialogfeld „Suchoptionen aktiviert“ ist, und wählen Sie OK aus.
Experiment: Verwenden von LDP zum Zurückgeben von Abfragestatistiken
Führen Sie die folgenden Schritte auf einem Domänencontroller oder von einem in die Domäne eingebundenen Client oder Server aus, auf dem die AD DS-Tools installiert sind. Wiederholen Sie die folgenden Aktionen für Ihren Windows Server 2012-Domänencontroller und Windows Server 2012 R2-Domänencontroller.
Lesen Sie den Artikel Erstellen effizienterer Microsoft Active Directory-fähiger Anwendungen, und nehmen Sie bei Bedarf Bezug darauf.
Aktivieren Sie mithilfe von LDP Suchstatistiken (weitere Informationen finden Sie unter Aktivieren des Steuerelements „Statistik“ in LDP).
Führen Sie mehrere LDAP-Suchvorgänge durch, und beobachten Sie die statistischen Informationen oben in den Ergebnissen. Sie wiederholen dieselbe Suche bei anderen Aktivitäten, weshalb Sie sie in einer Textdatei in Editor dokumentieren sollten.
Durchführen einer LDAP-Suche, die der Abfrageoptimierer aufgrund der Indizierung von Attributen optimieren können sollte
Versuchen Sie, eine Suche zu konfigurieren, die sehr lange dauert. (Sie können beispielsweise die Option Zeitlimit erhöhen, damit die Suche kein Timeout verursacht.)
Zusätzliche Ressourcen
Was sind Active Directory-Suchvorgänge?
Funktionsweise von Active Directory-Suchvorgängen
Erstellen effizienterer Microsoft Active Directory-fähiger Anwendungen
951581 LDAP-Abfragen werden im Verzeichnisdienst AD oder LDS/ADAM langsamer als erwartet ausgeführt, und die Ereignis-ID 1644 wird ggf. protokolliert
Verbesserungen am Ereignis 1644
Übersicht
Dieses Update fügt zusätzliche LDAP-Suchergebnisstatistiken zur Ereignis-ID 1644 hinzu, um die Problembehandlung zu erleichtern. Darüber hinaus gibt es einen neuen Registrierungswert, mit dem Sie die Protokollierung anhand eines zeitbasierten Schwellenwerts aktivieren können. Diese Verbesserungen wurden in Windows Server 2012 und Windows Server 2008 R2 SP1 über KB 2800945 zur Verfügung gestellt und werden auch für Windows Server 2008 SP2 zur Verfügung gestellt.
Hinweis
- Zusätzliche LDAP-Suchstatistiken werden zur Ereignis-ID 1644 hinzugefügt, um die Problembehandlung bei ineffizienten oder aufwändigen LDAP-Suchvorgängen zu erleichtern.
- Sie können jetzt einen Schwellenwert für die Suchzeit angeben (z. B. Protokollereignis 1644 für Suchvorgänge, die länger als 100 ms dauern), anstatt die Schwellenwerte für aufwändige und ineffiziente Suchergebnisse anzugeben.
Hintergrund
Bei der Behandlung von Active Directory-Leistungsproblemen wird deutlich, dass die LDAP-Suchaktivität möglicherweise zum Problem beiträgt. Sie entscheiden sich, die Protokollierung zu aktivieren, damit Sie erkennen können, welche aufwändigen oder ineffizienten LDAP-Abfragen der Domänencontroller verarbeitet hat. Um die Protokollierung zu aktivieren, müssen Sie den Diagnosewert „Field Engineering“ festlegen und können optional die Schwellenwerte für aufwändige/ineffiziente Suchergebnisse angeben. Wenn Sie die Protokollierungsebene „Field Engineering“ mit dem Wert 5 aktivieren, wird jede Suche, die diese Kriterien erfüllt, im Directory Services-Ereignisprotokoll mit der Ereignis-ID 1644 protokolliert.
Das Ereignis enthält Folgendes:
Client-IP und -Port
Startknoten
Filtern
Suchbereich
Attributauswahl
Serversteuerelemente
Besuchte Einträge
Zurückgegebene Einträge
Allerdings fehlen in dem Ereignis wichtige Daten, wie z. B. die Dauer des Suchvorgangs und der verwendete Index (sofern vorhanden).
Zusätzliche Ereignis 1644 hinzugefügte Suchstatistiken
Verwendete Indizes
Seiten, auf die verwiesen wird
Auf Datenträger gelesene Seiten
Auf Datenträger vorab gelesene Seiten
Geänderte bereinigte Seiten
Geänderte unbereinigte Seiten
Suchzeit
Attribute, die die Optimierung verhindern
Neuer zeitbasierter Registrierungswert für Schwellenwert für die Protokollierung des Ereignisses 1644
Anstatt Schwellenwerte für aufwändige und ineffiziente Suchergebnisse anzugeben, können Sie den Schwellenwert für die Suchzeit angeben. Wenn Sie alle Suchergebnisse protokollieren möchten, die mindestens 50 ms gedauert haben, geben Sie 50 (dezimal)/32 (hexadezimal) an (zusätzlich zum Festlegen des Werts für „Field Engineering“).
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032
Vergleich der alten und neuen Ereignis-ID 1644
OLD
NEW
Experiment: Zurückgeben von Abfragestatistiken mithilfe des Ereignisprotokolls
Wiederholen Sie die folgenden Aktionen für Ihren Windows Server 2012-Domänencontroller und Windows Server 2012 R2-Domänencontroller. Beobachten Sie nach jeder Suche auf beiden Domänencontrollern die Ereignis-ID 1644.
Aktivieren Sie mit regedit die Protokollierung der Ereignis-ID 1644 mit einem zeitbasierten Schwellenwert auf dem Windows Server 2012 R2-Domänencontroller und die alte Methode auf dem Windows Server 2012-Domänencontroller.
Führen Sie mehrere LDAP-Suchvorgänge durch, die den Schwellenwert überschreiten, und beobachten Sie die statistischen Informationen oben in den Ergebnissen. Verwenden Sie die LDAP-Abfragen, die Sie zuvor dokumentiert haben, und wiederholen Sie dieselben Suchvorgänge.
Führen Sie eine LDAP-Suche durch, die vom Abfrageoptimierer nicht optimiert werden kann, da mindestens ein Attribut nicht indiziert ist.
Durchsatzverbesserung bei der Active Directory-Replikation
Übersicht
Die AD-Replikation verwendet RPC für den Replikationstransport. Standardmäßig verwendet RPC die Übertragungspuffergröße 8 KB und die Paketgröße 5 KB. Dies hat zur Folge, dass die sendende Instanz drei Pakete (ca. 15 KB Daten) überträgt und dann auf einen Netzwerkroundtrip warten muss, ehe weitere Pakete gesendet werden. Bei einer Roundtripzeit von 3 ms würde der höchste Durchsatz bei etwa 40 Mbit/s liegen, selbst in Netzwerken mit 1 Gbit/s oder 10 Gbit/s.
Hinweis
Dieses Update erhöht den maximalen Durchsatz bei der AD-Replikation von 40 Mbit/s auf ca. 600 Mbit/s.
- Dadurch wird die Größe des RPC-Sendepuffers erhöht, wodurch die Anzahl von Netzwerkroundtrips reduziert wird.
Die Auswirkung ist am deutlichsten bei Hochgeschwindigkeitsnetzwerken mit hoher Latenz.
Durch diese Updates wird der maximale Durchsatz auf etwa 600 MBit/s erhöht, indem die RPC-Sendepuffergröße von 8 KB in 256 KB geändert wird. Durch diese Änderung kann die TCP-Fenstergröße über 8 KB hinaus erhöht werden, wodurch sich die Anzahl von Netzwerkroundtrips reduziert.
Hinweis
Es gibt keine konfigurierbaren Einstellungen, um dieses Verhalten zu ändern.