Come vengono gestiti i cookie del server LDAP

  • Articolo

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

In LDAP alcune query generano un set di risultati di grandi dimensioni. Tali query comportano delle difficoltà in Windows Server.

Raccogliere e compilare questi set di risultati di grandi dimensioni rappresenta un impegno notevole. Molti degli attributi devono essere convertiti da una rappresentazione interna nella rappresentazione di collegamento LDAP. Per molti attributi, la conversione da un formato interno, spesso binario, deve essere eseguita in un formato UTF-8 basato su testo nel frame di risposta LDAP.

Un altro problema è costituito dal fatto che i set di risultati con decine di migliaia di oggetti richiedono spazi di archiviazione enormi, raggiungendo spesso diverse centinaia di megabyte. Perciò, richiedono inoltre molto spazio degli indirizzi virtuali. Il trasferimento in rete diventa problematico perché si perde l’intero sforzo quando la sessione TCP si interrompe durante il transito.

Questi problemi di capacità e logistica hanno spinto gli sviluppatori LDAP di Microsoft a creare un'estensione LDAP nota come "query di paging". La query di paging implementa un controllo LDAP per separare una query di grandi dimensioni in blocchi di set di risultati più piccoli. La query di paging è uno standard RFC: RFC 2696.

Il metodo query di paging usa le dimensioni di pagina impostate dal client o tramite i Criteri LDAP ("MaxPageSize"). Il client deve sempre abilitare il paging inviando un controllo LDAP.

Quando si usa una query con molti risultati, a un certo punto viene raggiunto il numero massimo di oggetti consentiti. Il server LDAP suddivide il messaggio di risposta in pacchetti e aggiunge un cookie che contiene le informazioni necessarie per continuare la ricerca.

L'applicazione client deve considerare il cookie come un BLOB opaco. Può recuperare il numero di oggetti della risposta e può continuare la ricerca in base alla presenza del cookie. Per continuare la ricerca il client invia la stessa query al server LDAP, incluso il valore del cookie della risposta precedente.

Se il numero di oggetti non riempie una pagina, la query LDAP risulterà completa e la risposta non conterrà alcun cookie di pagina. Se il server non restituisce alcun cookie, il client deve considerare la ricerca di paging completata.

Se il server restituisce un errore, il client deve considerare la ricerca di paging non riuscita. Se si riprova, la ricerca verrà riavviata dalla prima pagina.

Windows Server restituisce il cookie al client e talvolta archivia le informazioni relative al cookie sul server. Queste informazioni vengono archiviate nel server in una cache e sono soggette a determinati limiti.

In questo caso, il cookie inviato al client dal server viene usato anche dal server per cercare le informazioni presenti nella cache del server. Quando il client continua la ricerca di paging, Windows Server userà il cookie del client, nonché tutte le informazioni correlate presenti nella cache dei cookie del server per continuare la ricerca. Se per un qualsiasi motivo il server non riesce a trovare le informazioni correlate sui cookie nella cache del server, la ricerca viene interrotta e viene restituito un errore al client.

Ovviamente, il server LDAP gestisce più client alla volta. Inoltre, più client alla volta possono lanciare query che richiedono l'uso della cache dei cookie del server. Pertanto, nell'implementazione di Windows Server è previsto un monitoraggio dell'utilizzo e dei limiti del pool di cookie, per assicurarsi che il pool di cookie non stia occupando troppe risorse. Gli amministratori posso impostare i limiti usando le seguenti impostazioni nei criteri LDAP. Le impostazioni predefinite e le spiegazioni sono le seguenti.

MinResultSets: 4

Il server LDAP non considera le dimensioni massime del pool se nella cache dei cookie del server è presente un numero inferiore di voci rispetto a MinResultSets.

MaxResultSetSize: 262.144 byte

Le dimensioni totali della cache dei cookie nel server non devono superare il numero massimo di MaxResultSetSize in byte. Altrimenti, vengono eliminati i cookie meno recenti fino a quando le dimensioni in byte del pool non sono inferiori a MaxResultSetSize o nel pool non sia presente un numero di cookie inferiore a MinResultSets. Quando si usano le impostazioni predefinite, il server LDAP considera come valore ottimale un pool di 450 KB se sono archiviati solo 3 cookie.

MaxResultSetsPerConn: 10

Il server LDAP non consente un numero di cookie maggiore di MaxResultSetsPerConn per ogni connessione LDAP nel pool.

Gestione dei cookie eliminati

