MOLEHAND Solutions

 
Print  
Author: MOLEHAND Created: 2008. 09. 26. 23:33
Active Directory

By Szeifert Gergő on 2012. 04. 09. 23:25

Amikor egy kisebb cég átalakul, jönnak az új munkaerők, nagyobb beruházások, célszerű saját szervert beszerezni.
 
Azonban sokszor tanácsolt és javasolt a helyi felhasználókat és számítógépeiket tartomnyba léptetni. Viszont a felhasználók nem szeretik, ha már egy megszokott háterük, mappájuk, asztalukon valami nem ott van, vagy nem az, mintahogyan azt ők megszokták már. Ebben az esetben célszerű migrációt alkalmazni.
 
Ennek megoldása az alábbi lépések megvalósításával megoldható:
 

1. Lépjünk be a szerverre: Rendszergazda/Jelszó

2. Hozzuk létre a felhasználót a szerveren: keresztnév első betűje aztán vezetéknév pl.: gszeifert

3. (Zárójeles megjegyzés: biztonság végett jó ha tudjunk a kliens Rendszergazda jelszavát, ha nem akkor meg is változtathatjuk biztonság végett, vagy kérdezzük meg.)

4. Klienst léptessük ki a jelenlegi domainből (Tegyük át munkacsoportba mondjuk) és restart.

5. Lépjünk be Rendszergazdaként (vagy lokál userrel).

6. Vegyünk fel maunálisan DNS címet (amennyiben a beállítások nem frissültek volna). Ez általában a szerver és/vagy a router.

7. Léptessük be a klienst a domainbe: valami.local

8. Lépjünk ki a local userből és lépjünk be domain userként.

9. Lépjünk ki a domain userből és lépjünk be domain adminként.

10. Nyissuk meg az intézőt: Documenst and Settings: Jobb klikk a local user mappáján -> Tulajdonságok - > Biztonság -> Hozzáadás (domain usert) és adjunk full controlt neki, majd Alkalmaz.

11. Lépjünk a Speciális fülre és pipáljuk be az Objektumtól örökölhető... kezdetű sor előtti jelölőnégyzetet (alsó sor), majd Alkalmaz és OK.

12. (Opcionális: távolítsuk el a local usert a persmission listából.)

13. Ha ez megvan akkor Start -> Futtatás -> regedit

14. Válasszuk ki a HKEY_LOCAL_MACHINE sort, majd File -> Struktúra betöltése -> NTUSER.DAT (Elérése, ha nem oda ugrana elsőnek: C:\Documents and Settings\user\NTUSER.DAT) Állítsuk be a mappa tulajdonságainál a rejtett fájlokra vonatkozó szabályt, különben nem látjuk a fájlt.

15. Adjunk neki egy tetszőleges Key nevet.

16. Előfordulhat hogy nem sikerül neki betölteni, ilyenkor: cmd -> reg load HKLM\TempUser "C:\Documents and Settings\user\ntuser.dat"

17. Majd regeditben folytatjuk: válasszuk ki azt a bejegyzést amit hozzáadtunk most (vagy tetszőleges név, vagy TempUser), és jobb klikk -> Engedélyek.

18. Mint az elején itt is adjuk hozzá a domain usert, adjunk neki full controllt, és a speciális fülben válasszuk ki az alsót. Megesik hogy a speciális fülön nem engedi valami miatt az alsó alkalmazását. Ebben az esetben ez elmarad. Majd Apply és OK.

19. Miután megvagyunk, maradjunk ezen a kulcs bejegyzésen és File -> struktúra leválasztása, vagy cmd: reg unload HKU\TempUser

20. Most pedig registry kulcs értékeket kell átmásolni.

21. Lépjünk ide: HKEY_LOCAL_Machine\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

22. Válasszuk ki a local usert és jobb klikk a ProfileImagePath kulcson -> Módosítás és az értéket másoljuk ki.

23. Keressük meg a domain usert és másoljuk be neki ugyan abba a kulcsába.

24. Töröljük a local user-nél ezt a bejegyzést (Nem magát a kulcsot, csak az értékét.).

25. Indítsuk újra a gépet és lépjünk be domain userrel.

 

By Molnár Péter on 2011. 06. 05. 5:19

