Freigeben über

Behandlung von LDAP-Servercookies

In LDAP ergeben einige Abfragen einen großen Ergebnissatz. Solche Abfragen stellen Windows Server vor bestimmte Herausforderungen.

Die Erfassung und Zusammenstellung solcher großen Ergebnissätze bedeutet einen beträchtlichen Arbeitsaufwand. Viele Attribute müssen von einer internen Darstellung in die LDAP-Wire-Darstellung konvertiert werden. Einige Attribute müssen für den LDAP-Antwortframe auch von einem internen, meist binären Format in ein textbasiertes UTF-8-Format konvertiert werden.

Eine weitere Herausforderung besteht darin, dass Ergebnissätze mit Zehntausenden von Objekten eine enorme Menge an Speicherplatz – leicht mehrere hundert Megabyte – benötigen. Diese erfordern dann sehr viel virtuellen Adressraum. Die Übertragung über das Netzwerk kann problematisch werden, wenn die TCP-Sitzung während der Übertragung zusammenbricht.

Diese Herausforderungen in Bezug auf Kapazität und Logistik haben dazu geführt, dass die Microsoft-LDAP-Entwickler*innen eine LDAP-Erweiterung mit einer „seitenweisen Abfrage“ entwickelt haben. Die seitenweise Abfrage implementiert ein LDAP-Steuerelement, das eine große Abfrage in mehrere Blöcke kleinerer Ergebnissätze aufteilt. Die seitenweise Abfrage ist ein RFC-Standard: RFC 2696.

Bei der Methode der seitenweisen Abfrage wird die vom Client oder in einer LDAP-Richtlinie („MaxPageSize“) festgelegte Seitengröße verwendet. Der Client muss die Auslagerung durch die Übergabe eines LDAP-Steuerelements aktivieren.

Eine Abfrage mit sehr vielen Ergebnissen gelangt irgendwann an einen Punkt, an dem die maximale Anzahl der zulässigen Objekte erreicht ist. Der LDAP-Server verpackt die Antwortnachricht und fügt ihr ein Cookie mit Informationen hinzu, die er später zur Fortsetzung der Suche benötigt.

Die Clientanwendung muss das Cookie als nicht transparentes BLOB behandeln. Es kann die Objektanzahl in der Antwort abrufen und die Suche basierend auf dem Vorhandensein des Cookies fortsetzen. Zum Fortsetzen der Suche sendet der Client dieselbe Abfrage an den LDAP-Server, einschließlich des Cookiewerts aus der vorherigen Antwort.

Wenn die Anzahl der Objekte keine Seite mehr füllt, ist die LDAP-Abfrage abgeschlossen, und die Antwort enthält kein Seitencookie mehr. Wenn vom Server kein Cookie mehr zurückgegeben wird, kann der Client davon ausgehen, dass die seitenweise Suche erfolgreich abgeschlossen wurde.

Wenn der Server einen Fehler zurückgibt, muss der Client davon ausgehen, dass die seitenweise Suche fehlgeschlagen ist. Eine Wiederholung der Suche führt dazu, dass die Suche erneut bei der ersten Seite beginnt.

Windows Server gibt das Cookie an den Client zurück. Gelegentlich werden auf dem Server auch Informationen zum Cookie gespeichert. Diese Informationen werden in einem Server-Cache gespeichert, der bestimmten Einschränkungen unterliegt.

Falls Informationen im Cache gespeichert werden, wird das vom Server an den Client gesendete Cookie auch vom Server zum Suchen der Informationen aus dem Server-Cache verwendet. Wenn der Client die seitenweise Suche fortsetzt, verwendet Windows Server das Clientcookie und alle relevanten Informationen aus dem Cookiecache des Servers zum Fortsetzen der Suche. Findet der Server, aus welchem Grund auch immer, im Servercache keine relevanten Cookieinformationen, wird die Suche abgebrochen und ein Fehler an den Client zurückgegeben.

Offensichtlich bedient der LDAP-Server mehrere Clients gleichzeitig. Darüber hinaus können mehrere Clients gleichzeitig Abfragen starten, die die Verwendung des Servercookiecache erfordern. Daher wird bei der Windows Server-Implementierung die Verwendung des Cookiepools nachverfolgt, und es werden Grenzwerte festgelegt, damit der Cookiepool nicht zu viele Ressourcen in Anspruch nimmt. Administrator*innen können Grenzwerte in der LDAP-Richtlinie mithilfe der folgenden Einstellungen festlegen. Nachfolgend sind die Standardwerte mit Erläuterungen angegeben:

MinResultSets: 4

Der LDAP-Server ignoriert die maximale Poolgröße, wenn der Cookiecache des Servers weniger Einträge enthält, als durch „MinResultSets“ angegeben sind.

MaxResultSetSize: 262.144 Bytes

Die Gesamtgröße des Cookiecache auf dem Server darf MaxResultSetSize in Bytes nicht überschreiten. Andernfalls werden Cookies beginnend beim ältesten Cookie gelöscht, bis die Größe des Pools wieder kleiner als MaxResultSetSize in Bytes ist oder sich im Pool weniger als MinResultSets Cookies befinden. Mit den Standardeinstellungen akzeptiert der LDAP-Server einen Pool mit einer Größe von 450 KB, wenn der Pool nur 3 Cookies enthält.

MaxResultSetsPerConn: 10

Der LDAP-Server lässt im Pool nicht mehr als MaxResultSetsPerConn Cookies pro LDAP-Verbindung zu.

Handhabung gelöschter Cookies

Das Entfernen von Cookieinformationen aus dem Cache des LDAP-Servers führt nicht in jedem Fall sofort zu einem Anwendungsfehler. Vielmehr können die Anwendungen die seitenweise Suche von Beginn an neu starten und in einem weiteren Versuch erfolgreich zu Ende führen. Einige Anwendungen verfügen aus Stabilitätsgründen über diese Art von Wiederholungsmechanismus.

Einige Anwendungen können eine seitenweise Suche eventuell nie abschließen. Durch eine solche nicht abgeschlossene Suche können im Cookiecache des LDAP-Servers Einträge zurückbleiben, die durch den zuvor beschriebenen Mechanismus verarbeitet werden. Dieser Mechanismus ist wichtig, um den Speicherplatz des Servers wieder für aktive LDAP-Suchvorgänge freizugeben.

Was geschieht, wenn ein solches Cookie auf dem Server gelöscht wird und der Client die Suche mit diesem Cookiehandle fortsetzt? Der LDAP-Server findet das Cookie in diesem Fall nicht in seinem Cookiecache und gibt für die Abfrage eine Fehlermeldung zurück. Die Fehlerantwort ähnelt folgender:

00000057: LdapErr: DSID-xxxxxxxx, comment: Error processing control, data 0, v1db1

Hinweis

Der auf „DSID“ folgende Hexadezimalwert variiert je nach Buildversion der Binärdateien des LDAP-Servers.

Der LDAP-Server kann Ereignisse über die Kategorie 16 Ldap Interface der NTDS-Diagnoseschlüssel protokollieren. Wenn Sie diese Kategorie auf 2 setzen, erhalten Sie die folgenden Ereignisse:

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Event ID:      2898
Task Category: LDAP Interface
Level:         Information
Description:
Internal event: The LDAP server has reached the limit of the number of Result Sets it will maintain for a single connection.  A stored Result Set will be discarded.  This will result in a client being unable to continue a paged LDAP search.
Maximum number of Result Sets allowed per LDAP connection:
10
Current number of Result Sets for this LDAP connection:
11

User Action
The client should consider a more efficient search filter.  The limit for Maximum Result Sets per Connection may also be increased.


Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Event ID:      2899
Task Category: LDAP Interface
Level:         Information
Description:
Internal event: The LDAP server has exceeded the limit of the LDAP Maximum Result Set Size. A stored Result Set will be discarded. This will result in a client being unable to continue a paged LDAP search.

Number of result sets currently stored:
4
Current Result Set Size:
263504
Maximum Result Set Size:
262144
Size of single Result Set being discarded:
40876
User Action
The client should consider a more efficient search filter.  The limit for Maximum Result Set Size may also be increased.

Diese Ereignisse signalisieren, dass ein gespeichertes Cookie entfernt wurde. Es bedeutet nicht, dass der LDAP-Fehler bereits bis zu einem Client durchgedrungen ist, sondern lediglich, dass der LDAP-Server die vom Administrator bzw. der Administratorin festgelegten Grenzwerte für den Cache erreicht hat. In einigen Fällen hat der LDAP-Client seine seitenweise Suche auch schon abgebrochen, so dass der Fehler bei ihm gar nicht in Erscheinung tritt.