La rimozione delle informazioni dei cookie dalla cache del server LDAP non comporta sempre un errore immediato per le applicazioni. Le applicazioni possono riavviare la ricerca di paging dall'inizio e completarla in un altro tentativo. Alcune applicazioni presentano questo tipo di meccanismo di gestione dei tentativi per ottenere una maggiore affidabilità.

Alcune applicazioni possono eseguire una ricerca di pagina senza mai completarla. Questa ricerca non completata può lasciare voci nella cache dei cookie del server LDAP, gestite tramite il meccanismo descritto in precedenza. Tale meccanismo è importante per liberare memoria nel server per le ricerche LDAP attive.

Cosa accade quando un cookie di questo tipo viene eliminato nel server e il client continua la ricerca con questo handle di cookie? Il server LDAP non trova il cookie nella cache dei cookie del server e restituisce un errore di query. La risposta di errore è simile alla seguente:

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

Nota

Il valore esadecimale dietro "DSID" varia a seconda della versione di build dei file binari del server LDAP.

Il server LDAP ha la possibilità di registrare eventi tramite la categoria 16 Ldap Interface nella chiave di diagnostica NTDS. Se si imposta questa categoria su 2, è possibile ottenere gli eventi seguenti:

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.

Gli eventi segnalano che è stato rimosso un cookie archiviato. Questo non significa che un client ha rilevato l'errore LDAP, ma solo che il server LDAP ha raggiunto i limiti di amministrazione per la cache. In alcuni casi, è possibile che un client LDAP abbia abbandonato la ricerca di paging e quindi potrebbe non visualizzare l'errore.

Se non si sono mai verificati errori di ricerca LDAP nel dominio, potrebbe non essere necessario monitorare il pool di cookie di ricerca di pagina del server LDAP. Nel caso in cui nell'ambiente usato si verificano errori correlati alla ricerca di pagina di LDAP, si potrebbe avere un problema con i limiti di amministrazione del pool di cookie.

Gli eventi 2898 e 2899 rappresentano l'unico modo per sapere se il server LDAP ha raggiunto i limiti di amministrazione. Quando si verifica un errore di query LDAP dovuto a un errore di elaborazione dei controlli, è consigliabile aumentare i limiti per una o più impostazioni dei criteri LDAP. È possibile trovare i limiti nella sezione Come viene gestito il pool di cookie, a seconda dell'evento che si ottiene.

Se nel controller di dominio o nel server LDAP viene visualizzato l'evento 2898, è consigliabile impostare MaxResultSetsPerConn su 25. In genere non si eseguono più di 25 ricerche di paging parallele in una singola connessione LDAP. Se l'evento 2898 persiste, provare a cercare la causa dell'errore nell'applicazione client LDAP. Potrebbe essere possibile che l'applicazione rimanga in qualche modo bloccata durante il recupero di altri risultati di paging lasciando il cookie in sospeso e riavviando quindi una nuova query. Verificare se l'applicazione, a un certo punto, dispone di cookie sufficienti per i suoi scopi. È possibile anche aumentare il valore di MaxResultSetsPerConn oltre 25. Quando vengono visualizzati gli eventi 2899 registrati sui controller di dominio, il piano è diverso. Se il controller di dominio o il server LDAP viene eseguito in un computer con memoria sufficiente (diversi GB di memoria disponibile), è consigliabile impostare MaxResultsetSize su un valore maggiore di >250 MB nel server LDAP. Questo limite è sufficiente per soddisfare volumi elevati di ricerche di pagina LDAP anche in directory di dimensioni molto grandi.

Se l'evento 2899 persiste con un pool di 250 MB o più, è probabile che molti client con un numero elevato di oggetti restituiti abbiano eseguito una query con frequenza. I dati che si possono raccogliere con l’insieme agenti di raccolta dati di Active Directory consentono di trovare query di paging ripetitive che mantengono occupati i server LDAP. Tali query vengono visualizzate con un numero di "Voci restituite" che corrisponde alle dimensioni della pagina usata.

Se possibile, è consigliabile esaminare la progettazione dell'applicazione e implementare un approccio diverso con una frequenza, un volume di dati e/o un numero inferiore di istanze client che eseguono query su questi dati. Se sono presenti applicazioni per cui si ha accesso al codice sorgente, per comprendere il modo ottimale con cui queste accedono ad Active Directory, vedere Creazione di applicazioni efficienti abilitate per Active Directory.

Se non è possibile modificare il comportamento delle query, si può usare un altro approccio che consiste nell'aggiungere più istanze replicate dei contesti dei nomi necessari e ridistribuire i client. La replica dell'istanza e la distribuzione del client possono ridurre il carico sui singoli server LDAP.