Active Directory címtár adatainak kezelése scriptek segítségével

Átírás

1 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 Active Directory bemutatása Active Directory séma bemutatása Active Directory séma kezelése... 6 II. Active Directoryban tárolt adatok kezelése Active Directoryhoz kapcsolódó szolgáltatások adatai... 8 a) DNS kezelése... 8 b) DHCP kezelése... 8 c) Csoportházirendek kezelése 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 Active Directory adatkezelés hiányosságai III. Munkakörnyezet bemutatása IV. Active Directory programozási lehetőségeinek bemutatása Parancssori eszközök Visual Basic Script bemutatása ADSI bemutatása a) Kapcsolat felépítése az Active Directory-val b) Objektumműveletek az Active Directory-ban c) Keresés az Active Directoryban V. Scriptekkel megvalósított feladatok bemutatása Új felhasználó felvétele a) A folyamat leírása b) Korábbi megvalósítás c) Jelenlegi megvalósítás d) Továbblépési lehetőségek Új számítógép felvétele a) A folyamat leírása b) Korábbi megvalósítás

3 c) Jelenlegi megvalósítás d) Továbblépési lehetőségek Felhasználók személyes adatainak megváltoztatása a) A folyamat leírása b) A korábbi megvalósítás c) Jelenlegi megvalósítás d) Továbblépési lehetőségek További IT WebWorks funkciók LDAP kereső a) A korábbi megvalósítás b) Jelenlegi megvalósítás c) Továbblépési lehetőségek További scriptekkel megvalósított feladatok VI. A scriptek jövője A VB Script jövője A PowerShell VII. Összefoglalás Elért eredmények összegzése Következtetések, javaslatok VIII. Köszönetnyilvánítás IX. Irodalomjegyzék

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-et 2. 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

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ülnek 3. 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 kapcsolatban 4. 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 felosztani 5. 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ú

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ása 6. 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 6 Robbie Allen, Laura E. Hunter: Active Directory Cookbook (11.23) 6

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. 7

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ára 7. 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 7 mspx?mfr=true 8

9 fejlesztett MMC beépülő modul 8. 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. 2. kép. Felhasználó tulajdonságlapja 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. 8 DD3CBFC81887&displaylang=en 9

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 Edit 9 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

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. 11

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

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: DSADD 11 : Ú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. CSVDE 12 : Megfelelő formátumú csv fájlokból tud importálni a címtárba, vagy a címtárból ilyen fájlokba. LDIFDE 13 : 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 f7c558f82fa1033.mspx?mfr=true

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 (RFC ) 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: 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 WSH 15 (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

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 ADSI 16 (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:

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 IADsContainer 17 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, 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

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 3. kép. Részletes keresés GUI-ja 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 dialektus 18, 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'

18 A másik az LDAP dialektus, ebben az esetben tulajdonképpen az RFC 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

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. 19

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. 20

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 ITt ú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 4. kép. Új felhasználó form á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 ben 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 21

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 22

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 23

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. 24

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 5. kép. Data collector 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 25

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 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 26