active directory címtár adatainak kezelése scriptek...

Active Directory címtár adatainak kezelése scriptek

segítségével

Konzulens:

Szalai László

Nyugat-magyarországi Egyetem,

Informatika Intézet, Intézeti mérnök

Arnhoffer Edit Evosoft Hungary Kft.

IT Manager

Készítette:

Bangó Balázs

Gazdasági Informatikus hallgató

2

Tartalomjegyzék Active Directory címtár adatainak kezelése scriptek ................................................. 1

segítségével ................................................................................................................ 1

I. Bevezetés ............................................................................................................. 4

1. Active Directory bemutatása ........................................................................ 4

2. Active Directory séma bemutatása ............................................................... 5

3. Active Directory séma kezelése ................................................................... 6

II. Active Directoryban tárolt adatok kezelése ..................................................... 8

1. Active Directoryhoz kapcsolódó szolgáltatások adatai ................................ 8

a) DNS kezelése ............................................................................................ 8

b) DHCP kezelése ......................................................................................... 8

c) Csoportházirendek kezelése ...................................................................... 8

2. Active Directory törzsadatai ......................................................................... 9

a) Felhasználók ............................................................................................. 9

b) Számítógépek, Csoportok, Kontaktok ...................................................... 9

c) Objektumok tetszőleges attribútumának módosítása .............................. 10

3. Active Directory adatkezelés hiányosságai ................................................ 10

III. Munkakörnyezet bemutatása .......................................................................... 12

IV. Active Directory programozási lehetőségeinek bemutatása .......................... 13

1. Parancssori eszközök .................................................................................. 13

2. Visual Basic Script bemutatása .................................................................. 14

3. ADSI bemutatása ........................................................................................ 15

a) Kapcsolat felépítése az Active Directory-val ......................................... 15

b) Objektumműveletek az Active Directory-ban ........................................ 16

c) Keresés az Active Directoryban .............................................................. 17

V. Scriptekkel megvalósított feladatok bemutatása ............................................ 20

1. Új felhasználó felvétele .............................................................................. 20

a) A folyamat leírása ................................................................................... 20

b) Korábbi megvalósítás .............................................................................. 21

c) Jelenlegi megvalósítás ............................................................................ 21

d) Továbblépési lehetőségek ....................................................................... 22

2. Új számítógép felvétele .............................................................................. 22


b) Korábbi megvalósítás .............................................................................. 23

3



3. Felhasználók személyes adatainak megváltoztatása ................................... 24


b) A korábbi megvalósítás ........................................................................... 25



4. További IT WebWorks funkciók ................................................................ 25

5. LDAP kereső .............................................................................................. 26

a) A korábbi megvalósítás ........................................................................... 26

b) Jelenlegi megvalósítás ............................................................................ 27

c) Továbblépési lehetőségek ....................................................................... 27

6. További scriptekkel megvalósított feladatok .............................................. 28

VI. A scriptek jövője ............................................................................................ 30

1. A VB Script jövője ..................................................................................... 30

2. A PowerShell .............................................................................................. 30

VII. Összefoglalás .............................................................................................. 31

1. Elért eredmények összegzése ..................................................................... 31

2. Következtetések, javaslatok ........................................................................ 31

VIII. Köszönetnyilvánítás .................................................................................... 33

IX. Irodalomjegyzék ............................................................................................. 34

4

I. Bevezetés

Napjaink nagyméretű informatikai rendszereiben alapkövetelmény, hogy

központosított jól kezelhető adatbázis alapú eszköz álljon rendelkezésre a felhasználók

és esetleg további hálózati erőforrások hitelesítésére, valamint adataik kezesére.

Windows kliensekből álló környezetben célszerű a Microsoft saját címtármegoldását

választani, az Active Directory-t.

1. Active Directory bemutatása

Az Active Directory egy LDAP szabvány alapú1 címtár implementáció, amit a

Microsoft a Windows 2000 Serverben mutatott be, és azóta is folyamatosan fejleszt.

A címtár jelenlegi verziója alkalmas felhasználók, számítógépek, különböző

típusú csoportok, kontaktok, nyomtatók és sok egyéb objektum kezelésére,

hitelesítésére, publikálására és velük kapcsolatos adatok tárolására. Ezen túl lehetőség

van az objektumok szervezeti egységekbe rendezésére, így egy könnyen áttekinthető fa

szerkezet hozható létre, ami nagyban megkönnyíti az egyes objektumok

menedzsmentjét. További hierarchizálási lehetőséget nyújt a telephelyek szerinti

csoportosítás, ami a szervezeti egységektől független szint, így problémamentesen

lehet kezelni telephelyeken átnyúló szervezeti egységeket is. A telephelyek

kialakításában valóban a földrajzi elhelyezkedés játszik szerepet és a telephelyek

szerinti testre szabási lehetőségeken túl jelentősége abban áll, hogy a címtárpéldányok

közti kommunikáció szervezésénél is figyelembe veszi a Windows. A szervezeti

egységeknél azonban nem kényszer a valós szervezeti struktúrához igazodva

kialakítani a hierarchiát. Dinamikusan változó szervezeti felépítés esetén ez nem is

lenne hatékony. Sokkal inkább egyedi, IT tervezési szempontok érvényesülnek az

alapján, hogy objektumok egyes csoportjára milyen központi szabályozást szükséges

bevezetni. Az Active Directory ugyanis lehetőséget nyújt csoportházirendek tárolására

és alkalmazására ez egyes szervezeti egységeken, telephelyeken, vagy akár a teljes

tartományon. Ezekkel a házirendekkel Windows 2003 szerver esetén több mint 2000

számítógépre és felhasználóra vonatkozó beállítást lehet központilag szabályozni,

Windows 2008 szerver esetén pedig ezen lehetőségek száma eléri a 3000-et2. További

nagy előnye címtárnak, hogy lehetőség van integrálni a DNS szolgáltatást, így a DNS

bejegyzések is szinkronizálódnak a domain controllerek között. Ennek elsősorban több

telephelyes cégeknél van értelme, hiszen így a névfeloldási kérésekkel nem kell a

telephelyek közti lassabb hálózatot terhelni, mert a szinkronizáció miatt a telephelyek

helyi DNS szerverei is tartalmazzák az összes bejegyzést. Ezen túl a DHCP

szolgáltatást is bele lehet integrálni az Active Directory-ba, így nem okoz gondot

1http://support.microsoft.com/kb/196455 2http://www.microsoft.com/hun/technet/?article=14c05bf7-62e8-492e-b3b5-8881bc4d33e1

5

kideríteni, hogy milyen DHCP szerverek vannak az egyes alhálózatokban és milyen

tartományt használnak. Az alapfunkciókon túl pedig lehetőség van akár a

címtáradatbázis sémájának bővítésére, akár további házirendek készítésére, így

szükség esetén teljesen testre szabható.

Windows 2003-ban az Active Directory sémáját nem csak globálisan lehet

bővíteni, hanem az ADAM (Active Directory Application Mode) segítségével csak

bizonyos alkalmazások számára látható virtuális sémabővítést hajthatunk végre. Ezzel

különböző speciális alkalmazásokat is ki lehet szolgálni az éles séma változtatása

nélkül.

2. Active Directory séma bemutatása

Az Active Directory sémája három osztálytípust különböztet meg, melyek közt

meghatározott öröklődési és példányosítási szabályok érvényesülnek3. Az absztrakt

osztályokat nem lehet példányosítani, viszont lehet örököltetni belőle bármely másik

osztálytípust. A kisegítő osztályok szintén nem példányosíthatók közvetlenül, viszont

bármelyik osztálytípus tartalmazhat kisegítő osztályokat. A strukturális osztályok

közvetlenül példányosíthatók, származhatnak absztrakt vagy strukturális osztályból és

tetszőleges számú segédosztályt tartalmazhatnak.

A Windows 2003 szerver körülbelül 230 osztályt használ alapértelmezésben, ezt

a számot tovább növelhetik egyes Active Directorihoz kapcsolódó programok, például

az Exchange szerver telepítésével, illetve az egyedi sémabővítésekkel. Az osztályok

jelentős része strukturális osztály és a gyakorlatban is komoly jelentőséggel bírnak,

bennük tárolódnak, a hálózati eszközök, felhasználók, DNS, csoportházirendek adatai

valamint a rendszer számára fontos egyéb kiegészítő információk például a domain

controllerek replikációjával kapcsolatban4.

Minden osztály tartalmaz különböző attribútumokat, esetleg további

alosztályokat. Összességében közel 1300 különböző attribútum érhető el az

osztályokban és ezeket három szempontból lehet felosztani5. Egyik csoportosítási

lehetőség az indexelhetőség alapján kínálkozik, egyes attribútumokhoz kapcsolódik

egy search flag, aminek értékét megfelelően beállítva lehet különböző prioritású

indexelést hozzárendelni, vagy le lehet tiltani ezt a szolgáltatást. Az indexelés

megfelelő beállítása nagyban gyorsíthatja a különböző keresésekért. Az attribútumok

másik típusa, a globális attribútumok. Ezek az egyes objektumok kiemelt attribútumai,

melyek replikálásra kerülnek valamennyi globális katalógus szerepkörű domain

controllerre, ezzel biztosítva, hogy egy tetszőlegesen nagy tartományban is minden

objektumról legyen információ a kiemelt tartományvezérlőkön, mivel a teljes

replikáció egy sok ezer számítógépet és felhasználót tartalmazó hálózatban túl lassú

