The Microsoft statement regarding Active Directory over NAT is:

• Active Directory over NAT has not been tested by Microsoft.
• We do not recommend Active Directory over NAT.
• Support for issues related to Active Directory over NAT will be very limited and will reach the bounds of commercially reasonable efforts very quickly.

The only configuration with NAT that was tested by Microsoft is running client on the private side of a NAT and have all servers located on the public side of the NAT. The NAT would also function as a DNS server.

http://support.microsoft.com/kb/978772

http://support.microsoft.com/kb/186340/en-us

Nici macar SCVMM-ul nu mai reuseste sa faca o conexiune cu acel host Hyper-V.

Insa stati linistiti, e BY DESIGN – http://support.microsoft.com/kb/2506417.

This issue is by design. Running Active Directory Domain Services on a server that is also running a RemoteFX-enabled virtual machine is not a supported configuration.

Adica Microsoft a facut treaba asta intentionat. Va dati seama cat a muncit indianul ala de la MS sa scrie acel cod care iti blocheaza consola Hyper-V in caz ca rulezi acest scenariu? Eu ma gandesc ca era mai simplu sa afiseze un mesaj de eroare cand instalai RemoteFX sau si mai bine sa recunoasca acest bug.

PS: eu inca stau si ma intreb cum o reusi AD-ul sa incurce RemoteFX-ul.

In Windows 7 lucrurile s-au schimbat, insa tot se pot efectua cautari in AD. Mai jos gasiti in imagini cum.

Sau daca vreti ceva mai scurt, iata comanda:

"C:\Windows\System32\rundll32.exe" dsquery.dll,OpenQueryWindow

Pentru asta ne putem folosi de version number si producttype pe care le putem obtine via WMI:

Version Number:

Windows Server 2008 R2 or Windows 7  -  6.1%

Windows Server 2008 or Windows Vista  -  6.0%

Windows Server 2003  -  5.2%

Windows XP  -  5.1%

Windows 2000  -  5.0%

Product Type:

Windows Server 2008 R2 or Windows 7  – 6.1%

Windows Server 2008 or Windows Vista  -  6.0%

Windows Server 2003  -  5.2%

Windows XP  -  5.1%

Windows 2000  -  5.0%

http://technet.microsoft.com/en-us/library/cc754488(WS.10).aspx

Iar lucrul asta poate fi foarte util atunci cand vrem sa limitam aplicarea unor GPO-uri doar la anumite OS-uri:

Sau daca vrem doar sa influentam modul in care ruleaza un script iata un exemplu care citeste versiunea si tipul OS-ului:

strComputer = “.”
Set objWMIService = GetObject(“winmgmts:” _
& “{impersonationLevel=impersonate}!\\” & strComputer & “\root\cimv2″)

Set colOperatingSystems = objWMIService.ExecQuery _
(“Select * from Win32_OperatingSystem”)

For Each objOperatingSystem in colOperatingSystems
Wscript.Echo objOperatingSystem.Caption & ” ” & _
objOperatingSystem.Version & “    ” & objOperatingSystem.ProductType

Next

Restul tine doar de imaginatia voastra. Pentru alte detalii ma gasiti pe forum.

By default orice user din AD are drept de Read & List Contents peste toate obiectele din AD, asta fiind motivul pentru care toate obiectele sunt vizibile din ADUC.

Dar sa luam cazul in care vrem sa gazduim in AD-ul nostru doua companii iar administratorii delegati peste obiectele din AD nu au voie sa vada decat OU-ul companiei lor. Daca am lasa totul default, lucrurile ar arata asa:

Iar daca am scoatem Authenticated Users din ACL-ul companiei B si ne conectam cu un user normal:

Ii blocam cumva accesul user-ului la acel OU insa tot il va vedea, ca Unknown bineinteles pentru ca nu ii poate citi nici macar ACL-ul.

Ca sa facem sa dispara complet acel OU, e nevoie sa activam List Object Mode. Asta se face activand DsHeuristics pe 001 (mai exact al treilea bit trebuie setat pe 1; daca aveti si alti biti setati, lasati-i in pace).

Detalii la http://technet.microsoft.com/en-us/library/dd346510.aspx

Setarea se aplica la nivel de forest. Nu este necesar reboot.

Imediat dupa modificare putem vedea ca in ACL-uri apare si List Object:

Ca sa facem sa dispara un OU, de exemplu “Company B”, e nevoie sa scoatem List Contents de pe containerul Hosting:

Iar pe containerul Company B, scoatem si List Contents si List Object (merge si daca scoatem List Object, insa List Contents va bloca si queryurile LDAP):

Iar rezultatul este urmatorul:

Pe scurt: List Contents scos de pe containerul parinte, List Object si List Contents de pe child.

Ce am facut eu pana acum a fost doar sa restrictionez vizibilitatea acestui OU pentru Authenticated Users, mai departe puteti asigna permisiuni de Read/List Contents/List Object pentru userii/grupurile ce vor avea access.

