Änderungen an LDAP Policies – sinnvoll oder nicht?

Hallo, Fabian hier. Oft bekommen wir Anfragen unserer Kunden, die das “Tuning” von Active Directory bzw. LDAP Parametern betreffen, so z.B. “MaxPageSize” oder “MaxResultSetSize”. In einer Vielzahl dieser Fälle soll in der jeweiligen Active Directory Umgebung eine Software eingesetzt werden, die bei Active Directory LDAP Abfragen z.B. Timeouts bekommt bzw. nicht die erwarteten Ergebnisse zurückgegeben werden. In letzterem Fall werden entweder 1.000 (Windows 2000 Server) oder 1.5000 (Windows Server 2003) Werte zurückgegeben, auch wenn mehr Objekte erwartet werden (siehe http://msdn.microsoft.com/en-us/library/ms676302.aspx).

Der vermeintlich “leichteste Weg” ist dann oftmals die Anfrage, ob Werte wie “MaxPageSize” und “MaxResultSetSize” problemlos angepaßt werden können (siehe http://support.microsoft.com/kb/315071/en-US). Ein Kollege aus den USA hat dazu einmal ein paar passende Sätze gesagt, die ich im Wortlaut und einigen zusätzlichen Anmerkungen hier darstellen möchte:

Ich kann diese Änderung nicht empfehlen und rate in den meisten Fällen davon ab, diese Werte zu verändern.

Die von uns standardmäßig ausgelieferten Werte sind das Ergebnis langwieriger Tests und Erfahrungswerte. Das Verändern der Werte kann schwerwiegende Konsequenzen für die Funktionalität einer Active Directory Umgebung nach sich ziehen.

Der jeweilige Einfluß einer Veränderung der im KB-Artikel 315071 aufgeführten Werte kann natürlich nur im konkreten Fall betrachtet werden und wenn alle Eckdaten der Active Directory Umgebung bekannt sind. Jedoch haben wir diverse Erfahrungswerte, die mich von einem solchen Vorgehen abraten lassen:

So sind uns z.B. Szenarien bekannt, in denen (insbesondere auf 32 Bit Systemen) LDAP Abfragen abbrechen, die Serverperformance der DCs massiv bei Abfragen einbricht (und infolge dessen diverse Probleme in der AD-Umgebung auftreten können) und in “worst case” Szenarien auch Serverabstürze die Folge sein können.

Weiterhin ist die Anpassung der Werte meist nur temporär erfolgreich, da später Änderungen in der Umgebung eintreten können, die die Grenzen wieder verschieben. Somit ist unter Umständen auch die Wertanpassung nur von eingeschränkter Dauer.

Daher ist es in der Mehrzahl der Fälle sinnvoller, die Applikation mittels “Paged Searches” / “Attribute Range Retrieval” auszustatten. Da diese Begrenzung der Rückgabewerte nicht erst seit gestern existiert, haben sich die meisten Applikationshersteller schon darauf eingerichtet – bei Applikationen, die diese Möglichkeit noch nicht besitzen, könnte mit einer Änderung im Code ausgeholfen werden.

Wir haben einige Codebeispiele zur Verfügung gestellt, um ggf. den Applikationscode noch einmal zu überarbeiten bzw. anzupassen:

Retrieving Large Results Sets
http://msdn2.microsoft.com/en-us/library/aa746459.aspx

Paging Search Results
http://msdn2.microsoft.com/en-us/library/aa367011.aspx

ldap_search_ext
http://msdn2.microsoft.com/en-us/library/aa366971.aspx

LDAP_PAGED_RESULT_OID_STRING
http://msdn2.microsoft.com/en-us/library/aa366953.aspx

http://msdn2.microsoft.com/en-us/library/aa367017.aspx

Rein theoretisch wäre es übrigens auch möglich, eine Änderung der LDAP Policies nicht für alle DCs der Domäne durchzuführen, sondern nur für DCs einer Site. Sollte es also unbedingt notwendig sein die Änderung doch durchzuführen (wovon wir wie gesagt im Normalfall abraten), ließe sich ein oder mehrere DCs in eine eigene Site verschieben, die mit veränderten LDAP Policy Werten ausgestattet wird. Diese Veränderung greift dann nur für DCs dieser Site, siehe http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsfl_utl_cazy.mspx?mfr=true und http://technet2.microsoft.com/windowsserver/en/library/39658d2d-ddd4-41bf-b5fe-8bc5094662f31033.mspx?mfr=true.

Bindet man dann die entsprechende Applikation oder Applikationen direkt auf diese Site bzw. die DCs der Site, ist das Risiko von Problemen geringer, als wenn man die Einstellung für alle DCs setzt.

Soweit erstmal, ich gehe nun in einen ausgedehnten Urlaub. 😉

Viele Grüße, Fabian.