3http://msdn2.microsoft.com/en-us/library/ms677964.aspx 4http://msdn2.microsoft.com/en-us/library/ms683854(VS.85).aspx 5http://msdn2.microsoft.com/en-us/library/ms675578(VS.85).aspx

6

lenne és feleslegesen sok adatforgalmat generálna. A harmadik csoport pedig a linkelt

attribútumok. Ezek olyan attribútumok, melyeknek valamilyen számított értéke vagy

másik objektumra, attribútumra mutató értéke van. Ilyen például a manager

attribútum, amely egy felhasználó főnökére való hivatkozást tárol és a főnök

objektumában is létrejön egy hozzá tartozó directReports attribútum.

3. Active Directory séma kezelése

A séma módosítását legtöbb esetben valamilyen Active Directory adatbázishoz

kapcsolódó program szokta igényelni és kézi beavatkozás nélkül el is végzi, ha

megfelelő jogosultságú felhasználó telepíti. A séma kézi módisítása viszont erősen

ellenjavallott, mivel a módosításokat nem lehet visszavonni, sem meglevő osztályokat

vagy attribútumokat törölni. Az egyetlen megoldás az objektumok vagy attribútumok

inaktív állapotba állítása6. Amennyiben mégis szükség szükséges a séma kézi

módosítása, vagy csak egyszerűen meg szeretnénk vizsgálni a séma felépítését, akkor

az schmmgt.dll csomagot kell importálnunk, majd az mmc konzolban Active Directory

Schema néven érhetjük el a beépülő modult (1. kép).

1. kép. – Active Directory Schema

A konzol jobb oldalán betűrendben találjuk az összes osztályt és attribútumot, az

egyes elemek tulajdonságlapján osztályok esetében általános információkat,

kapcsolatokat és az objektumhoz tartozó attribútumokat találjuk, valamint a biztonsági

beállításokat. Attribútum esetén láthatjuk a típusát és esetlegesen a megkövetelt

szintaxist. Ez az eszköz kiválóan alkalmas a séma felderítésére, objektumok és 6Robbie Allen, Laura E. Hunter: Active Directory Cookbook (11.23)

7

attribútumaik keresésére, mivel az elnevezések általában elég beszédesek és az elem

konkrét nevének ismeretében könnyebben lehet további információkhoz jutni más

forrásokból, akár az Internetről.

8

II. Active Directoryban tárolt adatok kezelése

Ebben a fejezetben bemutatom, hogy a különböző típusú Active Directoryban

tárolt, vagy tárolható adatot alapértelmezés szerint milyen eszközökkel lehet kezelni.

1. Active Directoryhoz kapcsolódó szolgáltatások adatai

Az Active Directory hálózati erőforrásokról tárol információt, ebbe nem csak a

felhasználók és fizikai hálózati eszközök tartoznak bele, mint egy számítógép vagy

nyomtató, hanem a hálózati szolgáltatások, pontosabban a DHCP és DNS is. Valamint

az Active Directory-t kiegészítő talán legerősebb eszköz a Group Policy.

a) DNS kezelése

Ahogy az I.1 fejezetben írtam, lehetőség van a DNS Active Directoryba

integrálására7. A megoldás előnye, hogy a teljes tartományban, illetve

tartományerdőben szinkronizálódnak a DNS beállítások, így távoli gépek esetén is

használhatjuk a helyi DNS szervert. További előnye a megoldásnak, hogy a DNS

kezelésére továbbra is használhatjuk a korábbról jól ismert konzolt. Továbbra is

megmarad a lehetőség bejegyzések kézi felvételére, de a legcélszerűbb az adatok

dinamikus kezelése. Ebben az esetben adminisztrátori beavatkozás nélkül működhet a

névfeloldás akár éveken keresztül.

b) DHCP kezelése

A DNS-hez hasonlóan a DHCP szerverek kezelése sem változik a integrálás

után. Mivel a címkiosztás helyi feladat és távoli telephelyeken szükségtelen állandó

jelleggel tárolni az aktuális licenceket, ezért ezek nem is tárolódnak az Active

Directory-ban. Tárolásra kerül viszont a szerver számos adata, így az MMC konzolban

könnyedén meg lehet találni a távoli DHCP szervereket, megnyitni őket és elvégezni a

szükséges beállításokat. A mindennapos adminisztrátori tevékenységben tehát

továbbra is a címkiosztási stratégiától függ a munka mennyisége.

c) Csoportházirendek kezelése

A csoportházirendeken keresztül lehet számítógépek és felhasználók egy

csoportjára különböző beállításokat érvényesíteni. Alapértelmezésben az egyes

konténer típusú objektumok tulajdonságlapján lehet menedzselni az objektumhoz

csatolt házirendeket, illetve közvetlenül innét lehet szerkesztésre megnyitni az egyes

házirendeket. Ez a kezelés kényelmetlen, nehézkes és nehezen áttekinthető. Erre a

problémára a Group Policy Management Consol ad megoldást, ami egy Microsoft által

7http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsbb_act_zyjb.

mspx?mfr=true

9

2. kép. – Felhasználó tulajdonságlapja

fejlesztett MMC beépülő modul8. Segítségével jól áttekinthető fa szerkezetben

láthatjuk az egyes házirendek becsatolását, lehetőség van HTML alapú riport

generálására, jogosultságok állítására, illetve a házirendek érvényesülésének

modellezésére. Végső soron kevés új funkciót tartalmaz, de a meglevőket olyan

áttekinthető struktúrában teszi elérhetővé, hogy a házirendek kezeléséhez nehezen

nélkülözhető eszköz.

2. Active Directory törzsadatai

Az Active Directory alapvető feladata

a felhasználók és hálózati erőforrások

hitelesítése, valamint adatok, kiegészítő

információk és bizonyos tevékenységeket

megkönnyítő objektumok adatok tárolása.

Ezen túl támogatni kell az elosztott

működést, valamint elég általános, hogy

Windows alapú rendszerekben a levelezést

Exchange szerverrel valósítják meg, ezért az

ide kapcsolódó adatokkal is foglalkozni

kell.

a) Felhasználók

A felhasználók és számítógépek

beépülő modul segítségével láthatjuk a kialakított szervezeti egység hierarchiát, ebben

találhatjuk meg a felhasználókat. A felhasználók tulajdonságlapján körülbelül 70

attribútum beállítására van lehetőségünk alapértelmezésben (2. kép), Exchange

kiegészítés telepítése után ez a szám meghaladja a 100-at. Ezek az attribútumok

magukba foglalják a legfontosabb felhasználóhoz kapcsolható információkat és jól

strukturálva jelennek meg grafikus felületen. Ez a megjelenítési mód, illetve

szerkesztési lehetőség a legtöbb esetben elegendő, de az attribútumok több mint fele

nem érhető el közvetlenül.

b) Számítógépek, Csoportok, Kontaktok

A számítógépek, csoportok és kontaktok adatainak kezelése is ugyanolyan

koncepció szerint történik, mint a felhasználóké. A legfontosabb attribútumok a

tulajdonságlapon közvetlenül elérhetők és beállíthatók. Azonban az objektumhoz

tartozó attribútumok több mint fele itt sem érhető el közvetlenül.

8http://www.microsoft.com/downloads/details.aspx?FamilyId=0A6D4C24-8CBD-4B35-9272-

DD3CBFC81887&displaylang=en

10

c) Objektumok tetszőleges attribútumának módosítása

A Windows Server support tools eszközei között található az ADSI Edit9 eszköz,

mely alkalmas bármelyik objektum megkeresésére, hozzá tartozó attribútumok

megjelenítésére és módosítására. Az eszköz grafikus felületét az MMC konzol

biztosítja, ennek megfelelően bal oldalon fa szerkezetben láthatjuk az egyes

objektumokat, jobb oldalt pedig a kiválasztott objektum attribútumait. Az egyes

objektumok tulajdonságlapján pedig szerkeszthetjük az attribútumok értékeit.

3. Active Directory adatkezelés hiányosságai

A számítógépek és felhasználók beépülő modul kényelmes, jól áttekinthető

grafikus felületet nyújt az objektumok egy részének kezeléséhez. Sok gyakori feladat

megoldására megfelelő megoldást kínál, viszont a használata során a következő

hiányosságokkal szembesülhetünk:

• Közel sem teljes körű, nem lehet megjeleníteni vele az attribútumok

jelentős részét valamint egyedileg definiált sémaelemeket.

• Nem ad lehetőséget a sémadefiníció szerinti típus ellenőrzésnél

összetettebb szintaxis ellenőrzésre.

• Nincs, illetve erősen korlátozott az automatizálási lehetőségek száma,

minden beállítást kézzel kell megcsinálni, ami sok attribútum esetén lassú

és nehézkes művelet lehet, ráadásul nagyban megnöveli a hiba

lehetőségét.

Az ADSI Edittel egy kicsit nehezebben áttekinthető grafikus felületű eszközt

kapunk, amely alkalmas bármelyik objektum módosítására. Azonban ennek az

eszköznek is számos hiányossága van:

• Használatához komolyabb szakértelem kell, mivel bármilyen

attribútumot közvetlenül állíthatunk be és ezzel akár a címtár

működésében is zavart okozhatunk.

• Ez sem ad lehetőséget egyéni szintaxis ellenőrzés bevezetésére.

• A sok attribútum között nehéz megtalálni amit keresünk, ha nem tudjuk

