Veeam Backup Free Edition & Veeam Explorer for Active Directory

By Andrei Ungureanu - Last updated: Wednesday, March 22, 2017

Veeam Backup and Replication s-a ridicat foarte mult in ultimul timp, in special pentru suportul platformelor de virtualizare si usurintei in utilizare fata de vechile produse de pe piata. Mai putin cunoscuta este versiunea free (si nu FastSCP, ci Veeam Backup and Replication, care include si suport pentru SCP si multe altele).

Eu acum o sa ma refer la un tool ce se instaleaza odata cu Veeam Backup and Replication si se numeste Veeam Explorer for Active Directory. Tool-ul va poate ajuta sa faceti recover la obiectele din AD chiar si atunci cand AD Recycle Bin nu este activat sau cand nu aveti un system state backup ci doar o copie a NTDS.DIT.

O sa incep prin a urma procesul de instalare care este banal. Cat timp nu introduci licenta, produsul functioneaza in modul free.

image

image

image

image

image

image

Odata instalat puteti porni consola principala. Nu sunt multe de vazut aici, existand destul de multe limitari in varianta free.

image

image

Link-urile catre tool-urile free le gasiti si in Program Files:

image

Si sa presupunem acum ca vrem sa restauram ceva dintr-o copie mai veche a unui NTDS.DIT. Putem folosi consola principala pentru a localiza fisierul sau direct Veeam Explorer for Microsoft Active Directory.

image

image

Dupa ce selectati Recover, o sa puteti sa faceti browse in copia AD offline, exact ca si cum ati utiliza ADUC:

image

Daca selectam optiunea advanced vom avea acces si la zonele DNS stocate in AD si la Configuration Partition. Deci vom putea restaura inclusiv inregistrari DNS.

image

image

Right click pe un obiect din lista si urmatoarele optiuni apar:

image

Compare va poate ajuta sa vedeti diferentele intre copia offline si online.

image

Din acelasi meniu se poate face si restore sau export in LDF.

PS: Acelasi procedeu se poate folosi pentru a restaura un intreg OU (mai putin optiunea compare).

Un ghid complet al versiunii free gasiti in link-ul de mai jos.

https://www.veeam.com/pdf/guide/veeam_backup_free_9_5_user_guide_en.pdf

Filed in Active Directory • Tags: , ,

Emulate NET VIEW behaviour from Powershell

By Andrei Ungureanu - Last updated: Tuesday, February 14, 2017

Am fost pus de multe ori in situatia in care am avut nevoie sa listez share-uri de pe un sistem remote folosind un script, si cu toate ca un simplu utilizator poate face asta foarte simplu din Windows Explorer, din linie de comanda sunt foarte putine optiuni.

Una dintre ele ar fi folosind NET VIEW. Cu NET VIEW poti lista foarte usor share-urile de pe o masina remote, si nici nu iti trebuie drepturi deosebite.

Problema cu NET VIEW este ca output-ul este text, intr-un format ce este greu de manipulat. Desigur ca poti face un parser peste acest output si sa scoti de acolo doar ce este necesar.

Am incercat varianta cu Powershell si ma gandeam ca ar fi destul de simplu. Dar nu este. In Powershell singurele moduri de a executa acest task sunt via WMI. Adica te conectezi la masina remote si interoghezi namespace-ul WMI. Doar ca pentru asta iti trebuie drepturi de admin pe masina remote.

O varianta gasita aici ar fi fost folosind ADSI cu providerul WinNT:

([adsi]"WinNT://$computername/LanmanServer,FileService").Children | Select-Object @(
  @{n='CurrentUserCount';e={$_.CurrentUserCount}}
  @{n='Name';            e={$_.Name.Value}}
  @{n='Server';          e={$_.HostComputer | Split-Path -Leaf}}
  @{n='Path';            e={$_.Path.Value}}
  @{n='Description';     e={$_.Description.Value}}
)

Mai multe detalii pe tema asta gasiti si in urmatoarele link-uri:

http://etutorials.org/Server+Administration/Active+directory/Part+III+Scripting+Active+Directory+with+ADSI+ADO+and+WMI/Chapter+22.+Manipulating+Persistent+and+Dynamic+Objects/22.3+Enumerating+Sessions+and+Resources/

http://etutorials.org/Server+Administration/Active+directory/Part+III+Scripting+Active+Directory+with+ADSI+ADO+and+WMI/Chapter+22.+Manipulating+Persistent+and+Dynamic+Objects/22.2+Creating+and+Manipulating+Shares+with+ADSI/

https://books.google.ro/books?id=4bFX1kwEf9cC&pg=PA250&lpg=PA250&dq=adsi+winnt+lanmanserver&source=bl&ots=pDuNJVlzhp&sig=q3ZAmhvn9jf6xsdvlmJBZgr7-Nk&hl=en&sa=X&ved=0ahUKEwi-vebPgZDSAhXGFywKHdkxDHkQ6AEIQzAG#v=onepage&q=adsi%20winnt%20lanmanserver&f=false

