MonthApril 2008

Mindenféle gondolatok az előadások kapcsán

Bár nagyon úgy nézett ki, hogy ezt a Lurdy-házas előadást kihagyom, valahogy csak sikerült úgy haladnom a dolgaimmal, hogy mégis belefért.
Aztán végül mégsem, ebédszünetben jött egy telefon a munkahelyemről, amely miatt át kellett szerveznem a napomat – és emiatt a délutáni előadások kimaradtak. Remélem, nem sértek vérig senkit, de nem kaptam sírógörcsöt: eleve is a délelőtti programért mentem. (Tudom, a délutániak is fontosak voltak, de jelenleg nincsenek benne a látóteremben.)

Szóval NAP. Szentgyörgyi Tibor előadása jó volt. Pedig ebből a nehéz, száraz anyagból nem kis kihívás jó előadást összerakni. És elhangzott a legfontosabb mondat, amelynél legszívesebben kirohantam volna az előadóhoz és csókot nyomtam volna a homlokára: a NAP nem arra való, hogy megbízhatóan kizárjuk a rosszfiúkat a hálózatunkról – sokkal inkább arra, hogy segítsünk a jóindulatú felhasználóinknak abban, hogy akaratlanul se tudjanak fertőzni.
Természetesen be lehet annyira keményíteni a rendszert, hogy jó legyen a rosszindulatú bepróbálkozások kiszűrésére is. Igaz, jó bonyolult lesz. És csak egyszer – hangsúlyozom egyszer – forduljon elő, hogy Vezérigazgató Bálintot, vagy a fiát, vagy a kutyáját kizárjuk… és már bonthatjuk is le az egészet. Ha meg kivesszük a körből a teljes pereputtyot, beleértve a vezérigazgató-helyetteseket, meg az egész csókos bagázst… akkor akkora lyukat ütöttünk a szuperbiztonságos rendszerünkön, hogy az egész értelmét vesztette.
Nem egyszerű. Nekem egy Dilbert rajz jutott róla eszembe: a figura ott ült, a világ _egyetlen_ videótelefonja előtt és várta, hogy valaki felhívja. Dogbert meg visított, hogy mennyire hülye is az emberiség. Aztán később megállapította, hogy ha nem lennének ilyen borzasztóan debil példányok közöttük, akkor sehová sem fejlődnének.
Azaz itt is el kell telnie bizonyos időnek, amíg ez az egész elképzelés beépül a köztudatba, elfogadhatóvá válik. Addig a pionírok szívnak.

A második blokk megint nem az egyszerű témák közé tartozott. PKI. Az egyik legborzasztóbb dolog az informatikában. Elmesélem, én eddig mi mindenen rágtam át magam, ahhoz, hogy értsek a területhez:

  • Éveken keresztül többször is nekifutottam mindenféle doksiknak, whitepaper-eknek. Habár egyik ügyfelünknél sem volt működő PKI rendszer, de éreztem, hogy kell a tudás. Természetesen nem jutottam semmire.
  • Elmentem Marciékhoz PKI tanfolyamra. Ennek megvolt az az előnye, hogy azóta a mosógép vezérlőtárcsájával is tudok RSA kulcspárokat generálni – de a tanúsítványkezelés politika része ugyanolyan homályos maradt számomra, mint korábban volt.
  • Mit ád az ég, egyik ügyfelünknél ki kellett alakítani egy kellően biztonságos, hosszútávú PKI rendszert – és mindenki másnak pont mozijegye volt. Ha azt mondom, hogy habosan izzadtam, igen finom voltam. És még egyáltalán nem vagyok biztos abban, hogy ez egy jól működő rendszer lett. Pedig ezerrel használják.
  • Elmentem meghallgatni Marcit, mit mond, milyen új nézőpontot mutat be, milyen kapaszkodót ad a gondolkodásomnak. Nos, ez után az előadás után már valószínűleg a digitális tűzhelyen is menni fog az RSA kulcsgenerálás – de a politika rész, a tanúsítványok kezelése, az egész unalmas, de roppant nehezen járható adatbáziskezelés továbbra is homályos maradt.