az attribútum pontos nevét.

• Nem kínál automatizálási lehetőségeket.

Mindkét eszköz közös tulajdonsága a grafikus felület, ami sok esetben hasznos,

de nem teszi lehetővé a műveletek megismétlését vagy tárolását. Kisméretű

szervezetek esetén, ahol ritkán kell új objektumot létrehozni, vagy csak kevés

opcionális attribútumot töltenek ki rendszeresen használhatók a grafikus eszközök, de

nagyméretű cégeknél, ahol több tucat attribútumot töltenek ki és napi rendszerességgel

9http://technet2.microsoft.com/WindowsServer/en/library/ebca3324-5427-471a-bc19-

9aa1decd3d401033.mspx?mfr=true

11

kell új objektumot rögzíteni csak valamilyen alternatív megoldás használható

hatékonyan. A későbbiekben ezen alternatív megoldások közül a Visual Basic

scriptekkel történő automatizálási lehetőségeket, illetve adatbeviteli módot mutatom be

részletesen.

12

III. Munkakörnyezet bemutatása

2008 Február 1.-től dolgozok Budapesten az Evosoft Hungary KFT.-nél

rendszergazdai pozícióban. A cég budapesti telephelyén körülbelül 500-an dolgoznak,

valamint Magyarországon van még egy telephely. Európa szerte a közvetlen üzleti

partnerekkel együtt összesen 11 telephelyen van jelen a cég, ezek közül a

legjelentősebbek a Nürnbergi és a Budapesti. Az Evosoft cégcsoport szinte kizárólagos

vásárlója a Siemens,10 ez biztos hátteret nyújt a cégnek és folyamatos növekedést tesz

lehetővé, így mára az Evosoft az egyik legjelentősebb Magyar szoftverház.

Az informatikai rendszer rendkívül sokrétű, habár alapvetően Windows

platformra épít, ezért az egész gerince egy Active Directory tartomány. Az Active

Direcroty-ban jelenleg több mint 2000 felhasználói fiók található, ez magában foglalja

a különböző servie accountokat és ideiglenes vendég accountokat is. Valamint közel

1500 számítógépet tárolunk, ez szintén magába foglalja a vendéggépeket, valamint a

szervereket is. Az Active Directory objektumokban számos kiegészítő adatot tárolunk,

melyek egy része cég, illetve telephely szintű, kötött szintaktikájú információ, ilyen

például a telephely kódja, felhasználóknál a cím, weblap címe, szervezeti egység és

még számos adat. Valamint tárolunk felhasználónként eltérő egyedi információkat,

például telefonszámot és az ország specifikus nevet. Utóbbira azért van szükség, mert

több nyelvben így a magyarban is vannak olyan speciális karakterek, amiknek az

olvasása vagy automatikus feldolgozása problémát jelenthet. Így összesen több mint

40 attribútumot kell beállítani egy felhasználónak, míg valójában 15 attribútumból

meg lehet határozni a többit, viszont a különböző rendszerek közti szinkronizáció miatt

feltétlenül szükségesek. Minden új felhasználó kézi felvitelénél ez túl sok felesleges

munkát és hibalehetőséget jelent. További nehézség az adatok naprakészen tartása,

egységes formátumok kialakítása és betartása, betartatása. Ugyanez a probléma, ha

nem is ilyen sarkítottan, de jelentkezik valamennyi objektum esetén, számítógépeknél,

kontaktoknál, sőt kis mértékben a csoportoknál is. Az adatok felvitele mellett komoly

probléma az adatok törlése is. Mivel az egyes objektumok között kapcsolatok állnak

fenn (pl.: a számítógépnek van managere), ha a kapcsolt objektum megszűnik a másik

hibás lesz és valamelyik szinkronizációs folyamat hibáját okozhatja.

A fenti problémákat nem lehet a hagyományos grafikus felületű eszközökkel

megoldani, csak valamilyen parancssori eszközön alapuló a cég speciális igényeihez

igazodó megoldás lehet rá képes.

10http://www.evosoft.hu/common/index_hu.html

13

IV. Active Directory programozási lehetőségeinek

bemutatása

Ebben a fejezetben szembeállítom a korábban bemutatott, GUI-n keresztül

kommunikáló eszközöket az alternatívaként használható parancssor vagy script alapú

megoldásokkal.

1. Parancssori eszközök

A Microsoft részéről folyamatosan volt egy olyan törekvés, hogy a különböző

technológiákat ne csak grafikus felületről lehessen kezelni, hanem parancssori

eszközökkel is konfigurálhatók és használhatók legyenek. Ez a Windows 2008 szerver

esetén vált teljessé, amit már kizárólag parancssorral, grafikus felület nélkül is lehet

telepíteni és a legtöbb szerver funkciót használni. Az Active Directory esetében

tulajdonképpen a teljes parancssoros konfigurálhatóság már Windows 2000 szerveren

megvalósult. A legfontosabb parancssori eszközök a következők:

• DSADD11: Új objektumokat hoz létre a címtárban.

• DSGET: Objektum tulajdonságait kérdezi le és listázza ki a képernyőre.

• DSMOD: Létező objektum valamely attribútumát módosítja.

• DSQUERY: Adott feltételeknek megfelelő objektumokat keresi meg a

címtárban.

• DSMOVE: Egy létező objektumot átmozgat egy másik konténerbe.

• DSRM: Töröl egy létező objektumot.

• CSVDE12: Megfelelő formátumú csv fájlokból tud importálni a címtárba,

vagy a címtárból ilyen fájlokba.

• LDIFDE13: LDIF (LDAP Data Interchange Format) szabványú fájlokat

tud importálni azokba exportálni és megfelelő paraméterezéssel törölni a

címtárból.

A DS (Directory Service) parancsok elsősorban batch fájlokban használhatók

bizonyos feladatok automatizált végrehajtására, vagy annak biztosítása érdekében,

hogy biztosan kitöltésre kerüljön minden szükséges attribútum. A batch fájlok

hátránya, hogy az egyes kézzel felvitt attribútumok szintakszisellenőrzése nehézkes

vagy egyes bonyolultabb feltétel esetén lehetetlen. Új gép felvitele:

DSADD COMPUTER „CN=TEST_PC,OU=TEST_OU,DC=EVO,DC=LOCAL”

11http://technet2.microsoft.com/windowsserver/en/library/714070bb-22a5-420b-ac0f-

2f7c558f82fa1033.mspx?mfr=true 12http://technet2.microsoft.com/WindowsServer/en/library/1050686f-3464-41af-b7e4-

016ab0c4db261033.mspx?mfr=true 13http://support.microsoft.com/kb/237677

14

A CSVDE parancs nagy előnye, hogy csv fájlokat használ, amit megfelelő

szeparátort választva akár Excelben is lehet szerkeszteni. Ez megkönnyíti az

adatbevitelt és akár szakértelemmel nem rendelkező személyek is elvégezhetik. Az

elkészült csv fájlok akár egyszerű szövegszerkesztőkkel is könnyen áttekinthetők és

szerkeszthetők szükség esetén és könnyedén archiválhatók későbbi hibakeresés vagy

statisztikakészítés céljából. Továbbá, mivel a CSVDE paranccsal nem lehet törölni,

ezért elég biztonságosnak is mondható

Az LDIFDE parancs elsősorban automatizált feladat végrehajtáshoz vagy a

CSVDE-hez hasonlóan kötegelt végrehajtásnál használható. Az importáláshoz illetve

exportáláshoz használható fájlok készítéséhez illetve helyes értelmezéséhez nagyobb

szakértelem szükséges, viszont szabványos formátuma (RFC284914) miatt akár LDAP

platformok közti átjárhatóságot is biztosít. Egy LDIF fájl valamint az importálása a

következőképpen nézhet ki:

DN: CN=MINTA BELA,OU=TEST_OU,DC=EVO,DC=LOCAL

CHANGETYPE: MODIFY

REPLACE: MOBILE

MOBILE: 06303245624

LDIFDE –I –F FILENAME –S HOST

Az LDIFDE legnagyobb veszélye abban áll, hogy alkalmas a címtárból való

törlésre is, egy törölt objektum pedig csak speciális eszközökkel és sok munka árán

állítható vissza.

2. Visual Basic Script bemutatása

A VB Script a Visual Basicen alapuló egyszerűbb programnyelv, melynek

fordítását Windowsban a WSH15 (Windows Scripting Host) végzi. A programozási

nyelv tulajdonképpen teljes értékű, mert megvannak mindazon elemei, amik egyetlen

komoly programozási nyelvből sem hiányozhatnak:

• Képes ciklusokat kezelni, elől és hátul tesztelős, valamint számláló

ciklust egyaránt.

• Két, három vagy sokágú elágazást lehet definiálni.

• Lehet akár többdimenziós tömböket létrehozni.

• Lehet függvényeket definiálni, így hosszabb kódot is átláthatóan megírni.

• Képes parancssori argumentumokat kezelni, valamint futásidőben

adatokat bekérni.

• Rendelkezésre állnak alapvető szám és szövegkezelő függvények.

14http://www.ietf.org/rfc/rfc2849.txt 15 http://msdn2.microsoft.com/en-us/library/9bbdkx3k.aspx

15

• Képes elérni és kezelni a Windows által szolgáltatott COM

objektumokat.

A széleskörű funkcionalitás ellenére a könnyű kezelhetőség biztosítása

érdekében, azonban bizonyos, csak a professzionális programnyelveket jellemző

tulajdonságokkal nem rendelkezik:

• Nem kezel pointereket.

• Nem használható polimorfizmus illetve öröklődés, valamint az operátor

túlterhelés.

• Nincs lehetőség összetett adatszerkezetek, rekordok készítésére.

• Nincs típusellenőrzés, sem explicit típus meghatározás.

Amint látható a nyelv legnagyobb előnye, hogy nem kell külön fordításról vagy

futtatókörnyezetről gondoskodni, mert a WSH helyben interpretálja közvetlenül a

kódot. Nincsenek köztes bináris állományok, header fájlok, vagy bármilyen csatolt

kód, ami a Windows rendszerek közti hordozhatóságot megnehezítené. Az igazi ereje

pedig a COM alapú technológiák, például WMI (Windows Management

Instrumentation) elérésében rejlik, mivel ezeken keresztül akár távoli gépek

rendszerszintű beállításait kérdezhetjük le vagy módosíthatjuk. Ilyen interfésszel

rendelkezik az Active Directory is.

3. ADSI bemutatása

Az ADSI16 (Active Directory Service Interface) egy Microsoft által kifejezetten

az Active Directoryhoz fejlesztett COM alapú interfész. Alapvetően a

címtárobjektumok programból történő menedzselésére fejlesztették ki, így lehetővé

teszi objektumok hozzáadását, módisítását és törlését. Maga az interfész nem kötődik

programnyelvhez egyaránt elérhető C, C++, Java, Visual Basic és Visual Basic Script

környezetből is.

a) Kapcsolat felépítése az Active Directory-val

Első lépésben csatlakozni kell egy ADSI kiszolgálóhoz, ezt meg lehet tenni egy

ADO kapcsolat felépítésével is, hiszen a címtár tulajdonképpen egy adatbázis. Ebben

az esetben a kiszolgáló típusát a kapcsolat létrehozása után a megnyitásakor kell

meghatározni:

SET OBJCONNECTION = CREATEOBJECT(“ADODB.CONNECTION”)

OBJCONNECTION.OPEN “PROVIDER=ADSDSOOBJECT;"

Azonban egy konkrét objektum elérésére hatékonyabb az ADSI saját megoldását

használni. Ehhez a GetObjet függvénnyel létre kell hozni egy kötést a címtár egy

objektuma és a program közt: 16http://msdn2.microsoft.com/en-us/library/aa772170.aspx

16

SET OBJDOMAIN = GETOBJECT(„LDAP://OU=TEST_OU,DC=EVO,DC=LOCAL”)

A paraméter első eleme határozza meg a szolgáltató fajtáját, ez Windows 2000

és újabb rendszerekben LDAP, Windows NT esetén WinNT, valamint támogatott még

a Novell Directory Services (NDS) és a Novell NetWare (NWCOMPAT). A paraméter

második fele pedig az objektum distinguished nevét tartalmazza.

A kapcsolat felépítése után lehet különböző műveleteket végrehajtani a

címtárban.

b) Objektumműveletek az Active Directory-ban

Az objektumok kezelését az ADSI tulajdonképpen az IADsContainer17

interfészen keresztül valósítja meg. Ez összesen tizenegy metódust tartalmaz, melyek

közül az egyik a GetObject, ami egy Active Directory objektum kötését valósítja meg.

Másik fontos metódus a create, ennek segítségével lehet új objektumot létrehozni

abban a konténerben amelyre a kötést csináltuk. Az újonnan létrejövő objektum

tulajdonságai teljesen üresek, illetve csak az alapértelmezett értékeket tartalmazzák:

SET OBJUSER = OBJDOMAIN.CREATE(„USER”,”CN=TEST_USER”)

Általában egy objektum felvételével egy időben szeretnénk kitölteni bizonyos

attribútumait is, erre a létrehozott objektumhoz tartozó változón keresztül, a Put

metódussal van lehetőségünk:

OBJUSER.PUT „HOMEPHONE”,”3615349136”

Mivel az Active Directory egy adatbázis érvényesülnek rá az alapvető adatbázis

kezelési elvek, az egyik ilyen fontos alapelv az atomosság. Ezért ha valamilyen

változtatással járó címtárműveletbe kezdünk mérlegelnünk kell, hogy mely

műveleteket tekintjük egy tranzakción belülinek és ezek végrehajtása után commit-olni

kell az adott objektum változtatásait:

OBJUSER.SETINFO

A már létrehozott objektumok attribútumait ugyanúgy a put metódussal lehet

módosítani, hiszen ez tulajdonképpen a már meglévő értéket írja felül, attól

függetlenül, hogy azt korábban már definiálta-e valaki vagy sem. Objektum

mozgatására viszont IADsContainer egyik metódusa használható, a MoveHere. A

grafikus Active Directory Users and Computers felületen lehetőség van a felhasználó

objektumok másolására is, azonban ez a lehetőség az NDS kiszolgáló esetében került

megvalósításra az ADSI-ban.

OBJOU.MOVEHERE „CN=TEST_USER,DC=EVO,DC=LOCAL”, VBNULLSTRING

Természetesen az objektumok törlését is támogatja az ADSI, a Delete függvény

segítségével. A törlés rendkívül veszélyes művelet, mivel nem visszafordítható és

17http://msdn2.microsoft.com/en-us/library/aa705985(VS.85).aspx

17

biztonsági azonosítóval (SID) rendelkező objektumokat újrakreálással nem lehet

pótolni, mivel az Active Directory ezeket az azonosítókat egyedileg generálja egy

olyan algoritmussal, amely világviszonylatban is csak kis eséllyel képzi kétszer

ugyanazt. Általánosságban elmondható, hogy ha egy objektumra már nincs

szükségünk, akkor is előbb tiltsuk le, majd csak bizonyos idő elteltével töröljük.

OBJUSER.DELETE „USER”,„CN=TEST_USER”

A fent bemutatott feladatok végrehajtásához azonban tudnunk kell, hogy

pontosan mi az objektum distinguised neve, ami tartalmazza az elérési útját is, ennek

meghatározása pedig nem várható mindig a felhasználótól, szükséges lehet valamilyen

keresési feltétel alapján történő meghatározására.

c) Keresés az Active Directoryban

A keresés az

Active Directory Users

and Computers

konzolban is

megvalósításra került

(3. kép), lehet menteni

a lekérdezéseket és

szükség esetén újra

futtatni őket. Az

objektumokhoz tartozó

attribútumok nagy

részére lehet keresni,

de néhány lényeges

kimaradt a lehetőségek

közül, például a számítógép „location” mezőjére nem lehet keresési feltételt létrehozni.

Ezen kívül a keresési feltétel megadására is szűkösek a lehetőségek.

Egyfelől a keresési lehetőség hiányossága miatt, valamint a keresés

eredményének további felhasználása miatt szükséges, hogy scriptből is tudjunk keresni

a címtárban. A kereséshez először fel kell építeni egy kapcsolatot a címtára

adatbázisával, majd el lehet végezni a keresést. A keresési feltételeket kétféle

dialektusban is definiálhatjuk. Az egyik lehetőség, az SQL dialektus18, ebben az

esetben az adatbázis kezelésből jól ismert SELECT parancsot használhatjuk a

fontosabb kiegészítéseivel. A példában látható lekérdezés az összes csoportot listázza

ki:

„SELECT ADSPATH,CN FROM 'LDAP://DC=EVO,DC=LOCAL' WHERE

OBJECTCATEGORY='GROUP'”

18http://msdn2.microsoft.com/en-us/library/aa746494(VS.85).aspx

3. kép. – Részletes keresés GUI-ja

18

A másik az LDAP dialektus, ebben az esetben tulajdonképpen az RFC225419

szabvány szerinti LDAP lekérdezést kell megírni:

„<LDAP://DC=EVO,DC=LOCAL>;(OBJECTCATEGORY=GROUP);

ADSPATH,CN;SUBTREE”

A lekérdezés felépítése elég egyszerű, az első rész a keresés célterületét

tartalmazza, a második a keresési feltételeket, a harmadik pedig azon attribútumok

felsorolása, amelyeket meg szeretnénk kapni. Az utolsó elem pedig a lekérdezés

hatókörét határozza meg. A példában ez a subtree, ami azt jelenti, hogy a célterület

alatti teljes fában keres. Ennek az elemnek érvényes értéke még a base és a onelevel.

A lekérdezést egy ADODB.Command objektumon keresztül hajthatjuk végre.

Ehhez az objektumhoz további tulajdonságokat állíthatunk be, amivel javíthatjuk a

lekérdezés teljesítményét illetve az eredmény kiértékelhetőségét. A fontosabb

tulajdonságok a következők:

• Asynchronous: Aszinkron végrehajtás, a végrehajtás nem várja meg a

teljes lefutást, hanem az első eredmény után elkezdődhet a feldolgozás.

• SearchScope: Szerepe ugyanaz, mint az LDAP lekérdezés utolsó

attribútumának, ha mindkettő be van állítva, akkor az LDAP lekérdezés

beállítása érvényesül

• SizeLimit: Definiálja az eredmény maximális méretét, ami jelen esetben

a visszaadott objektumok maximális számát jelenti.

• Sort on: Sorba rendezi a visszaadott rekordokat, szerver oldali támogatást

igényel.

• Time limit: A maximális idő, amíg a szerver a keresést végzi, ennek

elteltével befejezi a keresést és visszatér az addigi eredményekkel

