Privileged Access Workstation aka PAW

By Andrei Ungureanu - Last updated: Sunday, January 15, 2017

Conceptul de Privileged Access Workstation sau Secure Admin Workstation sau PAW e ceva destul de frecvent discutat in ultimii ani si deja vad multe companii ce au inceput sa implementeze modelul.

Totusi, multe din elementele din acest subiect sunt “de bun simt” pentru un admin cu experienta. Plus ca nu sunt chestii chiar atat de noi. Conceptul de administration workstation era discutat chiar de pe vremea Windows 2000/2003. Inca mai tin minte documentatia de Securing/Design de la Windows 2003 unde era recomandat sa folosesti credentialele de administrare doar pe statii dedicate si erau detaliate pana si GPO-urile pe care sa le aplici. Deci nu e ceva chiar atat de nou, pentru cei cu vechime e chiar boring.

Dar sa incercam sa discutam putin subiectul. De ce o statie dedicata pentru administrare?

image

Pentru a diminua riscul ca un atacator sa compromita contul unui admin, printr-un cont de user normal deja compromis (exploituri web, email, executabile, keyloggers, etc).

Deci in conceptul de PAW, discutam de un sistem dedicat folosit pentru administrare. Asta inseamna ca orice persoana cu rol de admin va folosi doua sisteme pentru activitatile de zi cu zi in companie. Un sistem pentru regular tasks (web, email, office apps, LOB apps etc) si inca un sistem unde se va loga folosind credentialele de admin. Si pentru a nu fi compromise aceste credentiale, acestea nu vor avea drept de logon pe sistemele unde un user normal se poate loga (dupa cum am spus, riscul ca un user normal sa fie compromis este mult mai mare).

Separand aceste doua taskuri – admin tasks & regular user tasks, punem o bariera intre interactiunea celor doua si diminuam riscurile de escalare a privilegiilor.

Si in mare ar fi doua variante de implementare:

1. Doua statii fizice. Una pentru taskuri normale si alta pentru cele de admin. Avantajul este separarea clara intre cele doua; cele doua sisteme nu interactioneaza in nici un fel. Dezavantaje: destul de multe. Nimeni nu vrea sa foloseasca doua seturi de tastaturi si sa se mute de la un monitor la altul, sau sa care doua laptopuri dupa el.

2. Partajarea unui singur sistem folosind tehnologiile de virtualizare existente. Avantajul fiind aici in usurinta de utilizare (comparand cu primul scenariu). Dezavantaj: unii ar spune ca daca exista o vulnerabilitate in tehnologia de virtualizare, un atacator s-ar putea folosi de aceasta vulnerabilitate sa compromita intreaga statie sau sa acceseze date din partitia administrativa. Scenarii pot fi foarte multe aici, dar important este ca pana acum tehnologiile de virtualizare au fost destul de sigure si as spune ca riscul este destul de mic.

Daca pentru primul scenariu, setup-ul este simplu, doua sisteme fizice separate, in al doilea scenariu poti sa ai nenumarate variante. Nu o sa incerc sa le descriu pe toate, doar o sa va dau cateva idei si o sa mentionez regula de baza dupa care trebuie sa va ghidati cand setati acest model.

Nota: In continuare o sa denumesc statia administrativa PAW si statia userului standard UW.

Intotdeauna directia de acces trebuie sa fie dinspre PAW catre UW si nu invers. Si vad greseala asta facuta foarte des chiar acolo unde s-a incercat implementarea unui astfel de model. Daca vrei cu adevarat sa implementezi o astfel de solutie, respecta aceasta regula de baza.

 

image

Exemple de scenarii gresite:

– UW instalat direct pe hardware in care ruleaza hypervizor si un PAW VM. Admin-ul isi face taskurile normale din acest host OS, si cand vrea sa isi acceseze contul de admin, porneste PAW VM-ul si se conecteaza la el. In acest scenariu daca acel host OS este compromis, automat si PAW-ul va fi, sau credentialele administrative pentru ca sunt introduse direct de la tastatura host-ului (un keylogger in host, compromite absolut tot)

– UW instalat direct pe hardware si PAW remote (VDI, Jump server, etc). La fel ca si in primul scenariu, tot ce tastezi, trece prin UW (cu acces la internet si foarte expus). Bineinteles ca scenariul este clar mult mai bun decat daca te-ai loga pe acelasi sistem cu ambele seturi de credentiale, dar se poate si mai bine.