Az ezzel az egésszel a baj, hogy… minden. Azt mondják, hogy aki ilyen rendszert tervez, hihetetlenül, baromira, átkozottan, borzasztóan jó nostradamusnak kell lennie, hiszen előre kell látnia mondjuk húsz évet, hogy ezalatt milyen igények lehetnek… mindezt úgy, hogy machetével is nehezen lehet vágni, akkora a köd. Ja, és hibázni sem lehet, mert akkor az egész megy a levesbe – adatvesztés, állásvesztés. Mission Impossible. Ahhoz, hogy valaki értsen hozzá, nemes egyszerűséggel fejre kell állítania néhány cég informatikáját. A sikeres PKI tervező életútját füstölgő bizalomromok szegélyezik.
Azt hiszed, szórakozok, direkt túlzó képeket vázolok fel. De jó is lenne.
Tessék, olvasd végig ezt a négy részes cikket. Eleinte minden világos. Aztán megjelennek a szkriptek, valami borzalmas sorokkal. Mik ezek? Nem kapsz rá választ. És ez úgy általában jellemző az egész katyvaszra. Írd be azt, hogy certutil bla-bla – aztán minden jó lesz. Beírod… de nem érted. Oké, egy idő után rájössz, hogy a certutil -setreg az registry bejegyzés lesz… meg ráérzel arra is, hogy a grafikus felület nem ritkán átkozottul tré, tehát a legegyszerűbb lefordítanod fejben a -setreg paramétereit és közvetlenül beírni a registrybe… már ha éppen megy. De ez akkor is gányolás, kókányolás, hályogkovácsolás. És ez jellemző az egész miskulanciára. Ezt állítsd be itt, azt állítsd be ott, az egyikhez registry turka kell, a másikhoz ini fájl editálás, ahhoz meg mmc konzol, ide másolj be szövegesként megnyitott fájlból base64 kódolású cuccost, de szedd ki az első x és az utolsó y karaktert – és persze az egészhez nincs értelmes leírás. Legalább annyi, hogy mit miért kell csinálnod. Aztán jönnek a rettenetes rövidítések: CRL, CDP, AIA, CPS… meg az egész ködös társaság. Melyik fontos? Melyik inkább technikai (azaz szigorúan betartandó), melyik inkább politikai (azaz működést nem annyira befolyásoló, inkább bizalmi problémát jelentő)? Amikor először belevágtam, pörgött az ujjaim alatt az acronymfinder, de az se hozott biztonságot. Ez egy szétfolyó, vázatlan, átláthatatlan és megfoghatatlan katyvasz. Mintha a markodba borítanának egy liter vizet, hogy formálj belőle húsvéti nyulat. De ha nem lesz tökéletes még a fülében is a szőrszál, akkor lelövik a kutyádat.

Aztán mindenki meglepődik, hogy az informatikusok idegenkednek a PKI rendszerek bevezetésétől.

No, ezek után voltam kíváncsi, mihez kezd Marci a rendelkezésére álló egy órával. Mit mondjak, nagyokat hasított bele a beton sűrűségű ködbe… de fény még továbbra sem jött át.

Kinyírják SIS-t?

A szemetek.

De tényleg. Egy kicsit nem figyelek oda és majdnem lemaradtam egy érdekes fejtegetésről. Arról van ugyanis szó, hogy létezik az Exchange adatbáziskezelésében egy metódus, az a neve, hogy Single Instance Storage, azaz SIS. Vén, mint az országút, már az Exchange 4.0-ában is létezett. Az elv lényege az, hogy ha egy levelet több embernek is elküldtek, akkor adatbázison belül csak egy példány létezett belőle, a felhasználók postafiókjaiból pedig pointer mutatott erre az egy példányra.

