Kerberos Token Bloat, Again

Am mai scris si o sa mai scriu probabil despre subiectul asta pentru ca pe masura ce trece timpul sunt sigur ca o sa vad tot mai multe astfel de cazuri (asta daca nu migreaza toata lumea pe Windows 10 si Windows 2012R2 sau mai mare).

Ca definitie, Kerberos Token Bloat se refera la scenariul cand token-ul Kerberos este prea mare, si de aici tot felul de probleme de autentificare. Pe vremuri primele simptome au fost legate de MTU si de faptul ca token-ul devenea fragmentat. Dar problema asta a fost depasita si s-a ajuns la o limitare numita MaxTokenSize ce defineste un buffer pentru tichetele Kerberos pe care le poate accepta un sistem Windows. Valoare initiala a pornit de la 8000 bytes (W2K) si a crescut la 12000 in Windows7/2008R2 iar incepand cu Windows 2012 este de 48000 bytes.

48000 este o valoare destul de mare, asa ca sistemele ce au MaxTokenSize setata asa nu vor suferi de Kerberos Token Bloat. In schimb daca inca esti pe 12000, ai sansa sa fii afectat de asa ceva. Dar hai sa vedem si cum.

Pai in ticketul ala Kerberos, o mare parte din informatie este reprezentata de acel PAC (Privilege Attribute Certificate) care ghiciti ce contine. Lista cu toate grupurile din care face parte userul (sub forma de SID bineinteles). Si nu numai grupurile ce apar in memberOf ci si “nested groups” (grupurile ce fac parte din grupurile din care face parte userul, etc), mai exact atributul tokenGroups (un atribut calculat atunci cand este accesat). Si cand sunt prea multe grupuri, automat si dimensiunea tichetului Kerberos o sa creasca.

Nota: exista o limita hardcoded de 1010 grupuri.

Iar daca se mai intampla ca obiectele din Active Directory sa mai contina si SIDHistory, automat informatia se dubleaza.

Cand banuiti o astfel de problema, puteti folosi scriptul de mai jos pentru a face o estimare a dimensiunii tokenului Kerberos pentru un anumit user:

https://gallery.technet.microsoft.com/scriptcenter/Check-for-MaxTokenSize-520e51e5

Si in functie de asta puteti sa reanalizati grupurile din care face parte userul (daca sunt nested, cateodata poate fi un chin) sau sa mariti dimensiunea MaxTokenSize.

Mai jos gasiti cateva articole foarte bune despre cum sa modificati MaxTokenSize pe diverse versiuni de Windows. Doar incepand cu Windows 2012 gasiti setarea by default in GPO:

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

http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-and-kerberos-token-bloat.aspx

Nota: Setarile astea trebuie facute pe toate sistemele ce fac parte din conversatia Kerberos (adica vor trebui aplicate si pe DC-uri, servere si statii).

Chiar si cu NTDSUTIL puteti obtine informatii utile (gen toate SID-urile din token-ul unui user):

Iata si alte cateva resurse ce pot fi de folos in astfel de situatii:

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

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

https://www.sans.org/reading-room/whitepapers/authentication/kerberos-token-size-dos-33714

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

LAPS.E

In caz ca Local Administrator Password Solution, solutia descrisa de mine aici nu va multumeste pentru ca informatia stocata in Active Directory nu este criptata, exista si un proiect open source ce vine si cu aceasta posibilitate. Solutia se numeste LAPS.E si mai multe informatii gasiti in link-urile de mai jos:

http://www.laps-e.net/index.php

https://github.com/jformacek/laps-e

https://code.msdn.microsoft.com/solution-for-management-of-ae44e789

PS: LAPS-ul oferit de Microsoft este bazat tot pe codul de mai sus. Pentru cei ce au nevoie sa ruleze CSE-ul pe XP in solutia oferita de MS, e nevoie sa il luati din varianta open source LAPS.E.

Local Administrator Password Solution aka LAPS

Eu am spus de multe ori ca cea mai buna solutie pentru protejarea conturilor locale (si de acolo a intregii infrastructuri) este parola unica pe fiecare cont local. Cu un sistem centralizat si bine securizat in care sa stochezi aceste parole, devine floare la ureche. Insa pana de curand, cam tot ce vazusem era destul de complicat, greu de folosit si foarte putina lume incerca asa ceva iar unii chiar nu auzisera.

Exista si o varianta scriptata dar si acolo foarte putini se avantau pentru ca le parea ceva destul de complicat. Asa ca stateau cu aceeasi parola pe contul de administrator si bineinteles expusi atacurilor de tip PTH.

Dar anul trecut Microsoft a pus la dispozitie un tool (LAPS) pentru gestionarea parolelor pentru contul de administrator local. Tool-ul se ocupa cu generarea parolei unice a contului de administrator pe statie si stocarea ei in Active Directory (locul unde vor fi stocate aceste parole).

Nota: LAPS era disponibil si pana acum clientilor ce aveau contracte de suport de tip Premier.

Pentru moment o sa incerc in mare sa fac un rezumat al componentelor ce fac parte din aceasta solutie pentru a fi mai usor de inteles. Solutia este baza pe pe Group Policy. Astfel fiecare computer administrat prin LAPS va avea nevoie de un nou CSE (Client Side Extension) ce se va ocupa de schimbarile de parola. Iar parolele vor fi stocate in Active Directory. Deci vom avea asa:

– un CSE ce se instaleaza pe client (este un DLL ce se va instala dintr-un MSI)

– un ADM ce va fi necesar pe statia de management pentru a administra setarile din GPO

– script pentru extinderea schemei AD ca sa poata stoca noile parole

– tooluri pentru a vizualiza parola din AD

Prima data trebuie sa downloadati solutia de aici:

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

In download gasiti urmatoarele fisiere:

 

Vom avea nevoie de un sistem de management, asa ca vom instala versiunea x64 pe sistemul nostru de management (in cazul meu este chiar un domain controller pentru ca este un mediu de test; altfel nu as recomanda).

By default, MSI-ul instaleaza doar AdmPwd GPO Extension (acel CSE sau extensie GPO de care va spuneam mai devreme). Dar pentru sistemul de management vom avea nevoie sa selectam toate componentele, exact ca mai jos:

Un nou modul powershell va fi instalat iar mai jos puteti vedea noile comenzi.

Iar una dintre ele este Update-AdmPwdADSSchema, comanda ce va face update-ul de schema cu noile atribute pentru stocarea parolei. Nu trebuie sa va mai spun ca aveti nevoie de Schema Admins ca sa efectuati acest update.

Odata ce am extins schema mai este ceva de setat legat de aceste atribute. By default userii normali din AD au dreptul sa citeasca foarte multe atribute. De aceea acum va trebui sa verificam si sa restrictionam daca este necesar accesul la aceste atribute. Accesul se va face prin “All extended rights” si avem la dispozitie chiar si un cmdlet prin care putem verifica cine are drepturi pe acest atribut pe un anumit OU:

Daca totusi avem useri sau grupuri ce nu trebuie sa aiba acces, atunci va trebui sa ne conectam cu ADSIEdit, properties pe OU, mers pe tab-ul Security, Advanced:

Selectat user/grupul, Edit si debifat “All extended rights” .

Bun, acum ca ne-am asigurat ca in afara de domain admins nu are nimeni drepturi, e timpul sa dam si cateva drepturi. Odata o sa facem un grup nou numit PasswordRecovery (puteti alege orice nume doriti) si ii vom da drepturi sa citeasca parolele folosind Set-AdmPwdReadPasswordPermission:

Nota: Putem avea grupuri diferite ce pot citi parolele de pe OU-uri diferite. De exemplu putem avea OU cu servere, unde doar anumiti admini vor avea acces la parole.

Dar pe aceste atribute si computer account-urile vor avea nevoie de drepturi ca sa poata updata parola si vom folosi Set-AdmPwdComputerSelfPermission:

Acum ca am terminat cu setat drepturile in AD, hai sa vedem cum facem deployment la acel GPO CSE pe statii. Si solutia pe care o propun acum este tot GPO. Bineinteles ca exista si alte variante, dar momentam lucram cu ce avem builtin. Deci vom face in GPO nou ce se va aplica pe OU-ul nostru cu statii (in cazul meu, acel Test1) si vom folosi functia de deploy software din Group Policy:

Selectam pe rand ambele MSI-uri ce au venit in solutie, setam ca deployment Assigned:

NOTA: Fisierele trebuie sa fie accesibile de catre statii. Eu le-am pus in NETLOGON pentru ca locatia accesibila si este replicata pe toate DC-urile.

Iar la MSI-ul pe 32 de biti trebuie sa mergem in advanced si sa debifam “Make this 32-bit X86 application available to Win64 machines” (pentru ca avem separat versiune pe 64 de biti).

Dupa ce setam politica, si cateva reboot-uri pe statii, o sa putem vedea ca LAPS s-a instalat in Programs and Features:

Iar acum ultimul pas din configurare, este setarea GPO-ului ce va trimite “instructiuni” CSE-ului de pe client. Putem face asta in acelasi GPO ce l-am folosit pentru instalarea pachetelor MSI sau in altul. In exemplul meu, o sa ma folosesc de acelasi GPO. Pe statia de management, in Administrative Templates putem vedea acum o noua rubrica, LAPS:

Urmatoarea setare o sa o las pe Not Configured, pentru ca intentia mea este sa controlez contul Administrator builtin. Acum depinde de cum gestionati statiile si daca ati facut enable la cont in imagine sau ati mers pe varianta cu un alt cont local:

Iar optiunea de mai jos se explica singura; cand CSE-ul va detecta ca parola a expirat va initia imediat schimbarea.

Si ultima optiune dar nu lipsta de importanta este “Enable local admin password management”. Fara aceasta optiune activa, CSE-ul nu va face nimic.

Dupa ce am salvat politica si a fost preluata de una din statiile pe care am instalat si CSE-ul putem vedea deja update-urile in AD. O varianta ar fi prin orice editor de atribute avem la indemana:

Nota: Password Expiration date-ul il putem converti cu w32tm /ntte:

Sau mai putem vizualiza parola si cu unul din tool-urile ce se instaleaza pe statia de management:

Sau din powershell cu Get-AdmPwdPassword:

Si gata, puteti uita de bataia de cap produsa de mentenanta conturilor locale.  GPO & AD will take care of that 🙂

Announcing SQL Server on Linux

Whaaaat? La asta chiar nu ma asteptam :).

https://www.microsoft.com/en-us/server-cloud/sql-server-on-linux.aspx

https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/

PS:Viitorul suna bine 🙂

Enable F8 Boot Menu & Safe Mode in Windows 10

In Windows 8 si Windows 10, accesarea vechiului meniu de boot ce contine printre altele si optiunea de Safe mode a devenit un cosmar. Daca incercati sa folositi F8 in procesul de boot stati linistiti ca nu merge by default.

Totusi vechea metoda cu F8 merge activata folosind BCDEDIT ca in exemplul de mai jos (cu optiunea bootmenupolicy legacy).

Dupa ce ati rulat aceasta comanda, la urmatorul boot puteti accesa meniul cu tasta F8:

Nota:Se spune ca aceasta optiune va incetini cu cateva secunde procesul de boot.

Altfel, metoda clasica in Windows 10 este de a tine apasat SHIFT in timp ce apasati pe optiunea de Restart. In felul acesta veti ajunge in ecranul de mai jos si intr-un final in ecranul cu startup settings ce va confirma ca veti ajunge in meniul Advanced Startup Settings.

PS: Windows Server functioneaza in continuare pe vechiul model si meniul de boot e accesibil cu F8 by default.

Free Ebook – Deploying Windows 10 with SCCM

How NTLM authentication works

Despre Kerberos se tot vrobeste insa sunt multe cazuri in care ne confruntam si cu NTLM iar pentru a diagnostica problemele de autentificare e bine sa intelegem si cum functioneaza.

Mai jos sunt etapele procesului de autentificare:

1. (Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographichash of the password and discards the actual password.
2. The client sends the user name to the server (in plaintext).
3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.
4. The client encrypts this challenge with the hash of the user’s password and returns the result to the server. This is called the response.

5. The server sends the following three items to the domain controller:

   • User name
   • Challenge sent to the client
   • Response received from the client
6. The domain controller uses the user name to retrieve the hash of the user’s password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

Sursa: https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx

GPO Logon Script Delay–Windows 10 update

Am scris anul trecut despre Logon Script Delay in Windows 8.1 si spre surprinderea mea lucrurile s-au schimbat in Windows 10.

Initial mi-a atras atentia un articol al lui Darren Mar-Elia insa nu am crezut pana nu am vazut cu ochii mei. Pentru ca folosind gpedit.msc pe un sistem cu Windows 10 imi spune in continuare ca by default sistemul va astepta 5 minute inainte sa inceapa sa ruleze scripturile:

Doar ca dupa cateva teste mi-am dat seama ca acel delay nu mai exista by default. In schimb, poate fi configurat prin aceasta setare din GPO.

Din nou si mai multa confuzie … tipic MS.

ASUS QM1 PC Stick–UPDATE

Dupa un interval mai lung de uitilizare am ajuns la urmatoarea concluzie. DO NOT BUY IT. Mai bine astepti ca Intel Compute Stick 2016 sa fie disponibil si in RO.

ASUS QM1 inca pastreaza toate defectele produselor anterioare (si Intel si alti producatori). In afara de problema cu WiFi-ul unde a fost nevoie sa cumpar un adaptor extern (btw: am reusit si ceva improvement cu adaptorul inclus din setarile driverului insa daca folosesti si bluetooth tot ai probleme) mai sufera si de problema cu incalzirea CPU-ului.

Simpla vizionare a unor materiale video ce duc procesorul aproape de 100% il fac sa o ia razna. Cand core-urile se apropie de 75C frecventa incepe sa fie redusa chiar si pana la 360Mhz. Iar 1.4Ghz este maxim, nici vorba de acel turbo la 1.8Ghz.

Si oricum pe incarcare maxima nu face fata decat vreo 2 minute.

Nu sunt genul care sa renunte usor, dar pana la urma suportul de la ASUS ma cam impinge sa renunt la produs. Am incercat sa fac un update de BIOS insa fara succes iar site-ul lur efectiv nu are suficiente informatii despre produs:

 

Buna ziua Domnule Andrei,

Va multumim pentru increderea acordata suportului tehnic ASUS.
Numele meu este Emanuela si voi face tot posibilul sa va fiu alaturi si sa va sprijin pe tot parcursul procedurilor cu serviciul nostru tehnic ASUS.

Va rugam sa nu ezitati sa evaluati serviciul nostru, potrivit solutiei furnizate prin chestionarul de calitate, ce urmeaza sa fie trimis catre dumneavoastra la scurt timp dupa ce primiti raspunsul la cerere.

Din pacate nu pot vedea imaginea atasata, in general nu recomandam un update de BIOS deoarece este o procedura riscanta, avand in vedere ca va aflati in primele zile de la achizitie, va recomandam sa discutati cu magazinul pentru a verifica disponibilitatea inlocuirii produsului sau returnarii banilor.

Raman la dispozitia dumneavoastra pentru orice alte nelamuriri sau intrebari suplimentare. Nu ezitati sa reveniti, puteti intra in contact din nou cu noi efectuand un reply la mailul primit.
Speram ca informatiile furnizate va vor fi de folos si va dorim o zi buna.

Cu respect,
Emanuela
Tehnician Suport Tehnic ASUS Romania

Whitepaper – Understand Microsoft Hyper Converged Solution

This whitepaper is written by Romain Serre and Charbel Nemnom which describes Microsoft Hyper-Converged solution in Windows Server 2016 using Storage Spaces Direct, Hyper-V and network technologies. The second part of this document shows an example of this implementation.

https://gallery.technet.microsoft.com/Understand-Hyper-Converged-bae286dd