• Timeout: A maximális idő amíg a kliens a szerver válaszára vár, mielőtt

megszakítja a keresést.

Az eddigiek alapján egy lekérdezés a következőképp nézhet ki:

SET OBJCONNECTION = CREATEOBJECT(“ADODB.CONNECTION”)

SET OBJCOMMAND = CREATEOBJECT(“ADODB.COMMAND”)

OBJCONNECTION.OPEN “PROVIDER=ADSDSOOBJECT;"

OBJCOMMAND.ACTIVECONNECTION = OBJCONNECTION

OBJCOMMAND.COMMANDTEXT = „<LDAP://DC=EVO,DC=LOCAL>;

(OBJECTCATEGORY=GROUP); ADSPATH,CN;SUBTREE”

OBJCOMMAND.PROPERTIES(“ASYNCHRONOUS”)=TRUE

SET OBJRECORDSET = OBJCOMMAND.EXECUTE

19http://www.faqs.org/rfcs/rfc2254.html

19

A lekérdezés eredménye egy recordset típusú objektumban kerül eltárolásra,

melyen a moveNext metódusával lehet végigmenni és a szükséges értékeket további

feldolgozás céljából kivenni belőle.

WHILE NOT OBJRECORDSET.EOF

WSCRIPT.ECHO OBJRECORDSET.FIELDS(„NAME”)

OBJRECORDSET.MOVENEXT

A keresés végén pedig természetesen le kell zárni az adatbázis kapcsolatot, hogy

a zárolt erőforrások felszabaduljanak.

A keresés végrehajtására többféle implementációs megoldás is létezik, azonban az átláthatóság kedvéért ajánlott ugyanazt a módszert használni minden csatlakozásnál.

20

V. Scriptekkel megvalósított feladatok bemutatása

Egy olyan nagyméretű cég, mint az Evosoft Hungary Kft. már nem teheti meg,

hogy az egyes informatikai folyamatok megvalósítását teljes egészében a

rendszergazdák belátására bízza. Egyrészt be kell tartani és be kell tartatni a

folyamatok során képzett adatokra vonatkozó formai és minőségi követelményeket,

másrészt meg kell valósítani a folyamatok nyomon követésének és hatókörök

ellenőrzésének lehetőségét. Emellett az egyre nagyobb felhasználói létszámhoz

kapcsolódó adatkezelést is meg kell oldani, hiszen majdnem minden felhasználóhoz

tartoznak olyan adatok, amik idővel változhatnak és az informatikai rendszerben is le

kell követni. Ilyen például a telefonszám, szobaszám esetleg a projekt, amin a

dolgozik.

A fent leírt problémák kezelésére az Evosoft Hungary Kft. egy saját eszköz

fejlesztésébe kezdett, ami SharePoint alapokon, webes felületet kínál a

felhasználóknak, az egyes folyamatok teljes életciklusát végigköveti, és csoport alapú

jogosultság kezeléssel elkülöníti hatásköröket és feladatokat. Ugyanakkor a folyamat

végén az Active Directory adatbázisban történő adatváltoztatás, valamint létrehozási és

törlési műveletek hagyományos script eszközökkel kerülnek megvalósításra. Habár a

SharePoint képes támogatni nem csak olvasási, hanem írási műveleteket is a

címtárban. Viszont az egyes funkciókat megvalósító scriptek az igényekkel együtt

változnak és ezeket a változásokat a rendszergazdáknak könnyebb scriptekben

implementálni, mint SharePoint oldalon.

1. Új felhasználó felvétele

A dinamikus növekedés miatt az egyik legmindennapibb, ugyanakkor nagy

figyelmet kívánó feladat egy új felhasználó felvétele.

a) A folyamat leírása

Új felhasználói fiók iránti igény többféleképpen keletkezhet. Egyik lehetőség,

hogy új alkalmazott kerül a céghez, akinek hozzáférésre van szüksége, másik

lehetőség, hogy valamelyik partner cég alkalmazottjának van szüksége bizonyos

hozzáférésekre és ezzel együtt felhasználói fiókra. Ezen túl pedig előállhatnak speciális

helyzetek, amikor nem valós személynek, hanem egy szolgáltatásnak kell account.

Valós személy esetén az igénylés először a HR osztályra fut be, ahol

összegyűjtik a szükséges adatokat, majd a kérést ezzel kiegészítve továbbítják az IT

felé. Az IT létrehozza az accountot a kezdő jelszót megbízható módon eljuttatja a

tulajdonosának. Ezzel a folyamat lezárul.

21

b) Korábbi megvalósítás

A korábbi megvalósítás

alapján a HR osztály egy

helpdesk ticketben kérte az IT-

t új felhasználói fiók

létrehozására, a tickethez pedig

excel táblában csatolta az

ehhez szükséges adatokat.

Több kollega esetén ez több

soros táblázatot jelentett,

aminek a szélessége közel két

képernyőnyi, ezért nehezen

olvasható volt, ráadásul

ugyanazokat az adatokat vittük

be kézzel ismét, amiket a HR

már felvitt, ez pedig dupla

hibalehetőséget jelent. A dupla

felvitel során az adatok

helyességét sem lehetett

ellenőrizni, mivel az eredeti

adatok kizárólag a HR számára

álltak rendelkezésre. Csak a

nyilvánvaló elgépelésekre derülhetett fény. Ezt követően az excel tábla adatainak

felhasználásával egy scripthez tartozó formot (4. kép) töltöttünk ki, amely elég

információt kért be ahhoz, hogy Active Directoryban minden szükséges adat kitöltésre

kerüljön. A form egy batch fájlt hív meg, ami bemenő adatként megkapja ezeket az

adatokat a többi szükséges mező tartalmát pedig ezek alapján feltölti. Ezen felül

létrehoz egy Exchange postafiókot a felhasználó számára, generál egy véletlen jelszót

és e-mailben elküldi a teljes rendszergazdai csapatnak. A service usereket a kollegák

közvetlenül az IT-tól kérték és ezeket a grafikus konzol felületen hoztuk létre, mivel

sokkal kevesebb kötelező attribútuma van, nem kapcsolódik hozzá postafiók és más

szervezeti egységhez tartozik.

c) Jelenlegi megvalósítás

A jelenlegi rendszer a korábban említett Share Point alapú webes felületre épül.

Ezen a felületen történik meg a kérvényezés, jóváhagyás és adatbevitel. A korábbi

folyamattal ellentétben csak egyszer, viszont minden lépésben megmarad a korábbi

ellenőrzési lehetőség. A folyamat egyes elemei utólag is lekérdezhetők, így a

személyes felelősség is teljes. Az egyes mezőkre jól testre szabhatók a különböző

szintakszis ellenőrzések, ezzel biztosítani lehet, hogy csak jól formázott adatok

4. kép. – Új felhasználó form

22

kerüljenek a címtárba. Az utolsó lépés azonban továbbra is egy script meghívása, ami

az összegyűjtött adatokat kiegészíti, létrehozza az objektumot és feltölti az

attribútumokat. Ennek a döntésnek a hátterébe az áll, hogy a rendszergazdák jól tudnak

batch fájlokat vagy vb scripteket szerkeszteni, viszont nem értenek a SharePointhoz.

Így ha a felvett adatok alapján valamit változtatni kell a létrejövő objektumon, akkor

elég egy scriptet módosítani és a SharePoint forráshoz nem kell hozzányúlni. Ilyen

változtatás lehet az alapértelmezett levelezési listákban történő változás esetleg új

szervezeti egységek létrejötte vagy azok átnevezése. A korábbi batch fájl alapú

megoldás továbbra is használható lenne, de elég lassú a futása elsősorban a

tartományvezérlők közti replikációra várakozás miatt. Valamint hosszabb, nehezebben

kezelhető kódot jelentett. Ezért szükségesnek éreztük a script Visual Basic script

formában történő újraírását, valamint újragondolását. Az új script első lépésbe egy az

egyben ugyanazt valósítja meg, mint amit a script csinál. Az új script megírása során

kihívást jelentett a megfelelő postaláda létrehozása. A rendelkezésemre álló

tesztrendszerben ugyanis nincs Exchange telepítve, éles hálózatban pedig további

óvintézkedésekre volt szükség Active Directory-t módosító és teszteletlen script

futtatására. Ezért a scriptet munkaidőn kívül előzetes biztonsági mentést követően

tesztelhettem sikeresen. A script a folyamatosan megfogalmazódó igényeknek

megfelelően folyamatos fejlesztés alatt áll. A teljes változat a CD mellékleten

található.

d) Továbblépési lehetőségek

A jelenlegi rendszer nagyban kielégíti a felmerülő igényeket, ugyanakkor a

felhasználó teljes életciklus-követésére nincs felkészítve. Előfordul, hogy

gyakornokként, vagy külsős vállalkozóként kezdő kollegák státusza állandósul, ebben

az esetben minden ehhez kapcsolódó attribútumot meg kell változtatni, ilyen és ehhez

hasonló változtatásokra nincs felkészítve a jelenlegi megoldás. Másrészt a külsős

vállalkozókkal a HR osztály nem vagy csak kis mértékben tartja a kapcsolatot, ezért a

jóváhagyási folyamatot is át kell dolgozni. A legégetőbb problémákra megfelelő

választ jelent a jelenlegi megoldás, a továbbfejlesztése valószínűleg akkor kezdődhet

el, ha minden kritikus IT folyamat legalább ilyen színvonalon implementálásra kerül.

2. Új számítógép felvétele

