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: ,

How to restart graphics driver on Windows 10

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

Un shortcut de care am auzit recent si care functioneaza pe Windows 10 este LSHIFT+LCTRL+WIN+B. Se pare ca aceasta combinatie de taste initiaza restartul driverului video iar din ce am testat sistemul se comporta ca si cum ar restarta driverul video. Totusi nu exista nici o urma prin loguri despre ceea ce se intampla in spate.

Oricum merita retinut pentru situatiile in care exista o problema cu driverul video iar sistemul nu mai afiseaza nimic.

Filed in Windows Client • Tags: ,

Visual Studio for Mac

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

Cineva cred ca a facut anuntul cam devreme, pentru ca la scurt timp fusese sters. Noroc ca pagina mai exista in cache.

image

Filed in Anunturi, Diverse • Tags: ,

Forget about the old pagefile, Windows 10 memory compression is here.

By Andrei Ungureanu - Last updated: Sunday, November 13, 2016

Memory compression nu e ceva chiar atat de nou si am vazut tehnica asta folosita si in alte produse, nu numai Windows cu mult inainte de Windows 10. De fapt in Windows totul a inceput cu Windows 7 si Ready Boost. Chestia e ca tehnologia s-a maturizat si modul in care functioneaza Memory Manager-ul in Windows s-a schimbat treptat, compresia a inceput sa fie folosita din ce in ce mai agresiv, iar utilizarea page file-ului s-a diminuat semnificativ.

Tineti minte ca parca din cand in cand vine cate o versiune de Windows care ruleaza mai rapid decat vechea versiune, pe acelasi hardware? Ei bine, genul asta de optimizari fac posibila aceasta crestere de performanta. Si mi se pare foarte important sa stim cum evolueaza tehnologia si cum noile sisteme de operare folosesc resursele hardware.

Dupa cum am spus, nu este ceva nou doar ca Microsoft a implementat treptat aceasta tehnologie si parca abia acum in Windows 10 se vad cu adevarat beneficiile. Pe scurt, ce se intampla cu paginile de memorie nefolosite ce apartin unui proces? Memory Managerul face o inspectie, le trece pe un Modified List si in momentul in care are timp si resurse le trimite intr-o noua locatie numita Compression Store. Dupa cum ati ghicit, acest Compression Store se afla in memorie, deci toate operatiunile de read/write sunt incredibil de rapide. Ganditi-va ca a preluat rolul pagefile-ului, dar in RAM si pe deasupra mai este si comprimat, adica ocupa mult mai putin spatiu.

In continuare mai exista si pagefile-ul normal, si cu toata compresia din memorie se poate ajunge la situatii cand resursele sunt atat de limitate incat nu mai exista loc in RAM. In cazul asta datele din compression store pot ajunge in page file-ul de pe disk, dar tot comprimate, adica mult mai putine operatiuni de I/O cu disk-ul.

Nota: In realitate e ceva mai complicat de atat si se intampla mult mai multe lucruri, dar sper ca am reusit sa rezum esentialul (nu cred ca intereseaza pe nimeni ca pot exista mai multe compression store-uri sau ca si paginile de memorie ale compression store-ului pot ajunge in modified list).

Iar daca nu ati observat in ultimele build-uri de Windows cand va uitati in task manager gasiti si o referinta la “compressed”:

image

Deci ce vedeti ca fiind in use, reprezinta memoria folosita activ de procese si drivere, plus ce se afla in compression store. Iar daca va duceti cu mouse-ul pe zona folosita de memorie din grafic veti vedea si cat anume din acea valoare este reprezentata de compression store. Pana la anumite builduri de Windows 10, in task manager, in lista de procese exista “System and compressed memory” si toata lumea tipa ca de ce “System” ocupa atat de multa memorie si cauta moduri sa dezactiveze acest mod de operare. Ce pot sa spun? Tehnici de cartier, de aprozar, pentru cei ce nu inteleg schimbarile din noul OS. “System” parea ca ocupa atat de mult pentru ca acel Compression Store rula in contextul System Smile.

Din Windows 10 Anniversary Edition, lucrurile s-au schimbat legat de modul in care e afisata informatia in Task Manager iar datele despre Compression Store nu le mai vedeti in lista de procese. In schimb puteti rula din Powershell urmatoarea comanda:

Get-Process –Name “Memory compression”

image (1)

Normal, valoarea de aici de la Working Set (WS) trebuie sa corespunda cu ce vedeti mai sus in interfata grafica din Task Manager. Doar ca eu am rulat comanda la ceva timp dupa ce am facut screenshot-ul de mai sus si datele s-au schimbat semnificativ.