Exemplu de scenarii ok:

– Host OS cu hypervisor in care ai VM-uri pentru diversele roluri pe care ai. VM pentru UW si alt VM pentru PAW. Separare clara intre cele doua, nu se acceseaza unul pe celalalt. Protectia este oferita de hypervizor. OS-ul de pe host este folosit doar pentru a te conecta la VM-uri.

– PAW instalat direct pe hardware + hypervizor. UW instalat ca VM de pe PAW. Din sesiunea de logon de pe PAW se poate accesa UW. Chiar daca UW-ul este compromis, nici macar un keylogger nu poate afecta sesiunea de pe PAW. (cu toate ca acest scenariu este recomandat de MS, eu il prefer pe primul; prefer sa folosesc contul de admin numai cand este nevoie, nu sa trec prin sesiunea de admin doar ca sa ma conectez la UW).

Si de aici poti sa faci o gramada de scenarii, cu VDI, thin clients, jump servere etc. Bineinteles ca exista si alte detalii, gen hardware-ul folosit, OS, procedura de hardening, metode de enforcement pentru a limita folosirea credentialelor doar pe anumite sisteme, monitorizare. Dar subiectul este vast si am vrut doar sa punctez una dintre cele mai frecvente greseli facute.

Microsoft a facut o super treaba in ultimii ani si a publicat documentatie foarte bine pusa la punct pe aceasta tema:

https://technet.microsoft.com/windows-server-docs/security/securing-privileged-access/privileged-access-workstations

https://technet.microsoft.com/windows-server-docs/security/securing-privileged-access/securing-privileged-access-reference-material

https://msdn.microsoft.com/en-us/library/mt186538.aspx

Filed in Active Directory, Security • Tags: , ,

J5 Wormhole – un produs interesant

By Andrei Ungureanu - Last updated: Sunday, January 8, 2017

Cautand un cablu USB host to host am dat peste acest produs:

https://www.amazon.co.uk/j5Create-Wormhole-Switch-for-Windows/dp/B00AIFHW9O/ref=sr_1_3?ie=UTF8&qid=1483545966&sr=8-3&keywords=wormhole+j5

image

Se lauda ca ar permite pana si copy/paste intre sisteme si multe altele. Nu l-am testat dar din review-uri se pare ca ar functiona. Si exista si varianta pentru Mac (bineinteles mai scumpa).

http://www.j5create.com/our-products/wormhole-switches/juc400.html

Filed in Hardware Corner • Tags:

Updating Nano Server image

By Andrei Ungureanu - Last updated: Wednesday, January 4, 2017

Daca am inceput sa ma joc cu Nano server, era si timpul sa incerc sa invat cum sa il updatez. Personal mi se pare cam peste mana tot procesul si fara tooluri specializate nu cred ca se va aventura nimeni sa faca mass deployment.

Metodele de update sunt descrise aici:

https://blogs.technet.microsoft.com/nanoserver/2016/10/07/updating-nano-server/

Toate necesita Powershell si/sau DISM.

Cea mai apropiata de modul actual de lucru cu Windows Server mi s-a parut varianta cu Windows Update (dar tot via Powershell):

 

$ci = New-CimInstance -Namespace root/Microsoft/Windows/WindowsUpdate -ClassName MSFT_WUOperationsSession$result = $ci | Invoke-CimMethod -MethodName ScanForUpdates -Arguments @{SearchCriteria="IsInstalled=1";OnlineScan=$true} $result.Updates

Filed in Windows Server • Tags:

Connecting to standalone/workgroup Nano server

By Andrei Ungureanu - Last updated: Tuesday, January 3, 2017

Pe masura ce invat despre Nano server incep sa imi dau seama ca Microsoft trebuie sa faca ceva neaparat pentru ca totul pare a fi ceva gen work in progres. Sau poate nu mai am eu rabdare sa citesc toata documentatia si sa fac totul perfect din prima incercare.

Am ajuns in punctul in care l-am instalat iar acum vine intrebarea: cum ne conectam la el prin Powershell? Nefiind in domeniu, IP-ul va trebui sa fie adaugat pe lista de TrustedHosts din Winrm.

Dar inainte de asta va trebui sa porniti si sa configurati serviciul WinRM pe statia locala. Cel mai simplu este sa folositi WINRM QUICKCONFIG:

image

Abia acum putem adauga IP-ul serverului remote in lista TrustedHosts:

set-item wsman:\localhost\client\trustedhosts ‘192.168.111.41’ -force

image

Iar acum putem sa folosim powershell remoting ca sa ne conectam la Nano Server:

Enter-PSSession -ComputerName 192.168.111.41 -credential (Get-Credential)

image

Filed in Windows Server • Tags:

Nano Server Image Builder

By Andrei Ungureanu - Last updated: Tuesday, January 3, 2017

A venit timpul sa ma joc si eu putin cu Nano server. Cu toate ca pe zona mea de lucru nu prea am vazut cerere pentru asa ceva, totusi am zis ca e bine sa fii cu un pas in fata.

Iar ca sa incepi cu Nano server, trebuie sa creezi imaginea. Si cu toate ca Microsoft impinge din ce in ce mai mult lucrul in command line, era nevoie de o interfata grafica. Se numeste Nano Server Image Builder si se poate downloada din link-ul de mai jos:

https://www.microsoft.com/en-us/download/details.aspx?id=54065

Ca sa functioneze aveti nevoie si de Windows Assesment and Deployment Kit:

https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit

Odata instalat, crearea unei imagini este destul de simpla.

image

Sunt doua optiuni de baza in pagina de start. Crearea unei imagini VHD/VHDX sau deploymentul unei astfel de imagini pe un stick USB (pentru a fi folosita mai departe pentru instalarea pe un alt sistem).

Nota: Exista si optiunea de a crea un ISO de instalare dar mi se pare amuzant modul in care a fost implementat. In loc sa permita direct exportul intr-un format ISO gata de instalare, va trebui sa faci un VHD/VHDX, dupa care sa faci din el un USB bootabil, iar mai apoi sa transformi continutul de pe acel USB in ISO.

image

Majoritatea optiunilor sunt simplu de inteles asa ca nu voi sta sa le mai explic in detaliu.

image

image

Atentie la maximum size extension. Eu am incercat cu 0.5 si am adaugat rolul de Hyper-V & File Storage, iar procesul a dat eroare din lipsa de spatiu.

 

image

image

image

Driverele pentru Nano server trebuie sa le adaugati din procesul de build, altfel va fi un cosmar. Dar daca folositi masini virtuale pe Hyper-V, atunci ar trebui sa fie simplu si sa nu aveti nevoie de nimic in plus.

image

Partea de domain join merita discutata intr-un articol separat. Deocamdata pentru teste eu am ales varianta standalone.

image

image

image

image

image

Si cam atat pentru a crea un VHD/VHDX cu Nano server. Ce faci dupa cu aceasta imagine, este cu totul alta poveste.

Pentru curiosi pun si cateva screenshoturi din partea de USB & ISO creation:

image

Iar cu ISO-ul obtinut se poate instala imaginea pe un alt sistem (fizic sau virtual).

image

Oricare din variante le-am alege, ISO,USB sau VHDX, in final trebuie sa reusim sa bootam si sa obtinem promptul de mai jos:

image

image

Pare complicat tot procesul la inceput; dar pe masura ce va jucati cu procesul de instalare, o sa inceapa sa para mai simplu.

Filed in Windows Server • Tags:

Windows 10 – WiFi Random Hardware Addresses

By Andrei Ungureanu - Last updated: Tuesday, December 6, 2016

In Windows 10 tocmai am observat o noua optiune ce tine de privacy & security. Si anume Random Hardware Addresses.

Atentie ca aceasta optiune apare doar pe placile de retea WiFi suportate ce au aceasta functionalitate in driver:

image

In teorie, cineva ar putea sa urmareasca miscarile unui device pe baza adresei MAC. Dar daca device-ul schimba adresa MAC de fiecare data cand acceseaza o retea WiFi noua, atunci am scoate din ecuatie aceasta problema.

Odata conectat la o retea WiFi, sistemul de operara va tine minte adresa folosita si o va folosi si la urmatoarele conectari (util atunci cand accesul se face si pe baza adresei MAC).

Mai multe detalii puteti gasi in link-urile de mai jos:

https://support.microsoft.com/en-us/instantanswers/dd1d98f6-7253-9b21-2b7e-06aa6063dc9b/how-and-why-to-use-random-hardware-addresses

http://www.mathyvanhoef.com/2016/03/how-mac-address-randomization-works-on.html

https://www.ietf.org/proceedings/93/slides/slides-93-intarea-5.pdf

Filed in Windows Client • Tags:

Quest Migration Manager for AD – SIDHistory Mapping

By Andrei Ungureanu - Last updated: Monday, December 5, 2016

O situatie intalnita cateodata in scenariile de migrare de Active Directory este atunci cand din diverse motive proiectul a fost intrerupt iar software-ul folosit pentru a migra obiectele din AD nu mai exista.

Cum continuam migrarea? Daca ar fi vorba doar de migrat obiecte din AD ar fi simplu, dar ce facem atunci cand migram servere si statii de lucru, unde trebuie sa procesam ACL-urile?

In mare, in procesul de migrare, cand un obiect este migrat din domeniul sursa in domeniul target, undeva intr-o baza de date a soft-ului de migrare se stocheaza informatii ce leaga obiectul din sursa de obiectul din target. Un exemplu foarte simplu ar fi ceva gen: SID-ul X din Domeniul A corespunde cu SID-ul Y din Domeniul B. Iar in momenul in care ne apucam sa procesam un server sau o statie de lucru softul de migrare o sa inlocuiasca SID-ul X cu SID-ul Y. Asta asa in mare.

Dar ce faci cand baza aia de date cu informatiile astea de matching nu mai exista?

Singura solutie pe care o cunosc este prin a folosi Quest Migration Manager for AD. Si functioneaza chiar si daca prima parte a migrarii a fost facut cu un alt software, chiar si ADMT. Conditia este sa se fi folosit SID History in migrare (si de regula este folosit).

Agentul folosit de Quest pentru a procesa ACL-urile de pe sisteme se numeste Vmover si este parte a RUM (Resource Update Manager). Acesta foloseste un mapping file (vmover.ini) ce contine SID-urile sursa si target. Cand agentul intalneste un ACE cu un user din sursa intr-un ACL, il modifica pe baza informatiilor din acel mapping file cu userul din domeniul target.

In cazul nostru, fisierul vmover.ini generat nu va avea informatiile necesare pentru translatarea permisiunilor, dar folosind optiunea SIDHistory Mapping, putem spune agentului sa caute informatiile necesare in domeniul target.

In fisierul vmover.ini se afla si cateva informatii de configurare. Acolo va trebui specificat SIDHistory=Yes si detaliile de conectare la DC exact ca in articolul de mai jos:

http://documents.software.dell.com/migration-manager-for-ad/8.10/resource-processing-guide/command-line-resource-update/sidhistory-mapping

Odata setata aceasta optiune, cand Vmover va intalni un user din domeniul sursa setat pe o resursa, ii va obtine SID-ul, se va conecta la domeniul target, va cauta prin toate valorile SID History si asa va localiza userul din domeniul target ce corespunde cu userul din domeniul sursa. Informatia asta va fi adaugata in fisierul vmover.ini, astfel ca data urmatoare cand intalneste acest user intr-un ACL, procesul de translatare va fi super rapid.

Alte cateva resurse pe aceasta tema gasiti in link-urile de mai jos:

https://support.software.dell.com/migration-manager-for-ad/kb/85365

http://documents.software.dell.com/migration-manager-for-ad/8.10/resource-processing-guide/command-line-resource-update/sidhistory-mapping

https://documents.software.dell.com/snippets/PrintableVersion.ashx?id=1027

Filed in Active Directory • Tags: , ,

How to purge Kerberos tickets for a different session using KLIST

By Andrei Ungureanu - Last updated: Sunday, December 4, 2016

Cam orice admin cu experienta ar trebui sa stie cum functioneaza Kerberos si de existenta utilitarului KLIST. In ultimele versiuni de Windows nu mai trebuie instalat nimic, este deja livrat cu sistemul de operare. Pentru cei ce nu sunt familiari, o sa amintesc scenariul clasic in care adaugi un user intr-un grup ce ii da acces la o resursa (sa zicem file share), dar accesul nu functioneaza decat daca userul face logoff/logon. Iar asta se intampla pentru ca in ticketul Kerberos nu exista si SID-ul noului grup, asta fiind motivul pentru logoff/logon (refresh). Asta asa foarte pe scurt si fara prea multe detalii tehnice.

Sa revenim la KLIST. Cu acest tool puteti face refresh la ticketele TGT/TGS si astfel sa updatati group membershipul in timp real fara a mai fi nevoie de logoff/logon. Ca o nota separata, refresh-ul la ticketele Kerberos nu rezolva toate probleme de acces, dar in multe cazuri se pare ca functioneaza. Documentatia oficiala a tool-ului o gasiti aici:

https://technet.microsoft.com/da-dk/windows-server-docs/management/windows-commands/klist

In documentatie si mai peste tot pe internet este prezentat cazul in care faci renew la sesiunea curenta sau la computer account-ul local. Dar sunt scenarii in care ai nevoie sa faci refresh la cache-ul unui serviciu sau al unui alt cont logat pe sistem.

Pentru contul curent comanda este:

klist purge

Iar pentru local system account:

klist –li 0:0x3e7 purge

Ambele comenzi trebuiesc rulate dintr-un shell elevat. 0x3e7 reprezinta ID-ul contului localsystem. Pentru a face refresh la alte conturi, trebuie sa aflam ID-ul.

Incepand cu Windows 2012/8 puteti afla ID-ul tot cu KLIST:

klist sessions

image

Mai departe puteti accesa o alta sesiune folosind ID-ul, ca in exemplul de mai jos:

image

In caz ca rulati pe ceva mai vechi de Windows 2012/8 va fi nevoie de powershell si WMI. Ca sa nu mai reinventez roata, exista deja comanda in Powershell aici:

https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=56

gwmi Win32_LogonSession | % { $one = $_ ; $one.GetRelated(‘Win32_Account’) | Select Domain, Name, SID, @{ n = ‘LogonSessionHEX’ ; e = { ‘0x{0:X}’ -f ([int] $one.LogonId) } }, @{ n = ‘LogonSessionDEC’ ; e = { $one.LogonId } } , @{ n = ‘LogonType’ ; e = { $one.LogonType } } }

Output-ul arata ceva de genul asta:

image

Mai departe puteti filtra dupa o sesiune a unui anume user, sau dupa tipul sesiunii, folosind LogonType. Pe acestea le gasiti explicate aici: http://www.windowsecurity.com/articles-tutorials/misc_network_security/Logon-Types.html

De exemplu sesiunile RDP vor avea Logon Type 10 si serviciile vor avea Logon Type 5. Pentru a filtra dupa tipul sesiunii adaugati urmatoarele la comanda de mai sus: |? {$_.LogonType -eq 10}

image

Sau |? {$_.LogonType -eq 10} daca ne uitam dupa servicii:

image

Sau folosind |? {$_.Name -eq "aungureanu"} putem filtra dupa numele user-ului. Inlocuiti aungureanu din exemplul meu cu numele user-ului dorit:

image

Nota: in exemplul de mai sus puteti vedea doua sesiuni de acelasi tip (RDP) pentru acelasi user. Asta se intampla datorita UAC; fiecare user are doua tickete, unul limitat si altul elevat. Cu exceptia administratorului builtin care by default primeste doar un token elevat.

Tineti minte: KLIST si refreshul la ticketele Kerberos nu rezolva toate problemele de autentificare. Tot Logoff/Logon este recomandat. KLIST este doar un workaround pentru situatii urgente.

Filed in Active Directory, Windows Server • Tags: , ,

Auditing Special Groups in Windows

By Andrei Ungureanu - Last updated: Tuesday, November 22, 2016

Special Groups este o functionalitate prezenta in Windows incepand cu 2008/Vista si de care am uitat sa scriu pana acum. Dar nevoia m-a facut sa ajung sa folosesc asa ceva recent, asa ca a fost nevoie sa imi amintesc.

Ca sa fac un rezumat al functionalitatii. Special Groups iti ofera posibilitatea de a detecta cand membrii unui anumit grup se logheaza si unde. Nu exista un grup anume, numit Special Groups. Tu definesti ce si unde auditezi. Pasii necesari ca sa faci asta:

1. Audit Logon/Logoff Special Logon – by default activat incepand cu Windows Server 2008/Vista

2. Un grup in care sa adaugi userii pe care vrei sa ii monitorizezi (poate fi grup din Active Directory sau local)

3. SID-ul grupului respectiv adaugat in registry pe masinile ce vor fi monitorizate, in urmatoarea locatie:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Audit\SpecialGroups

image

Nota: In exemplul de mai sus am adaugat SID-ul grupului Administrators (este un SID Well Known – adica e acelasi pe orice sistem)

Nota 2: Mai multe SID-uri pot fi adaugate, delimitate prin ;

Odata configurat, data viitoare cand un user ce face parte din grupul cu SID-ul adaugat in registry se va loga pe sistemul respectiv, Event ID 4964 va fi logat in Security Log:

image

Va las pe voi sa va ganditi cum faceti deployment la setarile in registry si ce grupuri sa monitorizati dar va dau si cateva example de scenarii cand puteti folosi Special Groups:

– detectarea conturilor de Domain sau Enterprise Admin ce se logheaza acolo unde nu ar trebui. De exemplu pe enduser workstations. Puteti seta monitorizarea special groups pe statiile de lucru, ori adaugand SID-ul acestor grupuri in registry pe statii, ori adaugand userii DA/EA intr-un grup special definit pentru monitorizare.

– detectarea cazurilor cand cineva se logheaza ca Admin local pe anumite statii sau servere

– identificarea masinilor unde anumite service accounts sunt folosite (in multe cazuri am vazut service accounturi lasate active doar pentru ca nimeni nu mai stie unde sunt folosite)

 

Dar bineinteles ca toate scenariile de mai sus necesita si un sistem bine pus la punct de colectare a logurilor de pe sistemele respective. Da, chiar si de pe statii. Nu mai este ceva anormal in ultimul timp.

 

Mai jos aveti si link-ul catre KB-ul oficial cu descrierea Special Groups:

https://support.microsoft.com/en-us/kb/947223

Filed in Active Directory, Windows Client, Windows Server • Tags:

Again about troubleshooting AD Powershell queries – This operation returned because the timeout period expired,Microsoft.ActiveDirectory.Management.Commands.GetADUser

By Andrei Ungureanu - Last updated: Saturday, November 19, 2016

I was previously writing about some timeouts when getting data from Active Directory using Powershell cmdlets. Another thing that usually pops up when dealing with large amounts of data in AD is a default timeout of 2 minutes for each page search. This means that the time spend by the server to retrieve a page of results can’t take longer than 2 minutes. So in order to get rid of this error you’ll probably need to adjust the page size using the ResultPageSize parameter. Set that to a lower value so that the server can fill up a page and return it to you faster. Another way will be to improve your filter or target specific objects or OUs so that the amount of data searched is smaller.

The Powershell help also have some good comments about this:

  Timeout Behavior
    The following statements specify timeout conditions within the Active
    Directory module and describe what can be done about a timeout them.

    The default Active Directory module timeout for all operations is 2
    minutes.

    For search operation, the Active Directory module uses paging control
    with a 2-minute timeout for each page search.

    Note: Because a search may involve multiple server page requests the
    overall search time may exceed 2 minutes.

    A TimeoutException error indicates that a timeout has occurred.

    For a search operation, you can choose to use a smaller page size, set
    with the ResultPageSize parameter, if you are getting a TimeoutException
    error.

    If after trying these changes you are still getting a TimeoutException
    error, consider optimizing your filter using the guidance in the
    Optimizing Filters section of this topic.


  Optimizing Filters
    You can enhance the search filter behavior by using these guidelines.

    Avoid using the Recursive parameter as it intensifies resource usage of
    the search operation.

    Avoid using bitwise AND operators and bitwise OR operators. For more
    information, see the Supported Operators section of this topic.

    Avoid using the logical NOT operator.

    Break down your search into multiple queries with narrower conditions.
https://technet.microsoft.com/en-us/library/hh531527(v=ws.10).aspx
Also check the ADWS docs on how to change the MaxPullTimeout timeout value:

Specifies the maximum allowed time-out value that a client computer can set when it retrieves one page of search results. Set this parameter to a higher value if slow wide area network (WAN) traffic results in a time-out value for returning one page of search results that is longer than two minutes

noteNote

The ADWS service processes search requests from client computers in the following manner:

A client submits a search request.

The ADWS service establishes a search context and returns a search context ID to the client computer.

Using this search context ID, the client computer issues a page request to extract the search results specifying how many LDAP objects can be returned per page.

MaxPullTimeout controls the maximum amount of time a client can ask the ADWS service to spend retrieving a page of results, while MaxEnumContextExpiration is the maximum time that the search context can be kept open.

https://technet.microsoft.com/en-us/library/dd391908(v=ws.10).aspx

And if you still don’t understand what a “page” is, here’s the MSDN documentation:

https://msdn.microsoft.com/en-us/library/aa367011(v=vs.85).aspx

Hope this makes everything clear and some of you will be able to fix their problematic queries.

Filed in Active Directory, Scripting • Tags: ,