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
a) A folyamat leírása ................................................................................... 22
b) Korábbi megvalósítás .............................................................................. 23
3
c) Jelenlegi megvalósítás ............................................................................ 23
d) Továbblépési lehetőségek ....................................................................... 24
3. Felhasználók személyes adatainak megváltoztatása ................................... 24
a) A folyamat leírása ................................................................................... 24
b) A korábbi megvalósítás ........................................................................... 25
c) Jelenlegi megvalósítás ............................................................................ 25
d) Továbblépési lehetőségek ....................................................................... 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.
a) A folyamat leírása
Ú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.
c) Jelenlegi megvalósítás
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.
d) Továbblépési lehetőségek
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) A folyamat leírása
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.
c) Jelenlegi megvalósítás
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ó.
d) Továbblépési lehetőségek
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.