A felhasználók létszámával párhuzamosan nő a gépek száma is, ezeknek a

nyilvántartása és menedzselése szintén komoly feladatot jelent egy több száz gépből

álló rendszerben.


Új számítógép igénylése egy beszerzési folyamattal indul, ami IT szempontból

lényegtelen. A sikeres beszerzési folyamat eredményeként a raktárba kerül a

23

számítógép és erről értesítést kap a beszerzést kezdeményező ágazatvezető. Ez után a

sikeres beszerzésre hivatkozva ír egy ticketet az IT-nak, amivel kéri a gép telepítését és

kiadását valamelyik kollegának. A telepítés és tartományba léptetés korrekt

elvégzéséhez szükséges ismerni az igényelt szoftverek listáját, a gép új gazdájának

nevét és ágazatát. A gép menedzserének beállítjuk a megfelelő személyt, az ágazatnak

pedig az IP cím és gépnév megadásánál van jelentősége. A gép előkészítése után

kiadjuk a gazdájának, aki ezután beállíthatja a saját munkakörnyezetét.

b) Korábbi megvalósítás

Korábban új számítógép felvitelére semmilyen informatikai támogatás nem

tartozott. Minden számítógép objektumot kézzel a grafikus felületen kellett felvinni.

Ez ugyan nem járt jelentős többletmunkával, mert az attribútumok közti összefüggés

minimális. Viszont a kézzel megadott gépnevek és IP címek időnként ütközéshez

vezettek, a hosszabb ideig kikapcsolt, esetleg időlegesen másik telephelyen működő

gépek címe és neve esetleg újra kiosztásra kerülhetett. A precíz rendszergazdai

munkának köszönhetően ritkán fordultak elő ilyen incidensek, viszont minden ilyen

eset felesleges kellemetlenséget jelent, ami megfelelő támogatással jól kivédhető.

További problémát jelentettek az ideiglenes vendég gépek kezelése. Ezeknek a

gépeknek is létrehoztunk egy objektumot a címtárban, letároltuk benne néhány fontos

adatukat és beállítottunk számukra egy lejárati időt. Mivel az Active Directory nem

támogatja közvetlenül a számítógép objektumok accountjának lejárását, ezért a már

lejárt vendéggépekhez tartotó objektumokat kézzel kellett megkeresni és eltávolítani.

Még nagyobb problémát jelentett, ha a lejárati idő a rutinszerű adatfelvitel miatt nem

került rögzítésre az objektumban.


A fenti problémák, illetve gyengeségek, valamint az egységes eszköz iránti igény

miatt az új számítógép felvétele folyamat is helyet kapott az IT Webworks SharePoint

alapú felületén. A felület jelen esetben is biztosítja a szintaktikahelyes adatfelvitelt, az

életciklus követés lehetővé teszi a felelőségek megállapítását, a háttérben futó script

pedig elvégzi a tényleges adatmódosítást az Active Direcroryban. A script létrehoz egy

számítógép accountot és feltölti a SharePointtól származó adatokkal. Az új script

megvalósítása során folyamatos egyeztetést igényelt, hogy a bekért adatok alapján a

végleges attribútumokat SharePointból vagy scripttel állítsuk elő. A végleges döntést

az indokolta, hogy a scriptben megvalósított formázásokat későbbiekben a

rendszergazdák könnyedén tudják módosítani. Ha ezeket a funkciókat a SharePoint

valósítaná meg, akkor egy kisebb változás is a web programozó segítségét igényelné.

Ebből a szempontból a legfontosabb jelenleg a location mező, ami kötött szintaktika

alapján tartalmazza a gép MAC címének és IP címeinek összerendelését adott

telephelyeken. Ugyanis ezen információk alapján egy script végzi az egyes siteok

24

DHCP szervereibe a rezervációk betöltését. Az ideiglenesnek megjelölt gépek lejárati

dátumát is ebben a mezőben kell megadni és a lejáratot a DHCP-ből való kikerülés

biztosítja, hiszen a lejárt gép nem kaphat IP címet, így nem érhet el semmilyen hálózati

erőforrást. Az új megvalósítással együtt más telephelyeken hasznosnak bizonyuló

gyakorlatot is átveszünk. Ilyen például, hogy az egyes gépen raktári számát is tároljuk

az Active Directoryban, a könnyebb azonosítás érdekében. Egy ilyen nagy gépparkkal

rendelkező cégnél ugyanis az lehet az első probléma, hogy valamilyen módon

meghatározzuk egy gép hardverkiépítését. Jelenleg a legjobb módszer a leltári szám

alapján történő meghatározás. A script jelenleg működő verziójának részletei a I.

Mellékletben olvashatók. A teljes script a mérete miatt csak a CD mellékleten kapott

helyet.


A teljes életciklus követés ebben az esetben is egy későbbi megvalósítandó

feladat. Célszerű lenne valamilyen módon kapcsolatot állítani a beszerzési

adatbázissal, így az új számítógép felvitele lényegében már a beszerzésnél elkezdődne,

majd a gép fizikai megérkezéséről automatikusan értesülne az IT, így felhasználói

jelzés nélkül lehetne felkészíteni a gépeket és a kollegáknak csak az átvételkor kéne

ténylegesen megjelenni az IT-n. Továbbá célszerű lenne átgondolni a jelenlegi IP cím

kiosztási stratégiát és annak megfelelően változtatni a magán a computer objektumon,

illetve a DHCP rezervációkat készítő scripten.

3. Felhasználók személyes adatainak megváltoztatása

Az Active Directoryban tároljuk a felhasználók telefonszámát, szobaszámát,

valamint a telephelyet ahol dolgoznak. Ezek olyan adatok, amik idővel változhatnak és

meg kell kísérelni nyomon követni az Active Directoryban is. Az itt tárolt adatok

szolgálnak alapul egyes telefonos címjegyzékekhez, illetve szerepet játszanak a

Siemenssel történő kommunikáció során is. Ezért törekednünk kell rá, hogy legalább a

kommunikáció szempontjából kritikus telefonszám bejegyzések meglegyenek és valós

adatokat tartalmazzanak.


A felhasználói profil eleinte az alapértelmezett adatokkal kerül feltöltésre, mivel

sokszor nem lehet előre tudni, hogy milyen telefonszámot kap az új kollega, sem azt,

hogy melyik szobában kerül elhelyezésre a munkaállomása. Ezért az adatokat a

kollegák önkéntes alapon szolgáltatják, elvileg folyamatosan, a változások hatására, de

a valóságban sajnos csak időnként külön kérésre frissítik az adatokat. Ez a megoldás

nagyban épít arra, hogy mindenkinek érdeke, hogy helyes adatok jelenjenek meg vele

kapcsolatban.

25

b) A korábbi megvalósítás

Korábban a probléma megoldására egy egyszerű eszközt használtunk (5. kép),

melyben a telefonszámot és a szervezeti egységet lehetett megadni, az itt kitöltött

adatok pedig azonnal az Active Directory-ba kerültek. Mint az látható felhasználónév

megadása nem szükséges, mivel a program mindenkinek a saját felhasználói

kontextusában futott, ami lekérdezhető, így

egyértelmű volt, hogy melyik objektumot kell

módisítani. Jogosultsági problémák nincsenek, mert a felhasználónak joga van

módosítani a saját bejegyzését a címtárban.


A jelenlegi megvalósításnak is az IT WebWork keretein belül adtunk helyet.

Egyfelől bővített funkcionalitással megtartjuk a korábbi megvalósítást, tehát a

felhasználóknak továbbra is lehetősége lesz manuálisan a saját adatait megadni,

másfelől pedig a telefonszámok követését megpróbáljuk megvalósítani a telefon

menedzsment folyamaton belül. Mivel ez az egyetlen folyamat, amihez az IT

közreműködése valóban nélkülözhetetlen, hiszen a telefonszámok kiosztását mi

végezzük. A többi adatot azonban más folyamatokon keresztül nem tudjuk követni és

továbbra is csak az önkéntes információadásra számíthatunk, amihez a magunk

részéről egy átlátható kényelmes felületet és megbízhatóan működő hátteret

biztosítunk. A korábbi megvalósításhoz képest a szobaszám nyilvántartása jelenik meg

újdonságként, a szervezeti egység megadásának lehetőségét viszont elvesszük. A

jelenlegi megvalósítás a II. mellékletben olvasható.


Egyenlőre a jelenlegi megvalósítás kielégíti azokat az igényeket, amiket

támasztottunk a folyamat felmérése és a feladat specifikálása közben. A telefonszámok

automatizált frissítésével nagy előrelépést tettünk a személyes adatok frissen tartása

irányában, a többi adatot azonban továbbra is kézzel kell bevinni. A hálózati

infrastruktúra fejlesztésével folyamatosan újragondoljuk a jelenlegi megoldást és a

lehetőségeknek megfelelően újabb adatok automatikus kezelését fogjuk megvalósítani.

4. További IT WebWorks funkciók

A fenti két folyamat és megvalósításhoz hasonlóan minden IT folyamatot

igyekszünk az egységes SharePoint felület alatt elhelyezni. A projekt jelenleg is

folyamatban van és sorra valósítjuk meg a különböző IT feladatokhoz tartozó felületet.

A folyamatok feltárása és megvalósítása folyamatos iteratív tevékenység, melynek

során az egyes folyamatokat megkíséreljük optimalizálni is, ezzel együtt a különböző