Nos, az Exchange2007 esetében úgy döntöttek, hogy nem igazán van szükség SIS-re. Miért is? Először is a – maximálisan lehetséges – 50 adatbázis miatt. Ha ugyanis kellően nagy postafiókokat szeretnénk adni a felhasználóinknak, azt úgy tudjuk csak elérni, ha sok adatbázist hozunk létre. Mennyi értelme van ilyenkor a SIS-nek? Elég halvány, tekintve, hogy lecsökken annak az esélye, hogy a címzettek ugyanabban az adatbázisban lesznek. Ráadásul nézzük csak meg, mit nyerünk, mit vesztünk? Nyerünk merevlemezterületet, vesztünk adatkezelési sebességet. Mennyibe kerül a merevlemezterület? Bagó. Mennyire fontos a levélkezelés sebessége? Baromira.
Nem jó üzlet.

Ezért a fiúk nemes egyszerűséggel úgy döntöttek, hogy az Exchange2007-ben a levelek törzsére megszüntetik a SIS-t, egyesül a csatolásokra hagyják meg. És erősen gondolkodnak, mi legyen vele a következő verzióban.

Az a szerencsétlen public folder…

Rájár a rúd, rendesen. Persze, igazából még a Microsoft se nagyon tudja, mit csináljon vele.

Amikor kijött az Exchange Server 2007, azt mondták, hogy már csak megtűrt lett szegény. Nem is kapott GUI-t, csak parancssort. Aztán felhorgadt a népharag, az Sp1-ben beépült az Exchange Management Console-ba. De mindig ott lógott fölötte Damoklész kardja, hogy majd az E14-ben, na ott már úgy ki lesz hajítva az udvarra, mint macskát anyagcserélni.
Ehhez képest tegnap jelent meg egy írás az Exchange blogon, mely teljes mellszélességgel kiáll a Public Folderek mellett. Hogy persze. Támogatjuk. De azért ismerkedjél bőszen a Sharepointtal, Kedves Rendszergazda.
Nem egyszerű helyzet.

De nem is erről akartam írni. Hanem arról, hogy mi is a helyzet a public folder referrals beállításokkal az Exchange 2007-ben. Azaz mennyire lesznek virulensek a public folder eléréseink.

Messziről fogok nekifutni. Egészen az Exchange 2000/3 termékvonaltól. Sőt.
A Public Folderek némileg egyedi figurák egy Exchange rendszerben. Van nekik adatbázisuk, a szokásos .edb formátumban. Meg lehet adni, mely szervereken legyenek. De nem csak adatból állnak, fontos komponensük a hierarchia is. Igen, a folderszerkezet. Ez, ha jobban megnézzük, egy halom pointerből áll, ezek mutatnak a bináris .edb fájl megfelelő pontjaira.
A lényeg az, hogy külön-külön élnek. A hierarchia egységes, organizáció szinten. De adat, az nem feltétlenül kell, hogy ott legyen minden szerveren.

Ismerkedjünk meg még a Routing Group fogalmával. Ez gyakorlatilag a Telephelyet jelenti, Exchange szlengben. A Routing Group Connector (RGC) pedig a kapcsolat közöttük – azaz a gyenge, vékony, lassú vonalakkal elválasztott hálózati entitások között.