Az eddigi elég körülményes restore mellett az Windows 2008 R2-ben megjelent a lomtár, így a törölt objektumok sokkal egyszerűbben visszaállíthatóak 180 napig.
 
A működéshez Windows 2008 R2 domain és forest szint szükséges, és ezen felül engedélyezni kell a funkciót powershell segítségével.
 

By Molnár Péter on 2011. 06. 05. 5:09

Az alapfogalmak
Csak tömören és a Windows Server 2003-ra kihegyezve következzen egy kis összefoglaló, egy még erőteljesen nyomdaillatú, de remélhetőleg a jövőben sokak által alaposan megforgatott könyvből, melynek címe:  "Rendszerfelügyelet rendszergazdáknak":

“A tartományok és erdők Windows Server 2003 Active Directoryban bevezetett működési szintjeinek segítségével engedélyezhetők bizonyos tartományi és erdőszintű Active Directory szolgáltatások. A hálózati környezettől függően másféle beállítások állnak rendelkezésre a tartományok és az erdők különböző működési szintjein. A működési szint egyrészt meghatározza a tartományban, illetve erdőben elérhető szolgáltatások körét, másrészt a működési szint emelésével régebbi tartományvezérlők már nem adhatók a tartományhoz. A tartományok működési szintjei a teljes tartományban, és csakis az adott tartományban elérhető szolgáltatásokat befolyásolják. A tartományok-hoz négy működési szint áll rendelkezésre: Windows 2000 – vegyes (mixed), Windows 2000 – natív, Windows Server 2003 – átmeneti (interim) és Windows Server 2003.

A működési szint előléptetését követően a korábbi operációs rendszereket futtató tartományvezérlőket nem lehet a tartományba beléptetni. Ha például a tartomány működési szintjét előléptetjük a Windows Server 2003 szintre, Windows 2000 Servert futtató kiszolgálókat tartományvezérlőként már nem lehet hozzáadni a tartományhoz. Természetesen továbbra is beléptethető a tartományba egy Windows 2000 Server, bármiféle feladatot is elláthat, csak tartományvezérlő nem lehet többé.

Az erdők működési szintjének beállításával az erdő összes tartományán engedélyezhetők szolgáltatások. Az erdőkhöz három működési szint áll rendelkezésre: Windows 2000, Windows Server 2003 – átmeneti (interim) és Windows Server 2003. Az erdő működési szintjének előléptetését követően, a korábbi operációs rendszereket futtató számítógépeket tartományvezérlőként nem lehet az erdőbe beléptetni. Ha például az erdő működési szintjét előléptetjük a Windows Server 2003 szintre, Windows 2000 Server rendszert futtató tartományvezérlőket már nem lehet hozzáadni az erdőhöz.

A működési szint emelése több előnnyel is jár, például így tehetjük lehetővé bizonyos erdő- vagy tartományszintű új szolgáltatások, megoldások használatát (univerzális csoportok, stb.), és az Windows Server 2003 R2 változat bizonyos szolgáltatásai is csak magasabb működési szinteken használhatók.”


Nos, annyi biztosan kiderülhet bárki számára ebből az idézetből, hogy a WS08 kapcsán is szét kell választanunk a témát két részre, a tartományok és az erdő szintjére. Ebben a cikkben egyelőre koncentráljunk a tartományok működési szintjével kapcsolatos okosságokra.

WS08 tartomány működési szintek
A legfontosabb: a WS08 a mixed üzemmód kivételével a többi felállásban képes lesz tartományvezérlőként dolgozni. Tehát a WS08 DC egy NT4 PDC-vel már semmiképp nem, viszont a Windows 2000/2003 DC-kkel biztosan egyet fog érteni.

Windows 2000 natív módú tartományok
Beépíthetünk tehát egy ilyen tartományba is WS08 DC-ket, de a problémamentes együttműködéshez szükség lesz még némi technikai információra, amely azonban még nem közkincs, de nyilván hamarosan az lesz. Az viszont biztos, hogy a WS08 AD újdonságok (lásd a végén) a tartomány ezen állapotában még nem használhatóak, hiszen ezen új technológiák alapfeltétele a tiszta WS08-as tartományi üzemmód. A W2K natív módú tartományok viszont a következő pluszokat adhatják az előző (a mixed) módhoz képest:
- Tartományvezérlő lehet: W2K, W2K3, WS08
- Az univerzális csoportok biztonsági és terjesztési csoportokként is használhatóak
- Csoportok általános egymásba ágyazhatósága
- Biztonsági és terjesztési csoportok közötti konverzió
- SID history