adatbázisokban, így az Active Directoryban tárolt adatok körét és módját is

5. kép. – Data collector

26

felülvizsgáljuk. A jelenlegi tervek szerint összesen több mint harminc kifejezetten IT

szolgáltatás fog megjelenni a weblapon, ezzel nagyban javítva az IT szolgáltatás

minőségét, valamint az SLA-nak való megfelelést. A következőkben röviden

bemutatok néhány további folyamatot:

• Telephone management: Új telefon kiadásánál, vagy a tulajdonos

cserélődésénél indul ez a folyamat. Az Active Directory-t azért érinti,

mert az IP telefonok be vannak jegyezve a címtárba egy számítógép

objektummal, amiben tároljuk a telefon gazdáját, valamint MAC és IP

címét.

• Domain Group management: A csoportok kezelésével kapcsolatos

kéréseket kezeli. Elsődleges feladata a biztonsági csoportok tagságának

változtatása a megfelelő jóváhagyások után. Mivel bizonyos csoportoknál

ehhez nincs szükség az IT engedélyére, ezért ez a feladat szinte teljes

egészében függetlenedhet a rendszergazdáktól.

• Mail redirection: Folyamatosan merül fel olyan igény, hogy a céges

postafiókba érkező levelezést irányítsuk át egy másik e-mail címre. Ezt

rendszergazdai jóváhagyással szinte teljesen automatikusan lehet

megcsinálni egy scriptekkel támogatott rendszerben.

Az IT WebWorks teljes jelenlegi állapotára elmondható, hogy nagy előrelépést

jelent az IT folyamatok automatizálásában, nyomon követésében és ezzel a minőségi

rendszergazdai munka végzésében. Azonban minden funkcióhoz biztosítani kellene a

teljes életciklus követést, egységesíteni kellene az összetartozó funkciók felületét és az

ezekhez a funkciókhoz tartozó scripteket. Így fejlesztői, rendszergazdai és felhasználói

oldalról is egységesebb, áttekinthetőbb lenne a rendszer működése.

5. LDAP kereső

Ahogy korábban is említettem az Active Directory grafikus eszközeibe beépített

keresési lehetőségek nem mindig elégítik ki az igényeket. Egyfelől hiányzik bizonyos

attribútumokra keresésének lehetősége, például az utolsó bejelentkezés ideje szerint

nem lehet keresni, illetve nem lehet szerepeltetni a keresési eredmények között.

Másrész a legnagyobb hiányosság, hogy a keresési kritériumoknál nem lehet megadni

a tartalmazást, mint kritériumot. Így ha egy attribútum valamely részletére szeretnénk

keresni, akkor nem marad más lehetőség, mint scriptet írni.

a) A korábbi megvalósítás

Egészen a közelmúltig nem volt mód egyedi lekérdezések készítéséig csak a

beépített grafikus felületen lehetett lekérdezéseket definiálni. Ezek a legtöbb igényt

maradéktalanul kielégítették, a többi ilyen jellegű problémára pedig más forrásból

kerestek megoldást. Azonban a cég dinamikus növekedésével egyre gyakrabban és

27

egyre komolyabb kérdés merül fel melyre valamilyen Active Directory lekérdezés

adhat könnyen áttekinthető választ. Ezeket a lekérdezéseket a közelmúltban egyedileg

az igényeknek megfelelően írtam meg, illetve paramétereztem fel. A folyamatosan

jelentkező igények arra ösztönöztek, hogy egy univerzálisabb, gyorsan használható

scriptet készítsek, amiben csak a lekérdezést kell megadni, a többi műveletet

tetszőleges számú és fajtájú attribútummal automatikusan elvégzi.

b) Jelenlegi megvalósítás

Egy ilyen keresés során ugyanazokat a feladatokat kell végrehajtani, csupán

mások a feltételek, illetve a keresési feltételek alapján kell az eredményként megjelenő

táblázat oszlopait meghatározni. A feladat végrehajtására lehet írni egy általánosan

használható scriptet, aminek az egyetlen bemenete maga a kereső string, illetve annak

változó attribútumai. Ez lehetne SQL dialektusú SELECT lekérdezés vagy LDAP

dialektusú lekérdezés, attól függően, hogy melyik kényelmesebb vagy célszerűbb.

Mivel az LDAP lekérdezés jobb teljesítményt nyújt és szélesebb körűen használható,

ezért a megvalósításban emellett döntöttem. Habár az SQL utasítások szélesebb körben

ismertek, az LDAP dialektikát sem nehéz elsajátítani, az attribútumok ismerete pedig

ugyanúgy szükséges SQL lekérdezés írásához is.

A lekérdezés eredményét a script egy text fájlba menti, az eredménytábla

oszlopait tabulátorokkal elválasztva. Ezt a formátumot Excelben könnyedén meg lehet

nyitni és további szűréseket, kereséseket végezni vagy akár statisztikai adatokat

kinyerni.

A script az eredménytábla oszlopainak nevét és számát a felhasználói inputként

megadott lekérdezésből határozza meg. Ehhez a scripten belül bizonyos mértékig

értelmezni kell a lekérdezést, a keresett attribútumokat egy tömbbe rakni és a

kimenetben ezt felhasználni. A kész script teljes egészében olvasható a III.

mellékletben.

c) Továbblépési lehetőségek

A script jelenleg egyszerű parancssoros felületről érhető el a bemenetét

parancssori argumentum szolgáltatja. Ez a megoldás ugyan nem a leg tetszetősebb, de

jelenleg tökéletesen megfelel az IT-n jelentkező igények kielégítésére. A későbbiekben

esetleg célszerű lehet egy webes vagy valamilyen más grafikus felületen

megvalósítani, de mivel alapvetően rendszergazdáknak készült az eszköz, ezért ez a

változtatás nem kritikus vagy sürgető. További problémát jelent olyan attribútumok

lekérdezése, amik nem replikálódnak a tartományvezérlők közt. Ilyen például az utolsó

bejelentkezés időpontját tároló attribútum. Ezen túl, problémásak azok az attribútumok

amik nehezen olvasható formában tárolják az információt, ilyen például az account

lejárati ideje, amit az Active Directory 1601 január 1 óta eltelt időként tárolja 100

nano-szekundumban megadva. Jelenleg ezeknek az attribútumoknak a kezeléséhez

28

nem használható a script. Ezen túl a felmerülő hibákat, problémákat folyamatosan

javítom és próbálom igazítani a scriptet az újabb felmerülő igényekhez.

6. További scriptekkel megvalósított feladatok

Az előzőekben bemutatott komolyabb feladatokon kívül folyamatosan meg

kellett oldani kisebb problémákat, illetve további feladatok várnak megoldásra.

• Komoly kihívásnak indult az a feladat, amelyik azt fogalmazta meg, hogy

a cégnél egyre sűrűbben előforduló notebookokon céges hálózaton kívül

aktiválódjon a tűzfal, hálózaton belül pedig kapcsoljon ki. Ezt a funkciót

a Windows tűzfalra a Group Policy támogatja, viszont a notebookok és

az asztali gépek különválasztását is meg kellett oldani, mivel néhány

asztali gépen nem várt működéssel járt a Policy engedélyezése. A

megoldást a Group Policy-hez rendelhető WMI filter jelentette. Más

módon ezt a problémát nem vagy csak nagyon nehezen lehetett volna

megoldani.

• A support tevékenység során folyamatosan szükség lehet a felhasználók

gépein az alapértelmezett megosztások elérésére (pl.: C$, D$, ADMIN$).

Azonban ezek néha valamilyen okból letiltásra kerülnek, így

elérhetetlenné válnak. Amennyiben az csak akkor derül ki, amikor

valóban szükség lenne rá, akkor feleslegesen sok időt rabol a valódi

probléma megoldásától. Ezért készítettem egy scriptet, ami ellenőrzi,

hogy a gépeken minden alapértelmezett megosztás elérhető legyen.

Eredményként a hibás gépek nevét egy fájlba írja a script és megelőző

jelleggel ezeken a gépeken újra engedélyezzük illetve engedélyeztetjük

ezeket a megosztásokat.

• Ahogy az új számítógép felvitele folyamatnál említettem a vendéggépek

számára is hozunk létre accountot a címtárban, viszont egy adott

mezőben ezeknek beállítunk egy lejárati időt is. Ez a beállítás azonban

néha elmaradt, ami oda vezetett, hogy becslésünk szerint több tucat

vendég gép volt az Active Directoryban lejárati dátum nélkül,

feleslegesen. A közel egy teljes C típusú címtartományt kitevő

vendéggépek átböngészése hosszadalmas munka lett volna, azonban egy

scripttel a hiányzó dátumokat néhány másodperc alatt pótoltam. A

következő lépés a lejárt bejegyzések törlése lesz, de ez inkább csak az

áttekinthetőség érdekében szükséges.

• Komoly problémát jelent, hogy a kollegák egy része a számítógépét nem

kapcsolja ki, sem éjszakára, sem hétvégére. Részben talán lustaságból,

részben pedig a távmunka szükségessége miatt, ez milliós töbletköltséget

jelent csak az energiaköltségben. A Wake On LAN (WOL) technológia

megoldást kínál kikapcsolt gépek ébresztésére, de hibernált vagy alvó

29

gépek ébresztését Windowsból is engedélyezni kell. Ennek a

problémának megoldása a következő hetek feladata lesz. A megoldás

után reményeink szerint a kötelező géplekapcsolás, illetve takarékosabb

