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

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

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.

Bun, hai sa vedem ce si cum am facut. Pentru inceput, cerinte:

1. modificam schema de AD
2. facem rost de poze
3. cunostinte minime powershell sau Gugl

Pentru modificarea schemei de AD rulam urmatoarea comanda intr-un cmd cu Run As Administrator:

Regsvr32 schmmgmt.dll

Facem rost de poze ale utilizatorilor. Le modificam sa fie sub 10 KB, 96×96 px si le salvam ca .JPG

Acum, punem pozele intr-un director (sa zicem C:\Emp_Pictures) si le redenumim in alias.jpg de exemplu. Teoretic, calea catre poza mea va fi C:\Emp_Pictures\vitalie.ciobanu.jpg

Daca vrem sa importam poza pentru un singur utilizator, rulam comanda de mai jos in Exchange Management Shell:

Import-RecipientDataProperty -Identity vitalie.ciobanu -Picture -FileData ([Byte[]]$(Get-Content -path C:\Emp_Pictures\vitalie.ciobanu.jpg -Encoding Byte -ReadCount 0))

Daca vrem sa importam pozele pentru suta de utilizatori, trebuie sa cream un fisier CSV cu datele despre utilizatori si calea catre poza fiecaruia. Fisierul CSV trebuie sa aiba doar doua coloane: alias si calea catre fisier. Mai jos e un exemplu de fisier csv:

alias, cale,

vitalie.ciobanu, C:\Emp_Pictures\vitalie.ciobanu.jpg

prenume.nume,C:\Emp_Pictures\prenume.nume.jpg

Tip:

Ca sa nu va chinuiti sa faceti copy/paste la alias in calea catre poza userului, deschideti un excel si in celula B2 scrieti: ="C:\Emp_Pictures\"&A2&".jpg" si copiati formula in jos cat aveti inregistrari (aliasuri) in coloana A. Pentru celula B3, evident, stringul va fi ="C:\Emp_Pictures\"&A3&".jpg" si tot asa mai departe…

Salvati fisierul excel ca Emp_Pictures.csv pe discul C: de exemplu.

Pentru a adauga poze mai multor utilizatori, rulam comanda de mai jos in Exchange Management Shell:

Import-CSV C:\Emp_Pictures.csv | % {Import-RecipientDataProperty -Identity $_.alias -Picture -FileData ([Byte[]]$(Get-Content -Path $_.cale -Encoding Byte -ReadCount 0)) }

Daca vreti sa vedeti ce mai fac si unii MVP (din afara, evident ), intrati aici http://www.mikepfeiffer.net/2010/05/manage-exchange-2010-thumbnail-photos-with-a-powershell-based-gui/ 

Disclaimer:

This weblog contains my personal opinions, offered in good faith, but also come with no guarantees or warrantees. These opinions does not necessarily reflect those of my employer nor the committees I’m member of.

Cu Powershell poate fi mai simplu sau mai complicat, depinde exact ce vrei sa faci. Obiecte de tip user pot fi create foarte usor cu cmdlet-ul New-ADUser.

Nota: pentru a afla care e smecheria cu $Password, vezi mai pe la sfarsitul post-ului.

Iar daca vrei sa importi o lista de useri din CSV, poti sa o faci dintr-o singura linie folosind Import-CSV:

Import-CSV users.csv | New-ADUser

Trebuie doar sa fii atent ca primul rand din CSV sa contina numele atributelor asa cum le vrea New-ADUser (vezi in help parametrii ceruti de New-ADUser). Nu e nevoie sa fie in ordine.

Mai complicat e cu Powershell sa ii setezi parola user-ului si sa-l activezi, dar folosind urmatoarea comanda se rezolva:

Pentru a functiona e nevoie sa definiti inainte variabila $Password ca securestring:

Mai merge si cu readhost – assecurestring:

Aceasta valoare va va deveni parola utilizatorului. Daca doriti sa importati parola din CSV (fiecare user cu parola separata) atunci e mai mult de munca si e nevoie de un script care sa citeasca parola din CSV sa o transforme in securestring si abia apoi sa rulati new-aduser in cadrul scriptului.

Totusi zilele astea scormonind prin MSDN am gasit ceva si acolo:

http://msdn.microsoft.com/en-us/library/ms677980(v=VS.85).aspx

User Object User interface Mapping e organizat pe tab-urile din ADUC si e foarte simplu de gasit atributul corespunzator unui anumit camp.

Util atunci cand vrei sa faci rapid un script pe genunchi.

In continuare si in Windows 2008, daca nu folosim Fine Grained Password Policies, se aplica setarile din politica de domeniu.