Windows Server 2003 módú tartományok
Ebben az üzemmódban a Windows 2000 DC-k már nem, a Windows Server 2003-ak viszont csont nélkül használhatóak együtt a WS08 DC-kkel. A korábban említett WS08 újdonság viszont szintén nem működnek majd ilyen körülmények között (van ami igen, de ez legyen egyelőre még titok). A W2K3 natív módú tartományok viszont a következő plusz lehetőségeket biztosítják az előző (a W2K natív) módhoz képest:
- Tartományvezérlő lehet: W2K3, WS08
- A Netdom.exe-vel átnevezhetjük a tartományvezérlőt
- A „Users” és a „Computers” tárolók (azaz nem OU-k) átirányítása
- Képes frissíteni a gépek illetve júzerek viszonylatában a LastLogonTime attribútumot (de nem replikálja), illetve replikálja a a tartományon belül a LastLogonTimeStamp-et - mégha ez utóbbinál a frissítés kissé nehézkes is, azaz nem túlságosan nagy pontosságú
- Az Authorization Manager a házirendjeit tárolhatja az AD-ban
- Rendelkezésre áll a Kerberos Secure Delegation az alkalmazások számára a Kerberos hitelesítés kikényszerítésére

Windows Server 2008 módú tartományok
Ha már itt tartunk majd, akkor már csak WS08 DC-ink lesznek (vagy elszúrtuk, de nagyon :D). Ez a szint azért fontos, mert gyakorlatilag az összes nagyobb és fontosabb címtárszolgáltatás újdonság ekkor elérhető csak el teljes mellszélességel. A WS08 módú tartományok például (a lista nem teljes!) a következő extrákat adják az előző (a W2K3) módhoz képest:
- Tartományvezérlő lehet: WS08
- DFS-R replikáció a SYSVOL megosztás számára, amely egy kifejezetten kellemes dolog, hiszen ekkor bevethető a DFS-R részeként az RDC algoritmus, amivel könnyedén magas tömörítési hatásfokot is elérhetünk, márcsak azért is, mert az RDC a különbségi replikációs módszert preferálja
- Kerberos AES 128/256 támogatás
- Last Interactive Logon Information, amely megmutatja a júzer legutolsó sikeres interaktív belépésének időpontját, az ehhez használt munkaállomást illetve a sikertelen belépések számát is (a hírek szerint elvileg az ismerős Acctinfo.dll integrálásáról van szó, bár nekem még eddig sehogysem sikerült előcsalogatni ezeket az infókat az ADUC-ban)
- Fine-grained password policies, azaz az alternatív jelszóházirend (eddig egy tartomány = max. egy jelszó házirend volt a szabály), akár OU-ként különböző jelszó házirend opciókkal. További, részletes infó itt.

Raise function level
Megtörténik mindjárt….

Most az erdők működési szintjének WS08-as szintre emelésével folytatjuk. Fárasztó lesz, különösen a vége, ezért kora reggel ne olvassuk el, mert visszaalszunk :D

Első lépésben visszanyúlunk az alapokhoz az előző alkalommal is emlegetett könyvből ("Rendszerfelügyelet rendszergazdáknak"), még a Windows Server 2003-ra koncentrálva:

"Az erdők működési szintjének beállításával az erdő összes tartományán engedélyezhetők szolgáltatások. Az erdőkhöz három működési szint áll rendelkezésre: Windows 2000, Windows Server 2003 – átmeneti (interim) és Windows Server 2003. Az erdő működési szintjének előléptetését követően, a korábbi operációs rendszereket futtató számítógépeket tartományvezérlőként nem lehet az erdőbe beléptetni. Ha például az erdő működési szintjét előléptetjük a Windows Server 2003 szintre, Windows 2000 Server rendszert futtató tartományvezérlőket már nem lehet hozzáadni az erdőhöz."

Szummaként elmondható, hogy óvatosabban kell bánnunk az erdő működési szintjének változtatásával, mint pl. a tartományéval, mert a hatóköre lényegesen nagyobb is lehet.

WS08 erdő működési szintek
A négyből (3 + a WS08) három erdő működési szint mellett használhatunk WS08 tartományvezérlő(ke)t. Nézzük át az idők kezdetétő, hogy mi minden pluszt lehetett korábban elérni egy-egy működési szint emeléssel.

Windows 2000 natív módú erdő
- Tartományvezérlő lehet: W2K, W2K3, WS08
- Az akkor még újnak számító, és előd nélküli címtárszolgáltatás összes alapértelmezett tulajdonságát használhattuk.

Windows 2003 natív módú erdő
- Tartományvezérlő lehet: W2K3, WS08

Néhány újdonság (nem az összes):
- Cross Forest Trust, azaz erdők közötti bizalmi kapcoslat kialakítása, magyarul két erdő összekötése, pl. két cég összeolvadása apropóján. Kétirányú, tranzitív az erdők összes tartománya között,  de nem az az egyik erdőhöz ugyanígy kapcsolódó harmadik erdő felé.
- Tartomány átnevezés
- Link valued replication, azaz az „finomított” replikáció, amely sávszélesség takarékos, és lehetővé teszi hogy ne az adott elemet tartalmazó egész tömb replikálódjon, hanem csak a ténylegesen megváltozott elem
- Séma elemek inaktiválása, azaz olyan osztályok és attribútumok forgalomból kivonása, amelyek sérültek vagy már nem szükségesek. A törlés nem járható út továbbra sem, de legalább a takarítás megoldható, sőt nagy szükség esetén akár visszakaphatjuk a koszt is, ti. az inaktiválás visszavonása, a deaktiválás is működik.
- RODC, bizony a WS08 egyik nagy dobásaként számontartott teljesen új típusú tartományvezérlő működik az erdő Windows Server 2003-es szintjén is, igaz egy kisebb szépséghibával, lásd később.

Windows Server 2008 módú erdő
- Tartományvezérlő lehet: WS08

Újdonságok:
Megdöbbentő, de tartományi szint számtalan újdonságával nagyjából el is lőttük a puskaport, azaz erdőszinten nincs semmilyen extra újdonság. Egyetlen dolgot azért meg kell említeni, ami miatt valószínűleg érdemes is lesz megemelni az erdő működési szintjét, ha lehetséges. A dolog a RODC-val kapcsolatos, de messziről futunk neki. Néhány alkalmazásnál megszokott dolognak számít, hogy  a címtárban tárol szenzitív adatokat (jelszavak, jogosultságok, titkosított kulcsok, stb.). Ezzel nincs is gond, sőt praktikusnak is tekinthetjük ezt a módszert, a tartományvezérlőkre amúgyis fokozottan oda kell figyelünk, és hát valóban ritkán tűnik el egy-egy DC a szerverszobából/teremből. Viszont ha bekerül majd a képbe egy-egy RODC  - ismerve a tulajdonságait: csak olvasható, jelszavakat nem tárol, Server Core-ra is felmegy, stb. -  a telephely egy sötét sarkába lerakva, akkor azért kicsit mégis aggódhatunk. Ugyanis egy címtárpéldány azért lesz azon a gépen is, szóval ha történetesen ellopják, azért kibányászható lesz belőle ez-az.

No, erre találta ki az MS okosan az ún. RODC Filtered Attribute Set (RODC FAS, korábban RO-PAS néven is futott) használatanák lehetőségét, amely azt jelenti, hogy a WS08 Schema Master DC-n pl. az ldfide-vel vagy az ADSIEdit-tel megnövelhetjük az adott attribútum tulajdonságai között a searchFlags értéket (pl. 0-ról 640-re = CONFIDENTIAL / RODC_FILTERED, lásd kép, bár ott még hexában van). Így aztán ha a tartományvezérlő beleakad ebbe az értékbe, akkor ezt az attribútumot nem fogja replikálni a RODC kérésére. Mármint a WS08 GC DC-k, merthogy egy WS03 GC DC továbbra is megengedő lesz (kipróbáltam ezt is, hiába hekkeljük meg az említett flag-et a WS03 Schema Master-en, nem érti) és csont nélkül hagyja magát megerőszakolni. Ha viszont az erdőnkben már nincs és nem is lehet effajta „régi” DC, akkor a problémát – kicsit közvetve ugyan de - letudtuk.

RODC attributum
Az általam variált Employee-Number attribútumon szépen látszik a változás

Sőt, a WS08-ban már gyárilag megjelöltek ily módon egy pár attribútumot, elsősorban a Credential Roaming (azaz ha több gépen bejelentkezve akarunk azonos tanúsítványt és kulcskészletet használni) és a BitLocker miatt, konkrétan ezeket:

- ms-PKI-DPAPIMasterKeys
- ms-PKI-AccountCredentials
- ms-PKI-RoamingTimeStamp
- ms-FVE-KeyPackage
- ms-FVE-RecoveryGuid
- ms-FVE-RecoveryInformation
- ms-FVE-RecoveryPassword
- ms-FVE-VolumeGuid
- ms-TPM-OwnerInformation

Annyi még lényeges, hogy a jelszavak replikálásával ellentétben itt nincs választási lehetőség egyesével. Akárhány RODC-nk is van, a megjelölt attribútumok egyikre sem fognak replikálódni. Vagy mindre fognak, ha nem jelöljük meg.

Ha már itt tartunk, azért említsük meg, hogy a FAS mellett/helyett van még egy lehetőségünk, ez pedig a védeni kívánt attribútum searchFlags értékének feljavítása a „CONFIDENTIAL” szintre (ennek 128 a decimális értéke, ez az előző esetben ugye automatikusan benne van a 640-ben, látszik is a képen). Ezt a WS03 SP1 óta lehetséges művelni, van is hozzá egy rendesen fárasztó KB cikk is. Gyakorlatilag e változtatás az Authenticated Users csoport Read jogát veszi le (ergo egy akármilyen jöttment RODC-jét is), csakhogy - állítólag - az a gond lehet ezzel, hogy az említett alkalmazások esetleg nem veszik majd ezt jónéven. A privát fantáziálásom homályos elméleti eredményeként arra jutottam, hogy ez talán a WS03 DC <> RODC viszonyban is megoldás lehetne, de erről nem szól a fáma (kipróbálni meg nem tudtam), nincs is utalás erre a jelenleg rendelkezésre álló doksikban, de talán kicsit később majd ez is világosan kiderül.

By Kiss Tamás on 2011. 03. 10. 12:04

Ha az AD-k nem szinkronizálnak egymás között, mivel  az utolsó replikáció régebben történt mint a tombstoneLifetime (az az idő amíg az ADből törölt objektum sírját megtartja az AD), akkor a következő teendők vannak:

·         felderíteni és eltávolítani a lingering objecteket.

o    lingering obejct: http://support.microsoft.com/kb/910205

o    felderítés, eltávolítás: repadmin /removelingeringobjects /advisory_mode http://207.46.16.252/en-us/library/cc949136(WS.10).aspx

§  A sourceDCGUID –t a repladmin /showrepl dc1 paranccsal lehet listáztatni, és ott a GUID kell. ( A legelső DC GUIDje és InvocationID-ja megegyezik!) A GUID amivel a DCk egymást azaonosítják, az InvocationID a Directory Services adatbázis példányát azonosítja.

§  Minden DC között le kell futtatni ha nem tudjuk melyik a latest. Ha tudjuk akkor a source mindig ugyan az a DC, ha nem akkor minden kombinácóban futtassuk le, lingering objecteket keresve.

Tipp: A replmon grafikus programmal megnézhetjük mely DCk között nem működik a replikáció, illetve kézzel kényszeríthetjük a szinkronizálást, de ha sikerül is, még nem jelenti hogy magától is menni fog! Ehhez muszáj a registry hack.

Ha ezzel megvagyunk,  jöhet a következő lépés:

·         DC-k szinkronizálásának folytatása:

o    A fönti linken a következő parancs van megadva: repadmin /regkey +allowDivergent . Nekem ezzel nem ment. Helyette, minden DCn a következő két registry kulcsot módosítottam:

§  Strict Replication Consistency registry entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Ez legyen 0 értékű azaz Disabled!

§  Allow Replication With Divergent and Corrupt PartnerHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Ez legyen 1 értékű!

Ha hiányzik valamelyik kulcs, akkor hozzuk létre a helyére. DWORD típus. Én az Allow Replication With Divergent and Corrupt kulcsot nem találtam, így létrehoztam. E nélkül nem indul el a replikáció magától!

Ezek után már működnie kell automatikusan. Miután megbizonyosodtunk, hogy a DCk szinkronizálnak maguktól, a registryben állítsuk vissza a két módosított kulcsot az eredetire.

By Molnár Péter on 2009. 06. 05. 1:40

To check AD Schema, move Schama Master role, or make Schema writeable (eg.: update) You must enable Schema Management Console first.

Follow these steps as Administrator (UAC!):

  1. At the command prompt, type regsvr32 schmmgmt.dll. This should result in a dialog box that says DllRegisterServer In Schmmgmt.dll Succeeded.
  2. Open the management console by typing mmc at the command prompt.
  3. Go to Console | Add/Remove Snap-in.
  4. In the Add/Remove Snap-in dialog box, click the Add button.
  5. In the Add Standalone Snap-in dialog box, select Active Directory Schema, click Add, and click OK.

To make the schema writable:

  1. From the console, right-click Active Directory Schema, and select Operations Master.
  2. In the Change Schema Master dialog box, select the Schema May Be Modified On This Domain Controller check box, and click OK.

Schema  is writeable only on the system that holds the schema operations master role!

By Molnár Péter on 2008. 06. 21. 0:49

Mint tudjuk az AD rengeteg objektumtípust ismer. Sok közülük -mint a nyomtatók- láthatatlanok az ADUC-ban. Ez azonban nem teljesen igaz. Két módszer is van, amivel láthatóvá tehetjük.
  • A ADUC-ban a View menü Users, Groups and Computers as containers sdfEzután -sok másik objektummal együtt- láthatóvá vállnak a nyomtatók. Alapértelmezetten a megosztó objektum (pl. szerver) alatt.
  • Hozzunk létra egy OU-t, vagy containert (ADSI edit). Ezek után a kereséskor válasszuk ki a Find: Printers opciót, és nyomjunk a Find Now-ra. Ekkor megkapjuk az AD-ban található összes nyomtatót. A kívánt elemeket kiválasztva jobb klikk Move... parancsal mozgassuk a létrehozott OU-ba, vagy container-be, ahol ezek után bármikor megtalálhatjuk.

Ezek természetesen csak akkor működnek, ha a nyomtató objektumok léteznek az AD-ban. Ez akkor keletkezik, amikor egy nyomtató megosztásakor bepipáljuk a List in directory opciót.
Az AD keresésben egyébként olyan információkat is találhatunk új oszlopok hozzáadásával, mint a eszköz memóriája, nyomtatási sebesség, duplex képesség, színek, port, stb.
Amennyiben a container-ben való tárolást választjuk, a printerek listája megjelenik a My network place listában.

http://support.microsoft.com/kb/303161/
http://support.microsoft.com/kb/235925/

By Molnár Péter on 2008. 01. 08. 14:13

Két attributum alaján lehetséges:
- LastLogon
- LastLogonTimestamp
Az első a pontos, de nem replikálódó attributum azaz minden AD-n meg kell vizsgálni és összehasolítani az értékeket. A második replikálódik, viszont csak 14 naponta.
 