energiaellátási séma alkalmazása éves szinten milliós nagyságrendű

megtakarítást hozhat.

Ahogy ebből a négy egyszerű példából is látszik a scriptekkel olyan kis

mindennapi bosszúságot okozó problémákat lehet megoldani, amik egy nagyobb

infrastruktúra esetén akár egy teljes embert is foglalkoztatnának főmunkaidőben. Így a

hatékony scriptelés csökkenti a költségeket és időt ad az adminisztrátoroknak, ezzel

teret enged a komolyabb fejlesztési és kutatási tevékenységnek.

30

VI. A scriptek jövője

Jó és hatékony scriptek készítése folyamatos feladat egy közepes vagy

nagyméretű informatikai rendszerrel rendelkező szervezet esetében. Legyen szó akár

logon/ logoff scriptekről, akár egyedi lekérdezésekről vagy a géppark egy részén vagy

egészén érvényes konfigurációs változtatásról. Ugyanis a rendszergazdai feladatok

csak egy bizonyos határig végezhetők el a grafikus felületen, a többit szinte kizárólag

scriptekkel lehet megvalósítani.

1. A VB Script jövője

Maga a Visual Basic Script és a hozzá kapcsolódó interfészek régóta részét

képezik a Windows rendszernek és hasznos segítőtársat jelentenek a rendszergazdai

feladatok gyors és hatékony elvégzésében. A legjelentősebb interfészek a WMI és az

ADSI folyamatosan fejlődnek és a lehetőségek széles tárházát nyújtják a

rendszergazdáknak. A VB Script eltűnésére az újabb scriptelési technológiák

megjelenésével sem kell számítani rövid időn belül, mivel széles körben elterjedt

technológiáról van szó és jellemzően a funkciók megvalósításához a gyártó független

CÍM szabvány alapú eszközöket használjuk fel. Tehát bátran állíthatom, hogy a VB

Script a rendszeradminisztráció terén élő technológia és a következő néhány évben

még biztosan nem szorítja ki teljesen a Microsoft új script platformja a PowerShell.

2. A PowerShell

A PowerShell a Microsoft új parancssori illetve script eszköze, programnyelve.

A Windows 2008 szervernek, illetve Windows Vistának gyárilag része, a korábbi

operációs rendszerekhez pedig külön telepíthető. Microsoft alapú technológiákat

használó rendszerek esetében hosszabb távon várhatóan ez fogja felváltani a VB

Scripteket, valamint parancssoros felületének köszönhetően részben a hagyományos

parancssor szerepét is átveheti. Alapértelmezésben több mint 130 parancsot tartalmaz,

valamint alkalmas a WMI, ADSI és egyedi interfészek elérésére, ez utóbbit plug-inek

importálásával. A PowerShell mindemellett új névkonvenciókat használ, ezáltal ugyan

egységesebbek lettek az elnevezései, de a használatához az egész nyelvet teljesen az

elejétől kell tanulni, ez pedig várhatóan még egy ideig távol tartja az adminisztrátorok

egy részét az új eszköztől. Várhatóan a következő években a PowerShell és a VB

Script egymással párhuzamosan lesz jelen, de lassan és biztosan a PowerShell teret fog

nyerni és a nagyobb szervezeteknél idővel egyeduralkodóvá válik.

31

VII. Összefoglalás

A következőkben összefoglalom az általam végzett munka jelentőségét, szerepét

a rendszeradminisztrátori munkában, valamint az elért eredményeket bemutatom azok

jelentőségét a mindennapi munkavégzésben.

1. Elért eredmények összegzése

Az elmúlt három hónapban megismerkedtem azokkal az alapvető problémákkal,

amikkel egy közepes méretű informatikai rendszer üzemeltetése során nap mint nap

találkoznak az adminisztrátorok. Megismertem az ezekhez a problémákhoz tartozó

üzleti és informatikai folyamatokkal, valamint azokkal a vezetői megfontolásokkal,

amik mentén ezek kialakításra kerültek, illetve amik alapján folyamatosan

újragondoljuk őket. Ezzel párhuzamosan megismertem a Visual Basic Script nyelvet,

valamint az ADSI és WMI interfészeket és felismertem, hogy hatékony megoldást

nyújthatnak több aktuális problémára. A munkám során szerzett scriptelési

tapasztalatot rendszeresen használom a napi problémák megoldásában is.

A legfontosabb eredménye a tevékenységemnek, hogy a scriptek használata

versenyképes alternatívaként jelentkezik a legtöbb probléma megoldására és sokszor

valóban ez mutatkozik a legjobb és leggyorsabb megoldásnak. Ezzel értékes

munkaórákat spórolunk meg, amit más fejlesztésekre, szakmai fejlődésre vagy az IT

szolgáltatásminőségének javítására használhatunk fel. Emellett folyamatban van egy

nagyszabású projekt, az IT WebWorks, ami szinte az összes IT folyamat egységes

felületre helyezését célozta meg. Ebben a munkában a scriptekért felelős

rendszergazdaként veszek részt és az első néhány folyamat végleges megvalósításához

már rendkívül közel állunk, jelenleg széleskörű tesztelési munkákat végezzük.

2. Következtetések, javaslatok

Kétségtelen, hogy a scriptek alkalmazása nélkülözhetetlen már egy kisméretű

informatikai rendszerben is, gondoljunk csak a logon/logoff scriptekre. Ezek azonban

általában kötegelt állományok és csupán az alapértelmezett parancssori eszközöket

használják. Ezek az eszközök illetve az általuk nyújtott lehetőségek azonban

megfigyelésem szerint elégtelenek egy nagyobb rendszerrel rendelkező szervezet

esetében. Az Evosoft Hungary Kft.-nél jól megfigyelhető, hogy a régi örökségből

származó batch scriptek szűk keresztmetszetet jelenthetnek a rendszer

működtetésében. Például a DHCP rezervációkat kezelő parancssor alapú script-

gyűjtemény jelentősen lassabban fut, mint ami kívánatos lenne. Ezeknek a scripteknek

az újragondolása a következő hónap munkája lesz. Továbbá a group policy-k

alkalmazásának testre szabásához is WMI szűrők használhatók, így a gépek

tulajdonságai alapján lehet a szabályokat érvényesíteni. Komoly problémát jelent a

startup és logon scriptek túlzott elnyúlása is, ez részben természetes következménye az

32

egyre növekvő cégben jelentkező újabb és újabb elvárásoknak, részben pedig a

parancssori eszközök alacsonyabb hatékonysága és a változásmenedzsment hiányára

vezethető vissza. Egy jól átgondolt és dokumentált VB Script a várakozások szerint

jobb teljesítményt és gyorsabb gépindulást adhat.

A fent leírt példák is mutatják, hogy professzionális scriptek alkalmazása nagyon

hasznos, sőt nélkülözhetetlen egy komoly informatikai rendszerben. Várhatóan az

Evosoft Hungary Kft. is folyamatosan átáll erre a gyorsabb és hatékonyabb

megoldásra, valamint a későbbiekben felmerülő ilyen jellegű igényeket elsősorban

scriptek segítségével valósítja meg. Igaz, hogy ez a rendszergazdai csapattól és

különösen a scriptekkel kiemelten foglalkozó adminisztrátortól egy új kompetencia

megszerzését követeli, de a folyamatos képzés szükséges velejárója ennek a

szakmának.

Az előző fejezetben is említettem már azt az új technológiát, ami várhatóan

idővel a VB scriptek helyére léphet, a PowerShell-t. Ez egy olyan technológia, amit

feltétlenül érdemes figyelemmel kísérni és megtanulni, bár az alkalmazása csak

Windows 2008 szerver és Windows Vista környezetben lehet teljes körű.

Mindenképpen ajánlott a váltásra olyan mértékben felkészülni, hogy a PowerShell által

nyújtott új lehetőségeket minél előbb ki tudjuk használni. Ennek érdekében az év

második felére beütemeztünk egy Microsoft tanfolyamot ebben a témakörben.

33

VIII. Köszönetnyilvánítás

Ezúton szeretnék köszönetet mondani munkám során nyújtott hathatós

segítségért:

• Szalai Lászlónak az évek óta tartó folyamatos motiválásért és szakmai

támogatásért.

• Az Evosoft Hungary Kft-nek és különösen Arnhoffer Edit IT managernek

az infrastruktúra biztosításáért.

• Az Evosoft Hungary Kft. rendszergazdai csapatának a folyamatos

szakmai támogatásért.

34

IX. Irodalomjegyzék

(1) Ed Wilson: Microsoft Windows Scripting Self-Paced Learning Guide

(2) William R. Stanek: Microsoft Windows Parancssor

(3) http://www.microsoft.com/technet/scriptcenter/default.mspx 2008.

április 2.

(4) http://www.microsoft.com/technet/scriptcenter/webcasts/archive.mspx

2008. április 10.

(5) http://msdn2.microsoft.com/en-us/library/ms675085(VS.85).aspx 2008.

április 10.

(6) http://www.microsoft.com/technet/scriptcenter/guide/sas_vbs_jcoq.msp

x?mfr=true 2008. április 14.

(7) http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx?mf

r=true 2008. április 15.

(8) http://msdn2.microsoft.com/hu-hu/library/aa772170(en-us,VS.85).aspx

2008. április 15.

(9) http://visualbasic.about.com/od/learnvbscript/ss/vbsadmin.htm 2008.

április 19.

active directory címtár adatainak kezelése scriptek...

Documents