ATENTIE la grupul Pre-Windows 2000 Compatible Access. Daca aveti activata aceasta optiune, atunci Authenticated Users o sa faca parte din acest grup. Ori dati remove ori modificati permisiunile si pentru Pre-Windows 2000 pentru ca altfel nu o sa mearga.

Si cam asta e tot, pentru intrebari va astept pe forum.

Ca sa explic putin, o sa dau cateva exemple.

1. File Server in domeniul A. Trebuie sa migrez serverul in domeniul B si din anumite motive translatarea cu ADMT nu functioneaza.

2. File Server standalone (nu radeti ca am vazut si scenariul asta) ce urmeaza a fi migrat la domeniu. Permisiunile sunt date pe grupuri si useri locali si vreau sa le translatez la grupuri de domeniu (pe care cumva va trebui sa le mapez la grupurile locale pentru a nu pierde permisiunile).

3. File Server membru in domeniu dar cu permisiuni date pe grupuri locale, ca deh asa au inteles unii MCSE strategia AGDLP.

Si scenariile mai pot continua dar e suficient deocamdata.

Pentru taskuri de genul asta ar cam fi cateva tool-uri:

- Subinacl – un tool foarte puternic dar in acelasi timp plin de bug-uri. In special pe partea de migrare de ACL-uri. Pentru alte taskuri merge chiar bine.

- SetACL – foarte interesant la prima vedere dar cu o sintaxa urata si cand vine vorba sa lucrezi cu anumite grupuri locale ii cam da cu virgula.

- Sidwalker tools – campionul nostru la exercitiul de azi. Este cea mai buna varianta FREE pentru a translata permisiunile.

Are chiar si un MMC care arata cam asa:

Dupa ce am facut maparile din MMC putem exporta totul intr-un fisier de mapare:

Cum interfata grafica este destul de primitiva si daca avem multe obiecte este imposibil de folosit, ne folosim de ea doar ca sa generam un model al fisierului de mapare. Din momentul acesta tot ce aveti de facut este sa generati fisierul in formatul de mai sus. Vbscript e util dar si mai util e sa stiti Excel (eu nu stiu, dar am pe cine sa intreb la nevoie). Atentie ca o sa aveti nevoie si de SID-urile obiectelor.

Eu acum facand doar un test/demo o sa ma folosesc doar de ce am generat cu MMC-ul Sidwalker. Si tit ca test o sa iau un folder unde pun permisiuni pe doua grupuri locale".

Rulam Sidwalker:

O sa primim erori pentru fiecare entry in ACL caruia nu i-am mapat nimic – asta se datoreaza grupurilor Builtin dar care vreau sa ramana acolo neatinse.

Si iata si rezultatul:

Sidwalker poate scana tot sistemul si translata ACL-urile de pe fisiere, share-uri, printere, registry, mai exact cu o singura comanda poti translata tot ce se afla pe acel sistem.

Tineti minte acest tool si rugati-va ca Microsoft sa nu-l uite si sa-l updateze.

Cautand un tool de modificat ceva in DACL-uri pe NTFS am dat de un post (si nu am salvat link-ul) in care cineva chiar dadea exemplu ca in ghidul de MCSE se recomanda folosirea grupurilor locale pentru acces la resurse. Personal m-am lovit de problema asta si muncesc de o saptamana sa corectez greselile unor astfel de MCSE care au dat acces pe resurse folosind grupuri locale de pe un server.

Guys! Domain Local nu se refera la grupuri locale pe server! Ci la tipul de grup numit Domain Local (spre deosebire de Global sau Universal) in Active Directory.

Schema AGDLP e foarte buna si recomandata in cursurile de MCSE (sau cum i-o mai zice acuma) doar nu confundati “Domain Local” cu Local.

Modul prin care pot fi joinate este cel remote in care te duci pe sistemul respectiv, computer properties, network identification si ii spui ca face parte din domeniul X.Y:

Eu de fiecare data am preferat sa spun ca asta e modul AdHoc de a joina sistemele (si pe care nu il recomand). Computer accounturile pentru sistemele nou joinate for fi create in containerul default Computers:

Si cum nu putea fi atat de simplu acum intervine smecheria. Exista un soi de quota, si fiecare user are dreptul de a joina maxim 10  sisteme. Limita asta o stiu de la Windows 2000 si nu cred ca s-a schimbat. Ce nustiu foarte multi e ca aceasta limita poate fi modificata prin editarea atributului ms-DS-MachineAccountQuota. Despre cum sa-l modifici gasesti aici:

http://support.microsoft.com/kb/243327

Acum de ce am zis ca nu recomand modul asta de a joina sistemele in AD? Pentru ca toate ajung in containerul Computers (by default; nu mai zic cum se modifica pentru ca nu are rost), nu le muta nimeni, GPO nu se aplica si iese o harababura acolo.

Modul pe care eu il recomand e sa delegi drepturile necesare pe un container, sa pre-creezi computer accountul si abia dupaia sa joinezi sistemul la domeniu.