Nézzünk egy példát. Az Outlook kliensemből létrehozok egy új Public Folder alfoldert valahol, jó mélyen a struktúrában. Hol is fog ez létrejönni? Természetesen annak a szervernek a Public Folder adatbázisában, amelyiken a postafiókom van. De az új alfolder a hierarchiában egyből megjelenik, látni fogják Alaszkától Hódmezővásárhelyig, mindenhol.
Mi történik, ha valaki le akarja kérni a tartalmát? Ez leginkább attól függ, hogy én, mint adminisztrátor, mit állítottam be. Ugyanis a Public Foldereknél alfolder szinten állíthatjuk, hogy mely szervereken legyen belőlük példány – és mikor történjen a példányok között a replikáció.
Mondjuk, az van beállítva, hogy ne replikálódjon sehová. Ebben az esetben azok járnak jól, akiknek ugyanazon a szerveren – nevezzük AL-nak – van a postafiókja, mint nekem. Ők egyből hozzá fognak férni az alfolder tartalmához. Mi van, ha valakinek az én Routing Groupomban lévő másik szerveren van a postafiókja? Hát, a hierarchiát látja… és az ún. public folder referral megadja, hogy mely szerverek PF adatbázisában létezik ennek az alfoldernek tartalma is. Tehát ők szépen átvándorolnak AL-hoz a tartalomért.
Mi van, ha valaki egy másik Routing Groupból akarja elérni az alfolderemet? Attól függ, mi van beállítva az RGC-n. Ugyanis létezik egy egyállású kapcsoló: Enabled/disabled public folder referral. Ha engedélyezve van, akkor a másik RG-ből eljönnek az én szerveremhez a tartalomért. Ha nincs, akkor hibaüzenetet kapnak vissza.
Jó ez? Nyilván nem – és az egésznek nem is az a célja, hogy hibaüzenetet kapjunk vissza.
Az elsődleges cél a gyenge vonal védelme az elárasztás ellen. Ha a vonal annyira nem gyenge, akkor engedélyezhetjük a PF referral-t, nem fogja padlóra küldeni, ha sokan lesznek kíváncsiak az alfolderemre. Ha viszont gyenge, akkor más stratégiát kell választanunk: azt mondjuk, hogy az alfolderemet lereplikáltatjuk egy másik szerverre a távoli RG-ban, méghozzá úgy, hogy csak este engedélyezünk replikációs forgalmat. Ekkor nyugodt szívvel tilthatjuk le a konnektoron a PF referral engedélyezést, hiszen minden lent lesz a lenti szerveren, ami kell. Nagyjából 24 órán belüli állapotban.

Így játszhattunk a régebbi Exchange rendszerekben. De mi van az Exchange 2007-ben? Hát, Routing Group, például nincs. Értelemszerűen RGC sincs. Akkor mi szabhat határt a public folder referralok burjánzásának?
Az RGC utódja. Az Active Directory IP Site link.

Tippeljünk!
Vajon az Active Directory IP Site linken tudunk-e Exchange Public Folder referral-t szabályozni?

  • Nem. Hogyan nézne már az ki? AD linken Exchange tulajdonság? Olyan lenne, mint hajszárítóval permetezni.
  • Miért ne? McGywer például egészen biztos, hogy permetezett már hajszárítóval. Gondoljunk csak bele, Exchange telepítés előtt lemegy egy sémamódosítás. Miért ne módosíthatná ez az IP Site link objektum definícióját úgy, hogy kiegészíti Exchange specifikus tulajdonsággal? Hiszen meg is teszi, ha EMS-ből lefuttatjuk a get-help set-adsitelink -detailed parancsot, láthatjuk, hogy az Active Directory IP Site linknek lett olyan tulajdonsága, hogy exchangecost, meg maxmessagesize.

Nos, melyikre tippelsz?
Sajnos az első. Elméletileg semmibe sem került volna felvenni egy igen/nem jellegű tulajdonságot az IP Site link objektumra – de nem tették. Csak saccolni tudok: tervezéskor nem is számoltak a Public Folderekkel. Csakhogy az élet máshogy döntött, Public Folderek bizony lesznek.
Korlátozhatatlanul.
Akkor mégis, mit tehetünk, hogy a Patagóniában létrehozott alfolder tartalmáért ne menjen el mindenki, aki pl. a calcutta-i részlegünknél dolgozik?

  • Előremenekülünk. Ha eddig nem is volt a cégünknél megtervezett PF replikáció, akkor mostantól lesz. Megtervezzük, hogy minden Active Directory site-on, ahol van legalább egy Exchange 2007 szerver, melyiken legyenek ott a site leginkább használt Public Folderei. A replikációt mindenhol úgy időzítjük, hogy akkor történjen, amikor a vonalon alacsony a forgalom.
  • Minden postafiók adatbázison van egy olyan beállítás, hogy azoknak, akiknek ebben az adatbázisban van a postafiókjuk, melyik legyen a default public folder adatbázisuk. Értelemszerűen ez mindenhol a Routing Group PF szerverére kell, hogy mutasson.
  • Természetesen ezzel nem zártuk ki a Routing Group-ok közötti PF elérések forgalmát. De minimalizáltuk. Ha már megtiltani nem tudjuk.