Dar am cautat o alta varianta, pentru ca doream sa emulez exact ceea ce face NET VIEW pentru a putea interactiona si cu sisteme non windows dar care partajeaza resurse prin CIFS.

Si am gasit pana la urma solutia intr-un proiect pe GitHub ce emuleaza comenzile NET * si foloseste API-urile WIN32 via Powershell. Proiectul foloseste destul de mult cod de pe ExploitMonday si poate parea dubios, dar este proiect ce ofera tool-uri in special pentru zona de PenTest.

https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1

Iar in acest modul powershell gasiti si functia Get-NetShare.

image

Vechiul proiect il gasiti aici:

https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerView 

Si alte cateva link-uri cu informatii ajutatoare:

http://www.exploit-monday.com/2012/05/accessing-native-windows-api-in.html

https://www.veil-framework.com/veil-powerview-usage-guide/

Nu este nevoie sa importati toate functiile de acolo. Cu putina munca, puteti gasi dependintele si pastra doar functiile de care aveti nevoie (pastrati totusi Get-DelegateType si Get-ProcAddress; sunt necesare ca sa puteti lucra cu Win32 API).

Filed in Scripting • Tags: , , ,

Optimizing Powershell functions by using a filter function

By Andrei Ungureanu - Last updated: Wednesday, February 1, 2017

Cred ca cel mai bine ar fi sa incep explicand cum preia o functie input-ul ce vine prin pipeline.

In mod normal o functie in powershell poate sa preia input din pipeline folosind variabila $Input.

image

Si daca trimitem ceva prin pipeline catre functie iata ce obtinem:

image

Pare normal, nu-i asa? Dar iata ce se intampla cu adevarat in spate. Functia noastra asteapta pana intreg continutul array-ului ce vine prin pipeline este stocat in variabila $Input si abia apoi functia isi continua executia. Daca am dori ca in codul functiei sa prelucram continutul ce vine prin pipeline, ar trebui sa folosim o structura de tip ForEach si sa trecem prin toate obiectele din variabila $Input. Ceva ca in exemplul de mai jos:

image

Nota:Bineinteles ca rezultatul va fi identic cu cel din primul exemplu pentru ca doar am enumerat obiectele.

Va intrebati de ce nu folosesc $_ ca sa acceses obiectul curent din pipeline. Pentru ca nu este definit cand folosesc acest model si am zis si mai sus in ce moment se incepe executia functiei.

Dar daca vom defini functia ca un filtru si anume asa:

image

Scapam de ForEach si putem accesa variabila $_. Si mai mult de atat, in cazul in care avem un volum mare de obiecte ce vine prin pipeline, functia le va prelua pe rand si nu va trebui sa astepte pana cand toate vor fi stocate in $input.

Si acum ca stiti la ce foloseste Filter in powershell, va doresc Happy Scripting!

 

PS: Puteti folosi si definitia Function si sa accesati $_, dar folosing blocul Process:

image

E un topic mai advanced cand vine vorba de functii, asa ca prefer sa folosesc in continuare Filter.

Filed in Scripting • Tags: , ,

Azure AD Connect – Single Sign On (SSO)

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

Am scris prin Ianuarie despre noi functionalitati in AD Connect. Si mai exact am scris despre Azure AD Pass Through Authentication. Dar mai este ceva nou in AD Connect. Si anume optiunea de SSO in cloud ce poate functiona chiar si impreuna cu Pass-through Authentication, fara a mai fi nevoie de ADFS sau alte componente; doar AD Connect.

image

Ca si mentiune, aceasta optiune de SSO functioneaza pentru clientii ce sunt joinati in domeniul AD on premises si pot contacta un domain controller (poate fi chiar si via VPN).

Iata cerintele aici:

SSO is a feature that is enabled through Azure AD Connect and works with password sync or Pass-through authentication and your on-premises Active Directory. For your end users to use single sign-on in your environment, you need to ensure that users are:+

If any of these requirements are not present, such as the machine is off the corporate network, then the user is prompted to enter their password as they would without single sign-on.

Nota: Trebuie sa mentionez ca SSO din Edge nu merge deocamdata. Poate pe viitor. In schimb mie mi-a functionat din Chrome si IE.

Imaginea din documentatia de aici cu modul de autentificare arata cam asa:

image

In principiu este Integrated Windows Authentication (IWA) si Kerberos, folosind si acel computer account creat de AD Connect (AZUREADSSOACCT).

image

Clientul va discuta cu DC-ul local, ce va incripta un ticket cu informatiile din computer accountul AZUREADSSOACCT ce va fi mai apoi decriptat in Azure.

image