Nu de putine ori am vazut admini incercand sa seteze Accounts Policy in politica ce se aplica pe containerul Domain Controllers – Default Domain Controllers Policy. Setarile puse acolo nu au nici un efect. Si o sa explic si de ce.

Da, stiu, putem seta pe un alt OU care contine computer accounturi, Accounts Policy, dar setarile se vor aplica si vor avea efect doar pentru conturile locale, iar cele de domeniu folosite pe acele masini nu vor fi afectate. Cum domain controllerele nu au conturi locale, mecanismul asta nu se aplica. Domain controllerele citesc Accounts Policy numai din politica de domeniu si ignora orice altceva setat intr-o politica legata de containerul Domain Controllers sau alt OU.

In afara de Accounts Policy se mai citesc din politica de domeniu si urmatoarele aflate Security Settings/Local Policies/Security Options:

Accounts: Administrator account status
Accounts: Guest account status
Accounts: Rename administrator account
Accounts: Rename guest account
Network security: Force logoff when logon hours expire

Pentru intrebari va astept pe forum.

Despre gasiti aici:

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

Si download aici:

http://www.microsoft.com/downloads/details.aspx?familyid=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en

Parte din acest packet este si Acctinfo.dll care adauga un nou tab in AD Users and Computers destul de folositor pentru taskurile de administrare.

Problema e ca acest dll functioneaza numai pe Windows x86 si cum W2K8 R2 vine numai in versiune x64 nu o sa mai functioneze. Mai nou umbla pe net si versiunea Acctinfo2.dll care mai avea cateva optiuni in plus dar nu era suportata de MS.

Recent am gasit si versiunea x64 a lui Acctinfo2.dll care merge inclusiv pe W2K8 R2. O gasiti aici http://www.activedir.org/ACCTINFO2_64BIT.zip

Pentru prima versiune era nevoie doar sa inregistrezi dll-ul, acum e nevoie de mai multi pasi. Ii gasiti pe toti in documentul din arhiva.

Dupa ce faceti ce scrie acolo tab-ul din ADUC o sa arate cam asa:

Optiunea Most Recent Logon iti arata serverul care a autentificat ultima data acel cont.

Poti vedea si replication metadata pentru acel obiect fara a mai fi nevoie de repadmin.

Si pe baza lui lastlogon poti afla site-ul in care se afla utilizatorul si ii poti schimba parola chiar in acel site.

Nota: Acctinfo2.dll nu este suportat de MS. Nu numai ca nu e suportat, MS nu a publicat niciodata oficial acest dll. So use it on your own risk.

Spor!

Andrei.

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

KB-ul descrie problemele care pot aparea atunci cand ai un RODC in retea si contine update-uri care trebuie instalate pe Windows 2003, XP si Vista.

Deci, de retinut: daca folosesti RODC e obligatoriu sa instalezi updateurile de mai sus pe clienti si chiar si pe domain controllerele care mai ruleaza Windows 2003 in domeniu.

Sa vedem cum procedam. Deschidem ADAC ( Active Directory Administrative Center) din Administrative Tools :

Mergem la Global Search si, in partea dreapta, expandam Add criteria. Bifam “Users with enabled accounts who have not logged on for more than a given numbers of days” si dam click pe Add :

Acum putem selecta numar de zile :

Sa zicem 60 de zile. Dupa care dam un click pe Search si avem rezultatul. Acum, ii putem selecta si, cu click dreapta sau din partea dreapta a consolei ( Tasks ), ii putem dezactiva sau sterge din Active Directory :

Traducerea in LDAP a acestei cautari arata cam asa : cautam obiecte de tip user – persoana, enabled (vezi atributul UserAccountControl) inactive in perioada data curenta minus 60 zile, folosindu-ne de atributul lastLogonTimestamp. Valoarea acestuia din urma este updatata implicit la interval de 14 zile asa ca sfatul meu e sa nu folositi intervalul de 15 sau chiar 30 de zile pentru clean up, ca sa nu riscati sa stergeti conturi active. Convertirea valorii in format standard de timp este descrisa aici .

Cum putem cauta computerele inactive timp de 60 de zile? Editam query-ul, inlocuind valoarea “person” a atributului objectCategory cu “computer”. Click pe Apply si gasim si computerele inactive pe care, de asemenea, le putem dezactiva sau sterge:

Spuneam ca ADAC a aparut de la Windows Server 2008 R2. Consola poate fi folosita totusi si cu Active Directory 2003 si 2008. Vedeti aici conditiile. Sunt valabile si pentru ADAC.