Wenn in Ihrer Domäne noch nie ein LDAP-Suchfehler aufgetreten ist, brauchen Sie den Cookiepool des LDAP-Servers für die seitenweise Suche gar nicht zu überwachen. Treten in Ihrer Umgebung hingegen Fehler in Verbindung mit der seitenweisen LDAP-Suche auf, liegt eventuell ein Problem mit den vom Administrator festgelegten Grenzen für den Cookiepool vor.

Die Ereignisse 2898 und 2899 sind der einzige sichere Hinweis darauf, dass der LDAP-Server die Administratorgrenzen erreicht hat. Wenn Sie feststellen, dass LDAP-Abfragen aufgrund der Steuerverarbeitungsfehler fehlschlagen, sollten Sie die Grenzwerte der LDAP-Richtlinieneinstellungen ggf. heraufsetzen. Die Grenzwerte finden Sie im Abschnitt Verwaltung des Cookiepools, je nach erhaltenen Ereignissen.

Erhalten Sie auf Ihrem DC/LDAP-Server Ereignis 2898, empfiehlt sich eine Erhöhung von MaxResultSetsPerConn auf 25. Mehr als 25 parallel ausgeführte seitenweise Suchvorgänge über eine einzige LDAP-Verbindung sind ungewöhnlich. Falls Sie Ereignis 2898 weiterhin erhalten, sollten Sie die LDAP-Clientanwendung überprüfen, in der der Fehler auftritt. In diesem Fall liegt es nahe, dass die Anwendung beim Abrufen weiterer seitenweiser Ergebnisse hängen bleibt, das Cookie daraufhin im Status „Ausstehend“ belässt und eine neue Abfrage startet. Überprüfen Sie, ob der Anwendung an einem bestimmten Punkt für ihre Zwecke ausreichend Cookies zur Verfügung stehen. Sie können auch den Wert von MaxResultSetsPerConn auf einen höheren Wert als 25 festlegen. Werden auf Ihren Domänencontrollern hingegen Ereignisse vom Typ 2899 zurückgegeben, sähe die Strategie anders aus. Wird Ihr DC/LDAP-Server in diesem Fall auf einem Computer mit ausreichend Arbeitsspeicher ausgeführt (d. h. es sind mehrere GB Arbeitsspeicher frei), sollten Sie MaxResultsetSize auf dem LDAP-Server auf einen Wert >=250 MB setzen. Dieser Grenzwert ist auch für große Mengen umfangreicher seitenweiser LDAP-Suchen auch in sehr großen Verzeichnissen mehr als ausreichend.

Wenn Sie bei einem Pool mit mindestens 250 MB nach wie vor Ereignisse vom Typ 2899 erhalten, ist zu vermuten, dass auf dicht aufeinander folgende Abfragen vieler Clients große Mengen an Objekten in kürzester Folge zurückgegeben werden. Die Daten, die Sie mit dem Active Directory-Datensammlersatz sammeln können, helfen Ihnen u. U. dabei, Abfragen mit repetitiver Seitenzahl zu finden, die Ihren LDAP-Servern Probleme bereiten. Diese Abfragen werden mit einem Wert für die „zurückgegebenen Einträge“ angezeigt, der der Anzahl der verwendeten Seite entspricht.

Wenn möglich, sollten Sie das Anwendungsdesign überprüfen und ein anderes Konzept mit einer niedrigeren Abfragefrequenz, geringeren Datenvolumen und/oder weniger Clientinstanzen implementieren, die diese Daten abfragen. Im Falle von Anwendungen, auf deren Quellcode Sie Zugriff haben, lesen Sie den Artikel Erstellen effizienterer Microsoft Active Directory-fähiger Anwendungen, um die optimale Methode zu verstehen, mit der Anwendungen auf AD zugreifen sollten.

Falls sich das Abfrageverhalten nicht ändern lässt, besteht eine weitere Strategie darin, die Anzahl der replizierten Instanzen der benötigten Namenskontexte zu erhöhen und die Clients neu zu verteilen. Durch Replizieren der Instanz und Verteilen des Clients kann die Last auf den einzelnen LDAP-Servern verringert werden.