Active Directory Branch Office setup & DC Locator
Un scenariu foarte uzual este acela de a avea domain controllere raspandite in mai multe site-uri, dar cu unul dintre ele desemnat ca site central.
Toate sunt bune si frumoase si setup-ul default functioneaza in majoritatea cazurilor pentru ca daca aveam definite bine subneturile in AD, clientii vor discuta cu DC-ul din site-ul lor.
Dar sunt scenarii cand clientul nu isi stie site-ul, sau cand subnetul nu este definit in AD si atunci incepe sa contacteze DC-uri random in unele cazuri creand si probleme (cel mai cunoscut scenariu mi se pare cel cand joinam in calculator la domeniu).
Problema apare datorita faptului ca toate DC-urile (si cele din site-ul central si cele din branch offices) isi pun in DNS anumite tipuri de inregistrari SRV ce le fac vizibile pentru clientii ce nu isi cunosc site-ul (generic service records).
Recomandat este ca aceste inregistrari sa existe doar pentru DC-urile din site-ul central.
Iata si recomandarea din Windows Server 2003 Active Directory Branch Office Guide:
The domain controllers of the branch domain, except the domain controllers in the data center site, must not register specific records. To ensure that these registrations do not occur, it is essential to create a new Group Policy object and a new global security group to set a special configuration for only the domain controllers in the branches. The following steps are necessary:
- Create a new global group named Hub-DCs.
- Place all domain controllers from the Data-Center-Site in this group.
- Create a new Group Policy object in the Domain Controllers OU named: BranchOfficeGPO.
- Modify the security of this policy object so that the Hub-DCs are denied permission to apply the policy, but have read access to the object.
- Set the values of the following Group Policies:
Computer Configuration/ Administrative Templates/ System/ NetLogon/ DC Locator DNS Record /DC Locator DNS Records not registered by the DCs/VALUE: ENABLED/Mnemonics: LdapIpAddress Ldap Gc GcIPAddress Kdc domain controller Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd GenericGc
Computer Configuration/ Administrative Templates/ System/ NetLogon/ DC Locator DNS Record /Refresh Interval of the domain controller Locator DNS Records/ VALUE: 86400
Iar daca scenariul este mic exista si varianta setarii prin registry (vezi in link-urile de mai jos).
Si iata si alte cateva resurse pe aceasta tema:
http://support.microsoft.com/kb/306602
PS: Daca nu stiati de recomandarea asta stati linistiti. Nu am vazut pana acum nici un AD cu asa ceva implementat :).
Amazon WorkMail
Amazon a anuntat azi lansarea unui nou serviciu, WorkMail, care are ca tinta zona de enterprise si va concura cu Office 365 si Google Apps. WorkMail, dupa cum se poate deduce si din nume, va fi un serviciu de email care va oferi functionalitati cunoscute in Exchange, cum ar fi: Shared Inboxes, Shared Calendars si Global Address Book.
Costul va fi de 4$ pe inbox, asemanator cu preturile practicate de Microsoft si Google.
Mai multe detalii aici
VMware vCenter Server 5.5 Update 2 d
Ieri a aparut un nou update pentru vCenter – VMware vCenter Server 5.5 Update 2 d, care are ca obiectiv rezolvarea mai multor probleme, fara a aduce vreo functionalitate noua. Ultimul release cuprinde urmatoare componente:
- vCenter Server 5.5 Update 2 d | 27 JAN 2015 | Build 2442329
- vCenter Server 5.5 Update 2 d Installation Package | 27 JAN 2015 | Build 2442328
- vCenter Server Appliance 5.5 Update 2d | 27 JAN 2015 | Build 244233
Din lista de probleme rezolvate o sa enumerez doar cateva, oarecum cele mai importante:
- VMware Directory Service consumes excessive memory
- Network Interface Cards of virtual machines in disconnected state might get eject during vMotion
- Accessing the Storage View tab fails with the error – Request failed. Server took to long to respond
- Datastore browser in vSphere Web Client does not overwrite existing files.
- Cloning or deploying virtual machines over the network causes performance degradation
Lista intreaga o gasiti aici cat si detalii despre problemele rezolvate.
vSphere 5.1 Invalid configuration for device ‘0’ error
M-am intalnit cu eroarea respectiva saptamana trecuta cand am avut o problema in infrastructura si mai multe VM-uri conectate la un Distributed Switch au raportat diferite probleme.
Cateva dintre ele apareau fara conectivitatea la retea, asa ca am mers in VM settings la Network Adapter si intr-adevar placa de retea aparea ca nefiind conectata. Am bifat optiunea de Connected si imediat dupa a aparut eroarea Invalid configuration for device ‘0’.
Rezolvearea este destul de simpla, tot ceea ce trebuie sa faceti e sa schimbati port groupul la care este conectata placa de retea si dupa sa mutati inapoi pe port groupul initial.
Active Directory Skeleton Key Attack
In caz ca nu sunteti la curent cu stirile din zona de security m-am gandit sa scot in evidenta un nou tip de atack ce a fost descoperit de curand si ce a fost denumit “Skeleton Key”.
Atacul vine sub forma unui malware ce este “plantat” pe domain controllere si odata ce acesta este incarcat in ram, este sters de pe disk pentru a ingreuna detectia. Asta face ca daca serverul este restartat, malware-ul va trebui reinstalat.
Este important de retinut ca malware-ul nu poate fi instalat pe un domain controller fara a avea acces. Deci de regula atacatorul se foloseste de ori credentialele compromise ale unui admin sau ale unui service account.
In raportul facut de Dell SecureWorks au fost descoperite doua fisiere msuta64.dll si ole64.dll folosite pentru a instala malware-ul pe DC-uri.
Dar sa va spun si cum decurge un astfel de atac, asta daca nu ati banuit deja din nume. Skeleton Key, ca si termen, se refera la o cheie ce poate deschide orice fel de incuietoare. Cand un domain controller a fost alterat cu acest skeleton key malware, atacatorul se va putea autentifica pe acest DC cu orice user din domeniu fara sa ii stie parola. Problema e ca odata ajuns in faza asta este foarte greu de detectat (poate chiar imposibil).
In unul din cazurile in care a fost detectat existau probleme inexplicabile de replicare intre DC-uri. Deci daca vedeti asa ceva si brusc dupa reboot merge, poate vreti sa urmati si pasii de detectie prezentati de SecureWorks si sa instalati si un antivirus cu semnaturile la zi.
Pentru mai multe detalii va invit sa cititi urmatorul articol:
http://www.secureworks.com/cyber-threat-intelligence/threats/skeleton-key-malware-analysis/
Exchange Autodiscover Logic using SCPs
Uite un articol cu niste informatii puse foarte bine cap la cap pe subiectul din titlu, ce merita share-uit:
http://www.coherence.us/coherence/coherence-blogs/entry/exchange-autodiscover-logic-and-scps
(nu mai merg toate link-urile de acolo, dar informatia este chiar si asa foarte utila)
NEWT: Network Emulator for Windows Toolkit
In multe scenarii pe care dorim sa le reproducem avem nevoie sa simulam o conexiune de retea lenta, cu pierderi de pachete sau cu bandwidth limitat. O parte din aceste lucruri le putem simula atunci cand folosim Vmware Workstation, dar in acest scenariu laboratorul este unul mic. E nevoie de ceva si atunci cand folosim Hyper-V sau ESXi.
Si solutia vine de la Microsoft printr-un software-based emulator ce se instaleaza in sistemul de operare si poate simula diverse conditii (latenta, bandwidth, packet loss). Se numeste Network Emulator for Windows Toolkit sau NEWT si pe vremuri era disponibil doar prin Visual Studio si anumite SDK-uri insa acum este disponibil si ca pachet standalone instalabil prin Chocolatey.
Tot ce aveti de facut este sa instalati clientul de Chocolatey si folosind comanda urmatoare puteti instala NEWT: choco install newt .
Imediat dupa instalare putem deschide interfata grafica:
Si o sa vedem si driverul instalat in proprietatile adaptorului de retea:
Ca sa simulam ceva va fi nevoie sa definim un Link si un Filter. In Link definim proprietatile conexiunii si pe upload si pe download iar in Filter specificam ce adaptor local va fi afectat si ce tip de trafic.
In exemplul meu am setat o latenta de 50ms si pe upload si pe download, dar putem seta foarte multe caracteristici dupa cum puteti vedea si in imaginile urmatoare:
Iar in Filter am setat adaptorul de retea afectat (sau putem sa aplicam filtrul peste All Adapters):
La final arata asa:
Iar din meniul Action e nevoie sa actionam Start sau F5:
Si iata ce se intampla cand incerc sa dau ping intr-un IP local:
50ms pe up si 50ms pe down .. 100ms RTT.
Spor la treaba!
Invata de la lenes
M-am gandit sa incepem anul cu o trimitere la un articol ce puncteaza ceva ce sincer am vazut la toti sysadminii de calitate. Si anume “lenea” 🙂
Va invit sa il cititi si sa va ganditi in care categorie va incadrati, harnic sau lenes?
http://news.ccibv.ro/stiri/flash/254-cand-lenesul-este-cel-mai-eficient-angajat
Group Managed Service Accounts in Windows 2012
Una dintre noutatile din Windows 2012 ce nu prea am vazut-o folosita foarte des este Group Managed Service Accounts (aka gMSA) si este o urmare fireasca a Managed Service Accounts (MSA) din Windows 2008.
Mai tineti minte MSA, nu? Eu nu prea pentru ca nu mi se paruse utilizabil, trebuia sa fac cate un cont pe fiecare server, scenariile de utilizare erau foarte limitate, etc. Ce e important sa ne amintim, este ca un managed service account isi gestioneaza singur parola si astfel administratorul poate elimina de pe lista de taskuri schimbarea periodica a parolei si modificarea ei pe serverele unde este folosit contul.
Ei bine gMSA este o evolutie normala a MSA si rezolva o problema pe care am spus-o mai sus. Si anume, un astfel de cont poate fi folosit pe mai multe sisteme. De aici si denumirea, este de fapt un service account ce poate fi folosit pe un grup de servere.
Schimbarile constau in special in modul de generare si folosire a parolei. De data aceasta parola este generata pe domain controller de serviciul Key Distribution Service (KDS) ce foloseste un algoritm ce include o cheie creata in prealabil, cheie ce se va afla pe toate domain controllere. Cum toate domain controllerele vor folosi acelasi algoritm si aceeasi cheie ce va fi replicata intre DC-uri, parola va fi identica indiferent de cine o genereaza.
Ca sa puteti folosi gMSA va fi nevoie sa aveti macar un DC cu Windows 2012 in domeniu (automat si update de schema cu atributele necesare pentru gMSA).
Primul pas este sa creati ROOT KEY, acea cheie folosita pentru generarea parolei. Se face din Powershell (de fapt cam tot ce implica gMSA se face din Powershell) cu comanda Add-KdsRootKey –EffectiveImmediately.
Atentie ca –EffectiveImmediately nu inseamna ca se face instantaneu. A fost introdus un ‘lag’ de 10 ore pentru ca aceasta cheie sa fie replicata pe toate domain controllerele si deci va trebui sa asteptati ceva pana sa puteti seta primul gMSA.
Exista si un workaround (pentru medii de test) ce face totul instantaneu (recomand totusi un repadmin /syncall):
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Odata creata cheia avem liber la creat primul service account. Dar mai intai trebuie sa stabilim ce servere vor avea acces la acest cont. Iar lucrul asta il putem face printr-un security group. Putem face unul nou sau ne putem folosi de un grup existent. De exemplu eu o sa folosesc grupul domain controllers pentru a folosi noul cont pe toate domain controllerele.
Nota: In caz ca folositi un grup nou, serverele respective vor trebui sa isi reinoiasca ticketele Kerberos, reboot, sau klist purge –li 0x3e7 pentru a face purge la ticketele din sesiunea computer account-ului. Comenzile pentru gMSA specifica si faptul ca poti adauga direct lista de servere ce vor avea acces fara a folosi un grup de securitate, insa eu nu am vazut sa mearga aceasta optiune. Deci tot la grup ramanem.
Contul il facem cu New-ADServiceAccount si trebuie sa specificam numele contului, un nume FQDN si grupul ce va avea acces (parametrul –PrincipalsAllowedToRetrieveManagedPassword).
Noul cont il putem vedea deja in AD.
Pasul urmator va fi sa “instalam” acest cont pe un server si sa testam daca poate fi folosit. Pentru asta vom folosi Install-ADServiceAccount si Test-ADServiceAccount.
Dar asta nu este tot. In exemplu de aici dorim sa folosim acest cont pe domain controllere, asa ca va trebui sa ii dam drepurile necesare pentru a putea rula aici, adica eu in cazul meu va trebui sa il adaug in grupul domain admins.
Din acest moment contul meu are drepturi depline de a rula pe domain controllere si dupa cum am si denumit contul backupAccount, va avea drepturi de a face backup si de a rula ca si job.
Dar in acest moment voi folosi ca exemplu un serviciu pentru ca setarea unui job de backup presupune si alte elemente ce nu le voi acoperi in acest articol.
Tot ce trebuie sa faceti este sa adaugati un $ la numele contului si sa nu setati parola.
Pentru setarea unui job de backup este nevoie de crearea unui job in task scheduler iar interfata grafica nu functioneaza cu gMSA. Va fi nevoie din nou de Powershell si de un batch cu comanda de backup (wbadmin parca e mai simplu decat powershell la capitolul asta). Probabil voi reveni in curand cu detalii si despre acest task.
Retineti ca nu toate componentele din OS functioneaza cu gMSA. Important este ca merg serviciile si Task Scheduler. Din ce am mai citit am inteles ca functioneaza si cu IIS application Pool si SQL 2012.
Recunosc ca pare destul de complicat la inceput si poate ca si asta este motivul pentru care nu a prea prins la public, insa dupa ce faci task-ul asta de cateva ori devine destul de banal.
Creating Self Signed certificates with Powershell 4.0
In sfarsit am gasit in Windows o metoda mai simpla de a face un certificat selft signed. Uitati de makecert.exe si treceti la Powershell 4.0 pentru ca are tot ce va trebuie. Cu New-SelfSignedCertificate puteti face un certificat instant sau puteti copia unul existent.
Sintaxa arata cam asa:
New-SelfSignedCertificate -DnsName test.winadmin.ro -CertStoreLocation cert:LocalMachine\My
Si nu trebuie generat neaparat pe masina destinatie. puteti sa-l generati oriunde si apoi sa il exportati cu Export-PfxCertificate.