Una peste alta, toate chestiile astea combinate aduc un plus enorm de performanta sistemului si nu mai e doar marketing ci se vede in lucrul de zi cu zi cand folosesti un astfel de OS.

Daca ma intrebati de Windows Server 2016, din ce am observat eu pana acum, Memory Compression nu este folosit si nici nu am gasit nimic pana acum despre viitorul acestei functionalitati in Windows Server. Cred ca totusi este doar o problema de timp pana cand tehnologia se va roda putin si abia apoi o vom vedea la lucru si pe platformele de tip server.

Filed in Windows Client • Tags: ,

Google Cloud Platform, EC2 and Windows Server 2016

By Andrei Ungureanu - Last updated: Friday, November 4, 2016

Citisem anuntul recent al celor de la Google despre disponibilitatea Windows Server 2016 in Google Cloud Platform (GCP) si surpriza a fost sa aflu ca iti dau si 300$ trial credit sa ii cheltuiesti in primele 60 de zile. Si nu pare a fi o capcana in care iti dai cardul si dupaia te trezesti ca ai de plata cine stie ce sume:

image

Sper totusi sa se tina de cuvant.

Interfata necesita putin timp de acomodare dar nu e un show stopper.

image

image

Si pentru ca am scris in titlu si EC2, gasiti acum Windows 2016 si pe Amazon EC2:

https://aws.amazon.com/about-aws/whats-new/2016/10/amazon-ec2-now-supports-windows-server-2016/

Insa nu am auzit de nici o oferta de genul celei de mai sus.

Cred ca e un moment bun acum sa testati GCP si Windows 2016 in acelasi timp.

Filed in Windows Client • Tags: , , ,

Intro to handling errors in Powershell–default variables

By Andrei Ungureanu - Last updated: Wednesday, October 26, 2016

In majoritatea cazurilor, adminii nu prea ajung in zona de error handling, pentru ca multe din interactiunile cu Powershell se rezuma la a compune comenzi intr-o singura linie iar errorile le trateaza ad hoc.

Dar chiar si atunci e bine sa stii cate ceva despre mecanismele din Powershell care te pot ajuta. Cel mai simplu examplu ar fi cazul in care am dori sa listam toate erorile aparute in sesiunea curenta de powershell (poate ca cineva a rulat CLS pentru a-si ascunde urmele si ne lasa pe noi sa ne chinuim fara sa ne spuna rezultatul incercarilor lui).

In fiecare sesiune erorile sunt stocate automat intr-o variabila default numita $error. Ca exemplu incerc sa import un modul inexistent:

image

Pasul urmator este sa sterg consola ruland CLS. Dar ruland $error, pot vedea mesajul de eroare aparut mai devreme si orice alt mesaj de eroare aparut in sesiunea curenta:

image

$error este un array ce by default este setat sa stocheze pana la 256 de intrari. Ultima intrare in array poate fi accesata cu $error[0]:

image

Dimensiunea maxima a $error poate fi vazuta si modificata prin variabila default $MaximumErrorCount:

image

Pentru a vedea cate erori sunt stocate pentru sesiunea curenta apelam $error.count:

image

Iar pentru a sterge orice urma de erori folosim $error.clear():

image

De retinut ca este important ca la finalul unui script sa poti verifica daca au aparut erori, eventual sa le salvezi si foarte important sa stergi continutul variabilei $error, pentru ca la o executie urmatoare sa capturezi doar erorile aparute ca urmare a ultimei executii si nu tot ce aparut pana atunci.

Si tot in aceasta categorie mai exista o variabila ce trebuie retinuta si anume $LastExitCode. Aceasta variabila este importanta pentru cand apelam comenzi sau scripturi externe si stocheaza codul de erorare returnat de comanda apelata. Stim ca trebuie sa fie 0 pentru o executie cu succes. Orice e diferit de 0 poate reprezenta o problema. Nota: In propriile scripturi putem seta codul returnat la exit.

Iata de exemplu o insiruire de comenzi in care incerc sa opresc servicii folosind NET START/STOP:

image 

Observati ca la inceput variabila $lastexitcode este neinitializata, apoi ia valoarea zero iar mai tarziu se schimba in 2 cand incerc sa pornesc un serviciu inexistent.

Cam atat in acest scurt intro si sper sa va ajute si sa va dea idea despre cum puteti monitoriza si observa erorile din sesiunile sau scripturile Powershell.

Filed in Scripting • Tags: ,

Managing local accounts in Windows 2016 & Windows 10

By Andrei Ungureanu - Last updated: Sunday, October 23, 2016

Un lucru nou pe care l-am observat testand Windows 2016, au fost comenzile Powershell pentru lucrul cu conturi de useri si grupuri locale.

Daca pana acum trebuia sa facem tot felul de artificii folosind WMI sau ADSI, sau mai recent sa importam module PS custom, acum exista ceva builtin.

Ce este ciudat deocamdata, este ca eu am gasit comenzile doar pe Windows 2016 si Windows 10 Aniversary Edition (ambele cu WMF 5.1; pentru restul este inca in preview). Documentatia spune ca ar trebui sa avem comenzile by default in Powershell 5.0, insa pe un server cu Windows 2012 R2 si Powershell 5.0 instalat eu nu le-am gasit.

Ruland Get-command -Module Microsoft.PowerShell.LocalAccounts, putem obtine lista cu noile comenzi:

image

Add-LocalGroupMember
Disable-LocalUser
Enable-LocalUser
Get-LocalGroup
Get-LocalGroupMember
Get-LocalUser
New-LocalGroup
New-LocalUser
Remove-LocalGroup
Remove-LocalGroupMember
Remove-LocalUser
Rename-LocalGroup
Rename-LocalUser
Set-LocalGroup
Set-LocalUser

image

image

Din ce am testat eu pana acum, puteti face cam tot ce este disponibil si in GUI si fara prea mari batai de cap. Probabil ca era momentul pentru asa ceva pentru a mai usura lucrul cu sistemele fara GUI, mai ales ca acum avem si Nano server.

Totusi as vrea sa le vad portate si pe sistemele de operare mai vechi. Dar poate cand WMF 5.1 o sa fie disponibil in versiune finala si pentru ele.

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

Troubleshooting AD Powershell queries: server has returned the following error – invalid enumeration context

By Andrei Ungureanu - Last updated: Saturday, October 22, 2016

I’ve seen a lot on the web about the error in the title (server has returned the following error – invalid enumeration context) and the reason I am writing about this is because there is a lot of confusion about this.

You might see this error when you try to query AD from powershell (get-aduser, get-adcomputer, etc) and the query is taking a long time to finish.

+ FullyQualifiedErrorId : The server has returned the following error: invalid enumeration context.,Microsoft.ActiveDirectory.Management.Commands.GetADUser

But if you pay attention you’ll notice the error comes up exactly after 30 minutes of script execution.

Why’s that? Simple, because somewhere there’s a timeout in Active Directory Web Services.

If you’ll go and read the documentation for AD WS you’ll notice a parameter named MaxEnumContextExpiration which is set by default to 30 minutes.

From the documentation:

In ADWS, there are a number of configuration parameters that determine how ADWS in Windows Server 2008 R2 handles the traffic that administrators generate. Administrators can manage AD DS domains, AD LDS instances, and Active Directory Database Mounting Tool instances by using applications such as the Active Directory module or Active Directory Administrative Center. These configuration parameters are stored in the Microsoft.ActiveDirectory.WebServices.exe.config file, under %WINDIR%\ADWS directory.

You can adjust these configuration parameters by editing the Microsoft.ActiveDirectory.WebServices.exe.config file to accommodate traffic that is directed at the ADWS service in their Active Directory environments. Any changes that you make to the ADWS configuration parameters on a given domain controller affect only the ADWS service that is running on this particular domain controller. In other words, changes that you make to the Microsoft.ActiveDirectory.WebServices.exe.config file on a domain controller in a given domain or forest do not replicate to other domain controllers in this domain or forest.

MaxEnumContextExpiration parameter description: Specifies the maximum allowed time period during which the ADWS service processes and retrieves the results of a query request from a client computer.

I’ve seen several recommendations to change –ResultPageSize & –ResultSetSize in order to fix this error. Although by changing those might improve the performance a little bit, if the query still takes more than 30 minutes, you’ll get the same error. Those two are still important. Why? Because you’ll need to optimize your query and make it faster.

So here’s your options:

1. Try with –ResultPageSize & –ResultSetSize and see if you can make it faster.

2. Go and change Microsoft.ActiveDirectory.WebServices.exe.config and increase MaxEnumContextExpiration

3. Improve your query so it will return fewer objects so it can take less than 30 minutes. (Example: return only active objects)

4. Sometimes there’s a lot of processing time spent on the client side. Think about all the pipelines in your one liner command. Change your code to retrieve everything in a local variable in memory if possible and then query that locally.

5. Use something else than AD Powershell Cmdlets. Maybe the Quest ones or directly from .Net. And remember there’s always VBScript.

Filed in Active Directory • Tags: ,