Ezután gyerekjáték lenne a dolog, de sajnos ezek a csodálatos amerikai emberek úgy gondolták, hogy az ANSI által kitalált formátumot használják. Ez nem más mint az 1601.01.01-óta eltelt 100 nanosecundumok száma(!&@"?)
Tehát a query a 2007.10.01 után nem használt gépekre:
(&(objectCategory=computer)(lastLogonTimestamp<128351730380973000))
Gyönyörű. Természetesen működik user-ekre is. Javaslom az ADexplorer használatát, mert az értelmes dátumban adja vissza a találatokat.
 
Bővebb infó:

By Gömbös Attila on 2007. 11. 26. 12:08

Sok új felhasználó hozzáadását célszerű és gyorsabb script használatával végezni.

Mindez lehetséges a dcadd parancs használatával batch-fájlból.

De tisztább megoldás Visual Basic Scriptet használni.

Option Explicit
Const ForReading = 1

Dim objDomain, objUser, fso, tsInputFile, strLine, arrInput
Dim fldUserHomedir, wshShell

'Domain objektum ldap lekerdezessel, ertelemszeruen sorban OU-ktol indulva
Set objDomain = GetObject("
LDAP://ou=Users,ou=domainPartners,dc=local,dc=domain,dc=hu")
Set fso = CreateObject("Scripting.FileSystemObject")

'Feldolgozando fajl
Set tsInputFile = fso.OpenTextFile("C:\Users\agombos\Desktop\FTP\Migration\service_users2.csv", ForReading, False)

'Csv sorainak beolvasa
'Csv formatumba az alabbi esetben:
'"username", "display name","e-mail address","password"
While Not tsInputFile.AtEndOfStream

  strLine = tsInputFile.ReadLine
  'Elvalaszto karakter a ",", igy tordeli a beolvasott sort
  'A sorbol egy arrinput tomb lesz, a sor elsoeleme a tomb elso eleme - arrInput(0)
  arrInput = Split(strLine, ",")
  'Username alapjan az uj userobjektum letrehozasa, es az atrributumok feltoltese
  Set objUser = objDomain.Create("user","cn=" & arrInput(0))
  objUser.Put "sAMAccountName", arrInput(0)
  objUser.Put "userPrincipalName", arrInput(0) & "@local.domain.hu"
  'Attributumok feltoltese a tomb tobbi eleme alapjan
  objUser.Put "description", arrInput(1)
  objUser.Put "displayName", arrInput(1)
  objUser.Put "mail", arrInput(2)
  'A jelszo hozzarendeles elott mentsuk az objektumot az LDAPba
  objUser.SetInfo
 
  'Lekerdezzuk az uj objektumot LDAP-bol, es azon dolgozunk tovabb - itt elmeletileg objUser.GetInfo fuggvenyhivas is eleg kellene hogy legyen
  Set objUser = GetObject("
LDAP://cn=" & arrinput(0) & ",ou=Users,ou=domainPartners,dc=local,dc=domain,dc=hu")
  'Alapbol disabled statuszban jon letre az objektum
  objUser.AccountDisabled = False
  objUser.SetPassword arrInput(3)
  'Mentjuk az "enabled", es jelszovat ellatott user objektumot
  objUser.SetInfo
  'objUser valtozott kinulazzuk
  Set objUser = Nothing
Wend

'Fajl zarasa
tsInputFile.Close

 

Csvt fájlt Excelben fel lehet tölteni adatokkal. Jelszavak generálására a Balázs által linkelt http://www.pctools.com/guides/password/ oldal ideális. Itt Quantityvel meg lehet adni, hogy hány új jelszóra van szükségünk, használható nagy mennyiségű jelszó generálására a pwgen UNIX alkalmazás is.

By Gömbös Attila on 2007. 10. 19. 14:40

Új gigabites hálókártyával rendelkező gépein jelentkezett a probléma. A hálókártya driver túl lassan töltődik be, és még hálózati link nélkül megpróbálja a Windows a Group Policyt letölteni. A policyt azonban később a kapcsolat létrejöttekor se töltötte le. A megoldás a policy letöltés késleltetésére: http://support.microsoft.com/kb/840669

By Molnár Péter on 2007. 09. 16. 20:13

Egy .DLL aktiválásával nagyon hasznos információkkal bővíthatjük az Active Directory Users and computers modult, többek között ezekkel:
  • Last logon time
  • Logon count
  • SID
  • PW expiration
  • Bad PW counter
  • PW reset by site
  • LDAP path
Szerezzük be a lenti file-t (Pl. Windows Resource Kit)Regisztrálni, adminisztrátori (UAC!) jogokkal így:
regsvr32 %systemroot%\system32\acctinfo.dll
 
Bővebb info:

 

 

Discount offer

 I’ve already tried several providers. Currently all of our projects are placed at MOLEHAND, because they provide real services not only a piece of a computer. Any kind of new problem crops up, I can always count on a fast and expert reaction.