Iata si toti pasii pe care ii parcurge clientul:

    1. Azure AD challenges the client, via a 401 Unauthorized response, to provide a Kerberos ticket.
    2. The client requests a ticket from Active Directory for Azure AD.
    3. Active Directory locates the machine account, created by Azure AD Connect, and returns a Kerberos ticket to the client encrypted with the machine account’s secret. The ticket includes the identity of the user currently signed in to the computer.
    4. The client sends the Kerberos ticket it acquired from Active Directory to Azure AD.
    5. Azure AD decrypts the Kerberos ticket using the previously shared key. Then it either returns a token to the user or asks the user to provide additional proofs such as multi-factor authentication as required by the resource.

Cerintele sunt putin diferite pe partea de networking daca folositi Password Sync. Daca folositi Pass-through, nu mai este nevoie de nimic suplimentar.

If you are enabling ‘Single Sign On’ with ‘Password Sync’, and if there is a firewall between Azure AD Connect and Azure AD, make sure that:

Protocol
Port Number
Description

HTTPS
9090
Enable SSO registration (required only for the SSO registration process).

In afara de asta mai e nevoie de inca o configurare pe statii (ce se poate face prin GPO) ce va permite browserului sa trimita ticketul Kerberos catre Azure (si anume sa fie adaugate in intranet zone). Site-urile necesare sunt:

https://autologon.microsoftazuread-sso.com
https://aadg.windows.net.nsatc.net

Puteti folosi Site to Zone Assignment List aflat in User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page:

image

image

Gasiti toate detaliile necesare in documentatia oficiala:

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso

Si tineti minte, nu merge cu Edge deocamdata.

Filed in Active Directory • Tags: ,

Windows Management Framework (WMF) 5.1 Released

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

WMF 5.1 este disponibil la download in versiunea finala. Asta inseamna ca puteti upgrada clientii vechi (W2012/W8.1/W2008R2/W7) la aceeasi versiune de Powersehll/WMI/WinRM ca si Windows Server 2016 si Windows 10 Anniversary Edition. In felul acesta puteti avea un baseline in intreaga infrastructura:

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

Totusi instalarea nu este chiar asa directa pentru W2K8R2 si W7 (recomandat ca WMF 3.0 sa fie dezinstalat) asa ca va sugerez sa cititi cu atentie release notes:

https://msdn.microsoft.com/en-us/powershell/wmf/5.1/install-configure

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

Azure AD Pass Through Authentication

By Andrei Ungureanu - Last updated: Friday, January 20, 2017

Inca in preview dar cu potential mare de a intra in infrastructurile mici si medii este Azure AD Pass Through Authentication. Initial mi s-a parut greu de inteles conceptul, pentru ca era prea simplu. Daca pana acum metodele de autentificare si integrare cu Azure si Office 365 erau password synchronization si ADFS, in curand (pentru ca inca este preview) o sa avem si pass through. O sa va intrebati, ce era rau cu celelalte doua metode de autentificare si pana la urma si pass-through authentication face acelasi lucru. O sa va explic si care este diferenta si cu ce vine in plus aceasta noua metoda de autentificare:

1. Parolele nu parasesc on premises. Pentru cei care aveau astfel de griji, trebuiau sa recurga la ADFS.

2. ADFS pare complicat de configurat si cateodata chiar este. Ai nevoie de certificate si endpointuri deschise in internet din infrastructura locala. Cu pass-through nici macar nu trebuie sa deschizi porturi inbound in infrastructura ta. Tot ce trebuie sa ai este conectivitate outbound de pe sistemele ce ruleaza AD Connect. Nimic altceva de setat, nu certificate, nu porturi de retea deschise catre interior.

Tot ce trebuie facut este sa instalati si sa setati AD Connect:

image

Si bineinteles sa activati sincronizarea pentru userii ce se vor autentifica la Azure.

image

In continuare procesul este foarte simplu. Connectorul va deschide o conexiune outbound catre Azure si va verifica in permananta o coada de autentificare. In momentul in care un request de autentificare vine din cloud, acesta va fi pus in coada, conectorul va prelua cererea de autentificare de acolo, o va valida si va treimite raspunsul inapoi in cloud.

Mai jos este o imagine preluata din documentatia de pe Technet insa cum mie mi s-a parut confuza m-am gandit sa explic procesul.

Pass-through Authentication

Masina ce va rula AD Connect trebuie sa ruleze Windows Server 2012 R2 sau mai mare si sa fie joinata la domeniul AD in care se va face autentificarea.

Pentru redundanta se pot instala mai multe instante de AD Connect. Procedura este descrisa in documentatia de aici:

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication

Tot aici gasiti si porturile de retea necesare pentru conexiunile outbound (in caz ca sunt filtrate).

Personal consider ca AD pass-through authentication este o solutie binevenita pentru cei ce nu au impementat inca ADFS si care vor sa simplifice configuratia pe zona de autentificare. Nu este un inlocuitor 100% pentru ADFS, asa ca daca veti avea nevoie sa faceti claim based SSO cu third party, atunci tot la ADFS ajungeti. Dar pentru cei ce au nevoie de autentificare doar cu Azure, atunci mi se pare super.

Filed in Active Directory, Windows Azure • Tags: ,

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: