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 general servicedesk-ul primeste dreptul de a reseta parole pentru ca asta e unul din rolurile lor de baza (trist dar adevarat), nu si unlock, probabil pentru ca nu exista un atribut anume pentru a fi delegat.

In cazul asta sa explicam cum se face. Prima data trebuie sa avem un grup pentru utilizatorii din servicedesk (intotdeauna delegati folosind grupuri nu user accounts).

Vom efectua exercitiul folosind consola AD Users & Computers cu toate ca exista si alte metode ceva mai simple, insa nu pentru adminul incepator. Activam Advanced Features:

Ne ducem pe containerul peste care vrem sa delegam permisiunile:

Click pe Add:

Si de aici incepe delegarea permisiunilor:

Iar acum dam drepturi peste atributul lockoutTime:

Din acest moment membrii grupului Servicedesk vor avea dreptul sa faca unlock pe conturile aflate in OU-ul peste care am efectuat delegarea.

Simplu, nu? O sa revin si cu alte taskuri din categoria delegari.

Stiu ca foarte multi administratori de Active Directory s-au lovit de problema asta. In special cand preiei administrarea unui domeniu de la altcineva sau cand obiectele care le ai in domeniul tau au venit printr-o migrare.

Bifa din imaginea de mai jos se refera la mostenirea permisiunilor de pe containerul care contine obiectul (sau pot fi mai multe nu numai unul).

E nevoie ca aceste permisiuni sa se propage la obiectele din container, pentru ca la nivel de container se fac delegarile de permisiuni. Sa luam exemplul in care delegam permisiunea de a reseta parole unui admin regional pentru toti userii care se afla intr-o anumita locatie, mai exact toti userii care se afla intr-un anumit container (OU).

Daca obiectele din containerul meu nu au bifa de care pomeneam mai sus activa, delegarea nu o sa functioneze. By default bifa e activa, insa pe parcursul vietii unui obiect in AD, se poate schimba. Cateodata poate fi facuta manual sau de anumite procese – gen cazul cand un user este adaugat in grupul Domain Admins, iar cand este scos nu este pusa la loc.

Cum putem sa fortam activarea acestei bife sau sa vedem daca este activa? In cazul unui singur utilizator e simplu, problema apare atunci cand avem zeci sau sute de utilizatori (poate chiar mai multi dar ne oprim aici) de modificat sau verificat.

Ca de obicei VBScript ne sare in ajutor. Mai jos avem un exemplu de script care verifica toti userii dintr-un anumit OU din AD si activeaza optiunea Allow inheritable permissions.

‘Script created by Andrei Ungureanu
‘www.winadmin.ro

On Error Resume Next

Const ADS_SCOPE_SUBTREE = 2
Const SE_DACL_PROTECTED = 0

Set objConnection = CreateObject("ADODB.Connection")
Set objCommand =   CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection

objCommand.Properties("Size Limit")= 10000

objCommand.Properties("Page Size") = 10000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE

objCommand.CommandText = _
"<LDAP://ou=accounts,dc=itboard,dc=local>;"_
& "(objectCategory=user);sAMAccountName,distinguishedname;subtree"

Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst
Do Until objRecordSet.EOF

userDN = objRecordSet.Fields("distinguishedName").Value
set objObject = getobject("LDAP://" & userDN & "")
Set objntSD = objObject.Get("nTSecurityDescriptor")

intNTSDControl = objNtSD.Control

If intNTSDControl <> 35844 Then
    ‘ Enable "allow inheritable permissions".
    intNTSDControl = intNTSDControl And SE_DACL_PROTECTED
    objntSD.Control = intNTSDControl
    objObject.Put "nTSecurityDescriptor", objntSD
    objObject.SetInfo
    WScript.Echo "Obiectul " & userDN & " a fost modificat"
End If

objRecordSet.MoveNext
Loop

Calea LDAP://ou=accounts,dc=itboard,dc=local trebuie inlocuita cu locatia in care avem obiectele ce trebuiesc scanate. Merge specificat chiar si domain root insa nu recomand asa ceva. Recomand ca inainte sa folositi scriptul, sa il verificati pe un mediu de test.

PS: scriptul merge modificat foarte usor si doar pentru a arata starea bifei Allow inheritable permissions.