Set DNS resolvers via Powershell & WMI
Ca tot am discutat despre cum sa obtinem lista de servere DNS setate, acum a venit timpul sa vedem cum putem sa modificam informatia asta.
Incepem tot printr-o conexiune WMI:
$ipconfig = GWMI –class win32_networkadapterconfiguration –computer “computername” –filter “ipenabled = $true”
Si ne pregatim un array cu noile setari:
$dnsarray = @("192.168.111.8","10.0.0.101")
Iar mai departe folosim metoda SetDNSServerSearchOrder():
$ipconfig.SetDNSServerSearchOrder($dnsarray)
Atentie la ReturnValue. Trebuie sa fie 0, altfel ceva nu a mers cum trebuie.
Si daca in articolul precedent am scris si despre noile cmdlet-uri din Windows 8 si 2012 o sa prezint si varianta asta.
Cmdlet-ul ce trebuie folosit este SetDNSClientServerAddress:
SetDNSClientServerAddress –cimsession “computername” –interfacealias “Ethernet” –serveraddress (“x.x.x.x”, “y.y.y.y”)
Prin exemplul asta atrag si atentia asupra importantei denumirii adaptoarelor de retea. E bine ca acestea sa fie standardizate pe toate serverele pentru a putea automatiza taskuri ce implica un numar mare de servere. Cand toate serverele au adaptorul principal (de pe care pleaca si queryurile de DNS) denumit sa zicem LAN1, atunci va fi foarte usor sa scrii un cod ce va targeta doar un adaptor de pe server, iar ala va fi cel corect.
PS: Stiu si de NETSH dar nu am fost niciodata fan :).
Getting DNS resolvers via WMI & Powershell
Pentru multe task-uri aleg de multe ori WMI fie via Powershell fie altceva, mai ales pentru compatibilitate cu versiunile mai vechi de Windows. Pentru ultimele versiuni exista cmdlet-uri builtin dar o sa spun cate ceva despre ele mai tarziu.
Task-ul pe care vreau sa-l execut astazi este de a extrage lista de DNS Resolvers de pe un client. Clientul poate fi local sau remote, dar o sa folosim unul remote pentru a merge pe un exemplu mai util. Pentru asta folosim comanda
GWMI –class win32_networkadapterconfiguration –computer “computername” –filter “ipenabled = $true”
Obiectul rezultat va contine multe din setarile IP ale sistemului dar noi vrem doar setarile specifice DNS.
Pentru asta vom stoca rezultatul comenzii intr-o variabila si vom enumera proprietatea DNSSERVERSEARCHORDER. Mai jos vedeti un exemplu in care accesem aceasta proprietate, inclusiv elementele individuale din array.
In exemplul de mai sus puteti vedea cum aflam dimensiunea array-ului folosind proprietatea COUNT.
In Powershell 4 exista si cmdlet-uri specifice pentru DNS iar unul dintre ele este Get-DnsClientServerAddress. Il putem folosi cu parametrul –cimsession pentru a ne conecta la un server remote via WMI:
Get-DnsClientServerAddress –CimSession “computername”
Output-ul este mult prea bogat in informatii asa ca va trebui sa mai restrangem din rezultate. Prima data o sa filtram doar dupa interfetele cu IPv4 iar asta se face filtrand dupa AddressFamily. Atentie ca valoarea dupa care trebuie sa filtrati este 2 nu IPv4 (http://msdn.microsoft.com/en-us/library/hh872425(v=vs.85).aspx)
Get-DnsClientServerAddress -CimSession srv2 | where-object {$_.AddressFamily -eq 2}.
Si ca sa restrangem si mai mult rezultatele o sa eliminam obiectele ce au aceste valori null.
NtTrace & ApiMonitor
Acum cateva zile m-am jucat putin cu doua tool-uri foarte interesante ce pot fi folosite pentru a investiga unele probleme mai complexe.
Primul se numeste NtTrace si poate fi folosit pentru a urmari anumite call-uri ale sistemului de operare, si anume API-urile native din ntdll.dll.
Sau sa vedeti stack-ul unui proces:
Daca procesul urmarit nu foloseste aceste API-uri atunci, nu veti vedea aici nimic. De regula activitatile din kernel pot fi vazute aici.
Ceva documentatie a acestor functii gasiti pe http://undocumented.ntinternals.net/
Celalalt tool este ApiMonitor, vine cu interfata grafica si va permite sa urmariti mult mai multe API-uri si sa efectuati o gramada de investigatii.
Bineinteles ca este si mult mai complex, asa ca necesita ceva learning inainte sa incepeti sa il folositi.
Bypassing Exchange Web Based Management interface
Dupa cum ati observat, Exchange 2013 (si 2010) este foarte strans legat de IIS. orice modificare in IIS poate avea efecte catastrofale asupra Exchange-ului. Si probabil ca ati intalnit si voi cazuri in care daca IIS-ul nu merge sau directoarele virtuale sunt corupte, nu puteti deschide nici interfata web de administrare si nici macar Exchange Management Shell (tot catre un director virtual din IIS se duce si el).
Dar cum ai putea sa mai administrezi un astfel de server cand tool-urile ce te-ar putea ajuta nu merg. Exista cmdlet-uri ce pot reface folderele virtuale din IIS, dar cum ai putea sa le rulezi cand nu te mai poti conecta la Exchange? Cumva trebuie sa poti face bypass la interfata web.
Solutia este una foarte simpla, dar foarte putin cunoscuta.
Trebuie sa va logati pe unul din serverele la care doriti sa va conectati, sa deschideti o sesiune Powershell (atentie, o sesiune normala, NU Exchange Management Shell) iar acolo sa importati modulele de Exchange cu urmatoarea comanda:
Add-PSSnapin *exchange*
Imediat comezile de Exchange vor fi disponibile iar comunicatia nu se va mai face prin IIS ci local prin RPC.
Iata mai jos un exemplu pe un server unde comunicatia nu mai functioneaza prin IIS:
Sper sa va ajute ;).
Windows 9 Leaked Screenshots
Pentru cine e curios iata cateva imagini cu presupusa interfata din Windows 9:
http://www.theverge.com/2014/9/11/6135079/windows-9-leak-technical-preview
The Host’s "A" Record Is Registered in DNS After You Choose Not to Register the Connection’s Address
Normal stim ca pe un server Windows care este si DC sunt doua procese responsabile pentru publicarea informatiilor in DNS: DNS/DHCP Client Service si Netlogon.
Dar scapam ceva. Si serverul DNS (uzual pe domain controllere) tine neaparat sa isi publice in DNS toate IP-urile pe care este setat sa asculte. Si face asta indiferent daca setati sau nu “Register this connection’s addresses in DNS”:
Ca sa nu se mai inregistreze in DNS cu interfetele nedorite (backup, management network, etc), serverul DNS trebuie setat sa aculte doar pe IP-urile dorite si nu pe “All IP addresses”:
Alte cateva detalii gasiti in urmatoarele KB-uri:
http://support.microsoft.com/kb/275554
http://support.microsoft.com/kb/2023004
Resetting Domain Controller computer account password
Cand vine vorba de replicarea intre domain controllere sunt multi factori care trebuie luati in calcul, insa unul este acela ca si DC-urile se autentifica unul la celalalt. Iar daca autentificarea nu merge, atunci nici replicarea nu o sa mearga.
Iar cand lucrul asta se intampla de obicei vedeti erori gen “The target principal name is incorrect", “Access denied” sau KRB_AP_ERR_MODIFIED.
http://support.microsoft.com/kb/2090913
Si de regula asta se intampla atunci cand exista o desincronizare intre parola computer account-ului unui domain controller. Adica un domain controller a trecut de mai mult de doua ori prin procesul de schimbare a parolei computer accountului, a scris informatia respectiva in AD-ul local, dar partenerii remote nu au noua parola.
Din cauza asta autentificarea prin Kerberos (ce cripteaza informatii pe baza parolei computer accountului) nu o sa mearga, deci nici replicarea.
Schimbarea parolei se poate face cu NETDOM:
netdom resetpwd /server:<remote DC> /userd:<user name> /passwordd:<password>
La parametrul /server trebuie pus numele DC-ului unde se doreste sa se faca schimbarea. Parola va fi schimbata in acelasi timp si local dar si pe DC-ul remote. Ignorati help-ul comenzii.
In acest timp, KDC-ul local trebuie oprit iar serverul trebuie facut sa-si obtina tickete noi de la un alt KDC.
Sunt multe articole cu informatii despre aceasta procedura insa cel mai complet mi s-a parut cel de aici:
http://support.microsoft.com/kb/2090913
Dar si http://support.microsoft.com/kb/260575 si
PS: NETDOM si NLTEST sunt de baza pentru aceasta operatiune.
HTC One (M8) cu Windows
Zilele trecute am avut o surpriza. HTC a scos unul dintre modelele lor de top, HTC One M8 cu Windows 🙂
http://www.htc.com/us/smartphones/htc-one-m8-windows/
Chiar sunt in cautare de telefon nou zilele astea insa tot nu prea am curaj sa ma apropii de ceva cu Windows.
Protected Users group in Active Directory
Grupul Protected Users este un grup nou ce vine cu AD-ul de pe Windows 2012 R2 si care are ca scop sa zicem protejarea unor conturi sensibile din Active Directory. Nu este ceva ce as putea recomanda pentru orice scenariu pentru ca dupa cum o sa vedem poate crea si unele neplaceri pentru un admin.
By default grupul este gol, si puteti pune conturile sensibile in acest grup dupa instalarea unui DC cu Windows 2012 R2. Grupul iti ofera “protectie” in doua feluri. Odata client side si inca o data server side. Asta ce inseamna? Inseamna ca si clientul si serverul vor verifica apartenenta la acest grup si daca faci parte din el anumite decizii vor fi luate. Bineinteles, clientul trebuie sa fie aware de aceasta “optiune” (adica trebuie sa fie Windows 8.1 sau 2012 R2). Dar si un client mai vechi poate beneficia de un soi de protectie prin verificarile si actiunile facute pe partea de server.
Iata de exemplu ce se intampla daca adaug un cont de domain admin in acest grup si incerc sa accesez un server cu Windows 2012 R2 folosind adresa IP (pentru a forta folosirea protocolului NTLM in loc de Kerberos). Daca folosim Kerberos atunci accesul functioneaza perfect.
Pe scurt, NTLM-ul va fi blocat pentru membrii acestui grup. Ca si curiozitate iata si ce se vede intr-o captura de pe retea:
Pentru diagnostic, pe domain controller gasim si cateva loguri in categoria Aplication and Services Logs/Microsoft/Windows/Authentication si iata cam ce puteam vedea acolo:
Atentie insa ca toata schema asta poate aftecta si alte servicii pe care in prima faza nu le luati in calcul. Iata ce se intampla cand incerc sa ma conectez la un domain controller folosind adresa IP (de pe un Windows 8.1):
Iar mai jos este mesajul cand incerc acelasi lucru de pe un Windows 7.
Deci mare grija cand adaugati conturile administratorilor in acest grup.
Restrictiile mai sunt valabile si atunci cand accesati un server cu o versiune de Windows mai veche, de exemplu Windows 2008, conditia fiind sa aveti toate DC-urile din domeniu cu Windows 2012 R2 (domain functional level 2012 R2).
Mai jos o sa pun restrictiile asa cum sunt listate ele pe Technet:
When Windows 8.1 devices are connecting to Windows Server 2012 R2 hosts
When the Protected Users’ group account is upgraded to the Windows Server 2012 R2 domain functional level, domain controller-based protections are automatically applied. Members of the Protected Users group who authenticate to a Windows Server 2012 R2 domain can no longer authenticate by using:
- Default credential delegation (CredSSP). Plain text credentials are not cached even when the Allow delegating default credentials Group Policy setting is enabled.
- Windows Digest. Plain text credentials are not cached even when Windows Digest is enabled.
- NTLM. The result of the NT one-way function, NTOWF, is not cached.
- Kerberos long-term keys. The keys from Kerberos initial TGT requests are typically cached so the authentication requests are not interrupted. For accounts in this group, Kerberos protocol verifies authentication at each request..
- Sign-in offline. A cached verifier is not created at sign-in.
Non-configurable settings to the TGTs expiration are established for every account in the Protected Users group. Normally, the domain controller sets the TGTs lifetime and renewal, based on the domain policies, Maximum lifetime for user ticket and Maximum lifetime for user ticket renewal. For the Protected Users group, 600 minutes is set for these domain policies.
After the user account is added to the Protected Users group, protection is already in place when the user signs in to the domain.
When domain controllers other than Windows Server 2012 R2 require the Protected Users security group
The Protected Users group can be applied to domain controllers that run an operating system earlier than Windows Server 2012 R2. This allows the added security that is achieved by using the Protected Users group to be applied to all domain controllers. The Protected Users group can be created by transferring the primary domain controller (PDC) emulator role to a domain controller that runs Windows Server 2012 R2. After that group object is replicated to other domain controllers, the PDC emulator role can be hosted on a domain controller that runs an earlier version of Windows Server.
For more information, see How to Configure Protected Accounts.
Built in restrictions of the Protected Users security group
Accounts that are members of the Protected Users group that authenticate to a Windows Server 2012 R2 domain are unable to:
- Authenticate with NTLM authentication.
- Use DES or RC4 encryption types in Kerberos pre-authentication.
- Be delegated with unconstrained or constrained delegation.
- Renew the Kerberos TGTs beyond the initial four-hour lifetime.
Ar mai fi multe de spus despre Protected Groups insa documentatia este inca foarte subtire pe acest topic si cred ca va fi folosit in foarte putine cazuri. De tinut minte ca poate cauza multe probleme cand nu a fost testat cum trebuie inainte de implementare si avut grija atunci cand inca mai aveti DC-uri cu Windows 2003 (e posibil sa blocheze si autentificarea Kerberos).
De ajutor in a intelege cum functioneaza mai este si pagina de aici: http://technet.microsoft.com/en-us/library/dn518179.aspx
Happy SysAdmin Appreciation Day!
https://www.youtube.com/watch?v=nRAuDdOfGIg#t=21