Recomandat in cazul delegarilor e sa folositi grupuri nu useri cum am facut eu in exemplul de mai sus. In caz ca userul pleaca puteti foarte simplu modifica membrii grupului fara a pierde delegarea. Sau puteti revoca drepturi modificand doar grupul.

Tot la fel poti sa-I dai si dreptul de a sterge computer accounturi.

Pasul urmator e de a pre-crea computer accountul:

Deci admin-ul nou delegat trebuie sa foloseasca Active Directory Users and Computers pentru acest task de fiecare data cand o sa introduca un sistem nou in domeniu. Nu e nevoie de drepturi de domain admin sau de drept de logon pe domain controller. Consola se poate instala pe orice statie din domeniu.

Atentie la rubrica User or Group. Aici puteti specifica ce alti useri sau grupuri o sa mai aiba acces pe acest computer account. By default userul ce il creaza este Creator Owner si are drept de Join/Modify/Delete. Aici puteti de exemplu sa specificati un grup folosit de departamentul IT, dar nu e obligatoriu.

Pasul urmator e de a joina sistemul care are acelasi nume cu computer accountul, in domeniu. Iar aici nu e nimic special, e ce am descris in primele randuri ale acestui articol.

Acum insa hai sa luam in calcul inca un scenariu. Poate ca am delegat drepturi pentru un user/grup pe un container in care se mai aflau si alte conturi, sau poate ca mai sunt si alti useri care au drepturi aici si joineaza si ei sisteme. Bineinteles ca userul nostru nu o sa fie Creator Owner pe computer accounturile create de altii si nici nu o sa aiba drepturi (in caz ca nu s-a folosit optiunea User and Group descrisa mai sus). Si ce facem daca vrem sa re-joinam un sistem introdus in domeniu de altcineva (poate de un domain admin)?

Pai mai e nevoie sa delegam urmatoarele drepturi la nivel de OU:

Reset Password
Validated write to DNS host name
Read and write Account Restrictions
Validated write to service principal name

Acesta este minumul de permisiuni necesare pentru re-join:

Mai sus sunt ceva mai multe permisiuni, insa am folosit imaginea pentru a arata unde puteti vedea aceste drepturi. Wizard-ul de delegari ati vazut cum se foloseste, iar daca vreti sa va complicati putin puteti folosi chiar si tab-ul security pentru a modifica drepturile pe un OU.

In felul acesta userul o sa aiba drept sa rejoineze orice computer ce se afla in acest OU.

Si cam atat imi amintesc acum. Sper sa nu-mi fi scapat foarte multe lucruri, dar daca am uitat ceva astept completari.

PS: Ar mai fi si varianta cu dat drept pe containerul Computers, dar nu recomand. De cele mai multe orice, ce ajunge pe acolo ramane orfan.

In SDK-ul de Windows exista exemple pentru asa ceva, la fel si pe net:

http://www.devx.com/security/Article/21522

http://www.codeproject.com/KB/winsdk/LoginFilter.aspx

http://blog.didierstevens.com/2010/11/15/password-auditing-with-a-password-filter/

Acum vreo luna Vitalie imi recomandase prezentarea asta si acolo vazusem un filtru custom care salva parolele intr-un fisier text. Cum bineinteles ca dll-ul respectiv nu e public, m-am gandit “cat de greu o fi sa faci asa ceva?”. Pai mi-a luat cam o zi jumate (cu tot cu instalare de Visual Studio si invatat cum sa lucrez cu fisiere text). Chestiile mai complicate le-am facut cu copy/paste . Am testat doar pe 2003.

Instalezi DLL-ul pe domain controllere si oricine isi schimba parola … ajunge in log.

Ce vreau sa scot in evidenta este ca daca arati cuiva cum se face si nu ii dai sursele, nu inseamna ca-l protejezi. Pana si eu care habar nu am de C++ am fost in stare sa contruiesc un password filter. Trebuie pus accent pe faptul ca acest lucru nu ar fi posibil daca nu ai avea access pe domain controller (adica sa fii Domain Admin).

La cerere pot sa dau DLL-ul membrilor Winadmin.

Personal nu sunt de acord. Scenariul poti sa-l iei in considerare atunci cand ai o organizatie mamut cu zeci, sute de mii de useri. Si chiar si atunci trebuie sa analizezi bine cum sunt folosite datele din AD.

Si cum stiam ca nu sunt singurul care gandeste asa am gasit si recomandarea unor oameni “de incredere”:

http://blogs.technet.com/b/askds/archive/2010/10/29/friday-mail-sack-not-particularly-terrifying-edition.aspx

Cautati prin intrebarile din postul de mai sus. Vedeti si comentariile unde a fost postat un scenariu care ar avea nevoie de un volum separat pentru SYSVOL. Dar e doar un scenariu de care multi dintre noi nu se vor lovi.

Deci cum de performanta nu poate fi vorba intr-o retea mica/medie, de ce sa mergi pe scenariul asta? Ca sa te incurce la backup/restore si sa cresti costurile serverelor? Nu e mai bine sa tii doar un volum in mirror sau un RAID5 atunci cand baza e accesata intensiv?

KEEP IT SIMPLE!