MonthFebruary 2008

H@x0r

Holnap Ma lesz az utolsó nap a Netacademia Ethical Hacking tanfolyamán. Mivel ez már csak olyan fél nap lesz, nagy változások nem várhatóak – így megírhatom már most is a véleményemet.

Kezdjük azzal, hogy ennek a tanfolyamnak nagyjából annyi köze van a hackeléshez, mint a Bükkben vezetett busztúrának a hátizsákos gyalogtúrához. Ha most azt hiszed, jól megkritizáltam az egészet, akkor tévedsz: ez egy pontos, alaposan megcsiszolt hasonlat volt. Ha ugyanis körbevisznek a buszban, akkor futólag látod a Bükk részeit. És ha tetszik, akkor egy-két hét után már jöhetsz is vissza a zsákoddal – és lassan, de alaposan járhatod be a terepet.
Viszont hacker ettől a tanfolyamtól nem leszel. De még csak a vizsgától sem. Azt nem adják ilyen könnyen.
Akkor mit ad a tanfolyam? Némi szemléletet, rövid áttekintéseket – és hatalmas adag tananyagot. Lássuk a szikár számokat: a csomagban hat könyv van: 2500 oldalnyi tankönyv, 500 oldalnyi laborgyakorlat. A mellékelt cédéken olyan 3 GB hacker/cracker segédprogram, egy vizsgasegédlet, két cédényi videó és egy cédéről boot-oló linux masina található. Hatalmas anyag, az oktató meg sem próbálta teljes mennyiségben leadni. Mentünk, ahogy tudtunk, belekaptunk ebbe is, abba is. Megjegyzem, inkább network alapokról volt szó, mint konkrét hekkelésekről, dehát ugye arra épül minden. Viszont láttunk azért olyat is, a laborgyakorlatokon pl. egymás gépeit borogattuk meg.
Ami engem nagyon zavart, az a naftalinszag volt. Olyanokat hekkeltünk, hogy IIS5, IE6, SQL2000, a vizsgakérdések között is volt olyan, amelyik 2002-es(!) Windows patch-re vonatkozott. Értem én, hogy ismerkedésre jó ez is, de szívesen láttam volna, hogy mi a helyzet a mai rendszerekkel.

Mondjuk, valamennyit azért láttam.
Például Zsíros Petya előadása ütött rendesen. Nulláról indulva írt PHP-ben egy BOF exploitot, részletesen elmagyarázva, mit miért csinál. Én ugyanis eddig azt hittem, hogy a buffer overflow töréseket zöld marslakók írják – az emberek ugyanis tuti képtelenek ekkora precizitással átsurranni egy-egy kapun. Most már tudom, hogy ember is képes erre, ha van elég agya.
De megemlíthetném Agot is, aki wifi törésekről tartott egy igen érdekesnek tűnő előadást. (Azért fogalmaztam ilyen óvatosan, mert én valahol a WEP hiányosságainak boncolásakor leestem a szekérről – és az még igencsak az eleje volt. Innentől gerillamódszerekkel értettem meg részleteket az előadásból – pont annyit, hogy adott esetben a google segítségével azért boldoguljak.)

És ha már az oktatóknál járunk, ejtsünk szót a fő oktatóról is: Jan szemmel láthatóan értett az anyaghoz, jól is adott elő – de szerény véleményem szerint engedhette volna lejjebb is azt az ekevasat a mélyszántás előtt. Ahogy elnéztem, nem volt olyan inhomogén a társaság, mint általában egy tanfolyamon szokott – senki sem bánta volna, ha jobban belemegyünk néhol az anyagba. Így viszont ez az egész inkább csak vizsgára felkészítésnek tűnt.

Apropó, vizsga. Habár a tananyag rettenetesen nagy, de a vizsga ránézésre nem tűnt vészesnek. 150 kérdés, 4 óra, azt hiszem, 120 jó válasz kell. Átfutottam a próbaverziót, nagyon sok kérdés kilogikázható, ráadásul jól be is határolható, mely anyagokra kell rágyúrni a könyvből.

De szándékosan nem akarok vizsgázni belőle.
A vizsga ugyanis veszélyes – különösen, ha sikerül. Onnantól kezdve az emberen számonkérik a tudást. A vizsga speciel nem csak arra jó, hogy kompetenciát mutassunk egy-egy pályázaton. A vizsga szakértőt csinál belőlünk – olyan szakértőt, akinek kutyakötelessége naprakész tudással rendelkezni az adott területen, mert bármikor igényt tarthatnak rá. Emiatt van az, hogy én már évekkel ezelőtt megfogadtam, hogy csak abból vizsgázok, amivel hosszútávon is foglalkozni akarok. Márpedig a hekkelés nem az. Jó képben lenni, jó ismerni a technikákat – de nem jó szakértőnek lenni belőle.

Konnektória

Ez az írás már hetek óta itt aszalódik a piszkozatok között, de valahogy úgy éreztem, hogy ábra nélkül nem igazán lenne élvezhető. (Nem mintha azzal valami nagy mámor lenne.)
Mostanra készült el.

Nagyítás

Értő szemű olvasók gondolom kapásból kiszúrják a hibát: igen, egy budapesti Exchange2000 szerver és egy vidéki Exchange 2000 szerver ugyanabban a routing groupban van, dacára annak, hogy egy igen vékonyka WAN vonal feszül a két telephely között.
Hát, igen. Exchange 2000 alatt még lehetett ilyesmit csinálni. Az Exchange 2007 alatt már nem annyira, az ugyanis routing group-ok helyett az AD telephelyeket használja.
Ezzel el is érkeztünk a rajzon található kaotikus állapothoz.

Igen, kénytelen voltam extra konnektorokat beledöfni az organizációba – ha el akartam kerülni azt, hogy vidék a vidékkel Budapesten keresztül levelezzen. A postafiók migrációról már nem is beszélve.

Össze is raktam. Át is migráltam 3 szerencsétlent a BP2-XCH2000 szerverről a BP2-XCH2007 szerverre. Meg is halt a levelezésük, legalábbis bizonyos irányokba.

Mi történhetett?
A Winroute látott valami konnektorszerűséget, méghozzá működőnek látta. Csak éppen unknown objektumként. De azért arra küldte a leveleket – csakhogy azok nem jutottak el odáig. (Megragadom az alkalmat, hogy itt is rúgjak egyet a Message Tracking Centerbe. Sokkal rosszabb lett, mint az Exchange 2003-ban volt.)
A levelek ott álltak a queue-ban. Dühömben levertem minden extra konnektort – a levelezés hamarosan be is indult, igaz bejárta a fél világot a levél, mire kitalált.
Menetközben jött az újabb sokk: a tesztuserek emailcíme evolválódott. kovacs.bela@leany.hu -> bela@leany.hu

Slatty. Ez az a hang volt, amikor a fejemre csaptam. Hát, persze. Email address policy – mint korábban is írtam, adatbázis szintre. Csakhogy a userek átkerültek másik szerverre, másik adatbázisba, mely még nem szerepelt a házirendben. A default policy meg – most nem részletezendő okból – ilyen idétlenke.
Kivettem, hogy ne essen a userekre a policy, emailcím visszaír, eredmény vár.
Semmi.
Szokásos körök: RUS (bár itt már nem kellene), OAB generálás, OAB lekérés gyakorisága 1 perc, SCP? Mindegyik CAS-ra leellenőriztem. Jöhetett a szokásos keresztúton kecskeáldozás, közben állandóan nyomkodva az outlookban a download OAB gombot. Semmi.
Adsiedit, összes DC-ről megnézve a proxyaddress tulajdonságot. mindenhol jó. Ldp-vel belekukkoltam a GC adatbázisába, jó.
Hol a francba ragadt be az a hülye emailcím?
Aztán egyszer csak eltűnt a 3 tesztuser a GAL-ból. Újabb rángatózások, majd leesett, hogy most ért körbe a lebontott konnektor hatása. (Ekkor indult be a levelezés is.)
Új konnektorokat álmodtam magamnak. (Más színes tintákkal szokott.)
Semmi javulás.
Küldtem néhány tesztlevelet. Megkapta. A benne lévő cím jó. Reply. Elment. Majd visszajött, hogy nincs olyan címzett, hogy bela@. Miért??
Aztán valahonnan beugrott, hogy minden felhasználónak, még a postafiókkal nem rendelkezőknek is van olyan tulajdonságuk, hogy ‘mail’. Eddig úgy tudtam, hogy csak megjelenítésre szolgál. Azért ránéztem. Bakker, ott volt. Létezik ugyanis egy automatizmus, mely amikor policy változtatja meg a default emailcímet, akkor átírja ezt a tulajdonságot is. Ha én, manuálisan változtatom meg, akkor nem. És úgy látszik, mégis van szerepe.
Átírtam, megrángattam a szálakat, hamarosan meg is jelentek a jó címek a GAL-ban. Méghogy öreg kutya nem tanul új trükköket….
De az OAB letöltés továbbra sem ment. Google. Néhány óra szenvedés. Aztán összedobtam egy új profilt (az egyik tesztalanynak) a gépemen. Működött. Tehát az outlook profilban romlott el valami. Remek. Új profil, kismillió új beállítások, új ost. Mondjuk, ki nem szarja le. Működik.

Csak a nyolc terminálablak bezárása eltartott egy negyedóráig.
Hajnali fél kettő. Mehettem haza.

Mondjuk nem aludtam jól. Valami zavart. De még reggel is. Éreztem, hogy nem kerek a történet.

Másnap reggel folytattam a levélküldési teszteket. Volna. De nem működött sem a Free/Busy, sem az OAB elérésem. (Ja, nem mondtam: az egyik teszt postafiók az én tesztfelhasználóm volt.) Agyalások, gyötrések. Valamiért nem fordul a dög a CAS-hoz – legalábbis nem jön fel a selfsigned certre figyelmeztető ablak. Próbaprofil másik – tegnap szintén elkutyult – felhasználóval. Működik. Azaz az én mapi profilomba ragadt be valami szemét. Csináltam magamnak egy újabbat. Aztán a sokadik OAB letöltési kisérletnél egyszer csak megjelent a CERT ablak. Onnantól már a régi profilomból is ment. Idióta.

Most már tényleg levelezési tesztek. Gáz: nem tudtam vidékre levelet küldeni. Visszafelé ment. Nyomozás. Winroute: A konnektor megint ledőlt. Letöröltem a francba. Nem változott semmi. Ilyen nincs. Most már csak az IP site link ívelt át a telephelyre, a címtár replikáció működött, de az Exchange routolás nem. Set-adsitelink, költségek különválasztása, akkor sem.

Ekkor tettem meg azt, amit jóval korábban kellett volna: oda-vissza telnet 25. Lefelé nem ment, lent viszont egyik szerverről a másikra igen. Tűzfal!! – ordítottam fel. Jött is egy tűzfalas ember. Elkezdtem demonstrálni neki:
– Látod, nem megy a 25 port. De ha teszem azt, a 135-öst adom meg, akkor sem… – mondtam, miközben pörgött a kezem… és a 135-ös port átment.
– Igen? – nézett rám kérdőn az ember.
– Any/any van? – hebegtem.
– Persze – bólintott.
– Bocs.

Mi a retek lehet? Transport szolgáltatások futnak. – Receive connector! – csaptam a fejemre. Autentikációk rendben. Network… és akkorát csaptam a fejemre, hogy lefordultam a székről. Egy, azaz egy szám el volt írva a három IP range közül az egyikben a Default smtp receive konnektornál. Így onnan nem fogadott el kapcsolatot. Ez a range pont az egyik pesti LAN volt, két Exchange szerverrel. Ráadásul következetes voltam: a tervben – a jól kidolgozott tervben! – gépeltem el a számot, és utána már mindkét helyen ész nélkül írtam be a rossz értékeket az implementáció során.

Innentől már csak a törmelékeltakarítás volt hátra. Mindent visszaállítani az eredeti elképzelés szerintire. Az összes CAS disztributálja az OAB-ot. Ekkor viszont nem megy az, hogy cegnev user belép a leánynál és letölti az OAB-ot. Szomorú lettem. Végül az lett, hogy anonymous autentikáció az autodiscovery, ews (availability) és oab website-okon. Igen, hőbörgött… de legalább működött.

Persze az OWA továbbra sem ment a vidéki telephelyen – de minden más, mint a svájci óra.

Házirendetlenül

Mint GT is rámutatott, az, hogy én létrehozok a nem működő, megsemmisült, sóvel beszántott default gpo-k helyett egy-egy hasonló nevű csoportházirend objektumot, nos… az nem az igazi. A rendszer, pusztán csak név alapján nem fog ráismerni. Hogy egész konkrét legyek, a rendszer csak akkor ismerne rájuk, ha az egyiket 31B2F340-016D-11D2-945F-00C04FB984F9-nek, a másikat meg 6AC1786C-016F-11D2-945F-00C04FB984F9-nek nevezném el – de természetesen ezek a nevek már foglaltak voltak.

Szokásos vadászat a neten, majd viszonylag hamar meg is lett a dcgpofix.exe progi neve. Meg a leírás is, hogyan kell használni. Az én esetemben borzasztó egyszerűen: be kellett írnom a parancssorba, majd minden rémüldözésekor yes-t nyomni. (Mondjuk előtte aprólékosan lejegyzeteltem a GPO-k ACL értékeit. Az ördög nem alszik. ADUC/System/Policy/GUID.) Még hozzá kellett rendelni a GPO-kat a megfelelő objektumokhoz, kitörölni a kamu GPO-kat – és már ment is minden.

Végül még lokálisan is rendet kellett tennem. Ez annyiból állt, hogy most, miután már megvoltak a default GPO-k, ráfutattam mindkét DC-re a DC security sablont. Ez az a sablon, mely akkor jön létre – és húzódik rá a gépre – amikor előléptetjük tartományvezérlővé.

Most nagyjából rend van a Futrinka utcában.

Újabb Exchange esettanulmány

Ügyfél szeretné, ha meglévő Exchange 2003 Sp1 szervereire Sp2-t telepítenénk. Nem egy nagy dolog, mondhatnád. Csakhogy. A hálózatuk meglehetősen cifra, benne az Exchange organizáció szintúgy.
– Mekkora a valószínűsége, hogy félremegy a telepítés? – kérdezték.
– Minimális – válaszoltuk.
– És ha mégis félremegy, mekkora a kár?
– Nem vészes. Uninstall, oszt jól van.
– Akkor csináljátok.
Mindez volt tavaly ősszel. Ugyanis mielőtt nekiugrottunk volna, megnéztük, hogy tényleg van-e uninstall. Nem volt. Sőt. Azt mondta a silabusz, hogy ha egyszer felraktad, akkor az már odanőtt; nem szedheted le. Azaz ha félremegy a telepítés és azt hiszi az Exchange, hogy már fent van az Sp2, pedig igazából nem – nos, akkor elég hülyén járunk.
– Kedves Ügyfél, ezt benéztük. Nincs uninstall – kezdtük beadagolni a keserű pirulát.
– Akkor most mi lesz?
– Majd kitalálunk valamit.
– Az jó lesz, mert rollback elképzelés nélkül coki.

Azaz előállt a feladat: csináljuk meg azt, amit a Microsoft szerint nem lehet.

A legjobb módszer ilyenkor gondolkodni egy cseppet. Mit csinálhat egy service pack? Egész biztosan lecserél egy csomó binárist. Hol lehetnek ezek? A ‘program files/exchsrvr’ könyvtárban tuti, és tudjuk, hogy a mapi32.dll meg a system32-ben van, tehát ez a könyvtár is érintett. Mi lehet még? Hát, van még ugye a szerver konfiguráció – csakhogy ez nem az Exchange szerveren tárolódik, hanem a címtár konfigurációs névterében. Igen, abban amelyből egy darab van az egész erdőben. Séma? Nem, nem kell semmilyen séma preparáció, tehát ahhoz biztosan nem nyúl. Adatbázis? Nos, igen. Ez sarkalatos kérdés.

Azaz, ha vissza akarjuk állítani az esetlegesen félrement sp2 telepítés előtti állapotot, egész biztosan mentenünk kell a binárisokat és a konfigurációs névteret. A sémát biztosan nem kell, az adatbázisról – és hozzá kapcsolódóan a domain névtérről viszont nem tudunk semmit.

Teszt.

Virtuális tartományban virtuális Exchange szerver. Sp2 telepítés előtt összes Exchange szolgáltatás lestoppol, telepítés közben a másolandó fájlok útvonala meredten figyel. Az eredmény mindenképpen kellemes: a telepítőt nem zavarta, hogy nem éri el az adatbázisokat, ergo nem is bántja őket. A binárisoknál pedig csak a fenti két könyvtár érintett.

Körvonalazódik a megoldás. Hogy elkerüljük a felesleges replikációhullámokat, a félisten repadminnal leállítjuk az Exchange szerver logon szervereként szolgáló tartományvezérlőn a kifelé menő replikációt, csinálunk egy system state mentést a DC-n, csinálunk egy fájl szintű mentést az Exchange szerveren, majd jöhet a service pack. Hiba esetén visszatesszük a binárisokat, egy non-authoritative restore a lezárt DC-n – és kezdhetjük előlről.

Újabb teszt.

Ilyenkor jön jól a virtuális környezet, ugyanis az előző virtuális tartomány gépeit előrelátóan elmentettem, még a kísérlet előtt.

Replikáció leáll, sp2 felmegy. Nézzük, mit látunk? Nézni nézzük, de nem hisszük – telepítés után az ESM azt mondja, hogy továbbra is csak az SP1 van fent. ADSIEdit-tel megnéztem a tartományvezérlőket – és ledöbbentem. A telepítő nem a logon szerveren tárolt címtáradatbázis konfigurációs névterébe írt, hanem egy éppen arra járó kósza tartományvezérlő adatbázisába. Visszakeresni viszont a logon szerveren keresett. A replikáció meg ugye fejbe volt csapva.
Azannya. Akkor az izolációnak lőttek. Szerencsére létezik fa/objektum szintre korlátozható autoritatív visszaállítás is, amelynek tulajdonképpen mindegy, mit történt a többi tartományvezérlőn – csak éppen így majd lesz két erős replikációhullám az erdőben.

Végső teszt.

  1. Az összes Exchange szolgáltatás leállít.
  2. Az összes virnyákölő szolgáltatás leállít.
  3. Mentés az Exchange szerveren a fenti két könyvtárból.
  4. System state mentés egy közeli tartományvezérlőn
  5. Servicepack2 hopsza, felugrik.
  6. Megvárjuk, amíg a replikáció szétterjed.
  7. ADSIEdit-tel ellenőrzés az összes DC-n. (Exchange server objektum, version tulajdonság. Hogy melyik szám mit jelent, itt találod.)
  8. Jöhet a visszaállítás. Binárisok visszatöltése az Exchange szerveren. Fontos, hogy a szolgáltatások még mindig állnak, tehát az adatbázis könyvtár még érintetlen.
  9. Tartományvezérlő újraindít, Directory Service Restore üzemmódban.
  10. Ideges kapkodás, hogy hová is írtuk fel évekkel ezelőtt a DC lokáladmin jelszavát.
  11. System state mentés visszatöltése.
  12. A konfigurációs névtér autoritatívvá jelölése:
    – ntdsutil elindít, megkapjuk a promptot,
    – beírjuk, hogy ‘authoritative restore’,
    – majd azt, hogy ‘restore subtree „CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=cegnev,DC=hu”‘
    – felírjuk, hogy hová gyártott az ntdsutil az ldf segédfájlokat,
    – quit.
    Ide elkél némi magyarázat, legalábbis a segédfájlokkal kapcsolatban. Egyszer már írtam az ún. Linked Value tulajdonságtípusról – itt is erről van szó. Egész egyszerűen van néhány olyan tulajdonság(backlink) a konfigurációs névtérben, melyek értékei más – esetlegesen más névtérben lévő – objektumtulajdonságok értékeiből állnak össze. Ezeket az értékeket az ntdsutil roppant intelligensen kiteszi egy ldif fájlba.
  13. Újraindítjuk a tartományvezérlőt, normál üzemmódban.
  14. Elindítunk egy replikációs hullámot: repadmin /syncall dc.cegnev.hu /e /d /A /P /q. (Ez ugyan lereplikál mindent, de csak a konfigurációs névtér lett autoritatív, a séma ugye intakt, a domain névtér meg normálisan replikálódik.)
  15. Végül visszatöltjük a backlink értékeket: ldifde -i -k -f fájlnév.ldf
  16. Szépen megvárjuk, amíg a replikáció elvégzi a dolgát. Leellenőrizzük mindegyik tartományvezérlőn, hogy a verziószám visszaállt Sp1-re.
  17. Biztonság kedvéért Exchange server újraindul, teszt levelezés, pihentetés.
  18. Végül Sp2 telepítés, megeszi-e. Megette.

Nos, ennyi. Ez már megnyugtatónak tűnt, nekikezdhettünk.

Természetesen végül nem volt semmilyen probléma.

ps: A fenti recept Windows Server 2003 Sp1 operációs rendszerű tartományvezérlők esetén működik! AD2000 esetén jócskán más a metódus.

Nem hivatalos rekordkísérlet

Ma olyan délutánom volt, hogy két gépen egyszerre 11 Terminál konzolból dolgoztam. Pörgött a kezem, füstölt a fejem… de sikerült minden.

  • Az egyik cégnél beröffent az egy hete működésképtelen Exchange 2007 OWA proxy.
  • A másik cégnél lecseréltem egy tűzfal mögötti tartomány összes tartományvezérlőjét Windows2003 szerverre, majd előléptettem a tartományt w2k3 módba.

Most egy hosszú szundikálás a metrón, majd jön az otthoni műszak.

[Update]

Azt hiszem, elkapkodtam ezt a délutáni bejegyzést. Mielőtt ugyanis előléptettem volna azt a tartományt, a biztonság kedvéért gyorsan leellenőriztem egy-két dolgot.
A hajam is égnek állt.
Először csak a replikáció nem ment.
Aztán a tartomány tokkal-vonóval leszakadt az erdőről.
Később már az Atyaúristens jogú felhasználómnak sem lett rá joga. Az erdő közölte, hogy olyan tartomány márpedig nincsen.

Na, ekkor füstölt csak igazán az agyam.

De végül meglett. Tudni kell, hogy ez ugyanaz a szutyok tartomány. Egész egyszerűen az történt, hogy a múltkori kavarás után a _pdc srv rekord értéke rossz helyre mutatott ugyan, de mivel az a gép még tagja volt a tartománynak, valahogy csak megtalálták a többiek az eldugott tartomány pdc emulátorát. Csakhogy most minden régi DC demotálva lett, az erdő pedig végképp elveszítette a fonalat. Természetesen az időszinkron is elment.
Most nagyzolhatnék, hogy mindezt brilliáns elmével következtettem ki, de nem lenne igaz. Bizony, ez egy kemény rakkolás volt, gyakorlatilag mind az öt – srv rekordokat tartalmazó – zónát egyenként csekkoltam át, hol találok valami rendelleneset. Szinte csak azt találtam. De végül összelegóztam mindent, kiszórtam a francba minden új link objektumot, hagytam, hogy a kcc elrendezze a dolgot, végül ki is segítettem néhány manuális konnektorral.
Juhé.

Innen már csak a GPO-kat kellett visszaállítanom, ugyanis az összes úgy elszállt, mint a győzelmi zászló. A teljes Sysvol – azaz Policy és Netlogon – csont üres lett. Bezzeg az eventlog…

Van erre egy jó módszer. Érdemes végigrágni, olyan területekre kaphatunk bepillantást, melyekről nekem eddig fogalmam sem volt, pedig elég régóta benne vagyok már az AD bizniszben. Csak a megértés volt egy félóra, a végigjátszás meg a duplája. És persze nem működött úgy, ahogy elképzeltem. (Én már annak is örültem volna, ha az egyik DC létrehoz egy szűz új struktúrát, a másik pedig átveszi. Csak működjön már végre a GPO szerkesztés.)
Végül a megoldás pofonegyszerű volt: habár a régi házirendekhez nem lehetett hozzányúlni, új objektumokat mégis engedett létrehozni. Utána már törölhettem a régi elárvult bejegyzéseket, az új házirendeket meg majd bekalapálja a helyi rendszergazda. Ha használta egyáltalán.

OCR a zsebben

Most csúnya dolgot fogok elárulni magamról: nem igazán értek a PKI rendszerekhez. Ismerem persze a privát meg a publikus kulcsok fogalmát/működését, tudom, mi az a tanúsítvány, tudom használni is ezeket – de amint odakerülök, hogy PKI infrastruktúra megtervezése, CA szerverek működtetése… mindig elfogy az erőm. Pedig megtanultam – hiszen vizsgázni is kellett belőle – voltam tanfolyamon is… de nem sok sikerrel. Amint feltűnik az a tömérdek szabvány, a rengeteg fájlformátum az egyedi nünükéikkel és rámzúdulnak az ismeretlen hárombetűs rövidítések, jönnek a bináris fájlokban txt módban kurkászások… elveszek. Úgy érzem magam, mint Alice Csodaországban. Nem az én világom.

Ennek ellenére én nyertem meg az egyik ügyfelünk PKI rendszerének megtervezését, telepítését.

A helyzetet cifrázta, hogy az ügyfélnek már volt egy MS PKI rendszere, egy Enterprise Root CA szerverrel – mely véletlenül és mentetlenül elhalálozott. Azaz újra kellett gombolni az egészet.

Úgy döntöttünk, hogy nem élesztjük fel a régi rendszert. Ment egy körlevél, hogy aki EFS titkosítást használt, gyorsan másolja ki a fájljait egy titkosítatlan könyvtárba, amíg még érvényes a tanúsítványa. Aztán jött a Nagy Radír. (A metódus itt található.)

Eddig nem is volt különösebb baj.
Annyi azért ragadt rám az oktatásokon, hogy hosszútávra úgy tervez az ember komolyabb PKI rendszert, hogy a Root CA az offline, a tanúsítványokat (Issuing funkció) és a házirendeket (Policy funkció) egy child CA szerver osztogatja, illetve kezeli. Hogy ne kelljen zselébe mártva eltárolni a hardvert, úgy döntöttünk, hogy a Root CA az egy virtuális gép lesz.

Szóval a vázlat hamar elkészült, jöhetett a részletek kidolgozása. Google. Szerencsére találtam is egy négyrészes cikket, mely pontosan leírja a tervezési szempontokat, a telepítési lépéseket. Pont ez kellett nekem.
Csakhogy a telepítésnek része volt néhány konfig fájl legyártása, néhány szkript lefuttatása. A weblapon ugyan ezek is ott voltak – de az a helóta szerző .jpg formátumban tette ki mind a 3 konfig fájlt és mind a két, kilométerhosszú szkriptet.
A francba.

De megint szerencsém volt. Jani éppen akkor jött be a szobába, amikor a harapásnyomokat políroztam ki az asztallapból – és megkérdezte, min dolgozok ilyen vehemensen. Elmondtam neki.
– Miért nem használom az Office Document Imaging programot? – kérdezett rá.
– ? – válaszoltam roppant intelligensen.

És lőn.
Elindítottam a Word-ot, majd ráböktem a Help-re. Hátha most. De most sem. Az a kék kérdőjel valami annyira borzalmasan használhatatlan, hogy nem is hiszem el. Nincs olyan – vagy legalábbis én nem találom – hogy részletes keresés, a kifejezések közé pedig ‘vagy’ relációt tesz, így ha beírod, hogy document imaging, kapsz ötezer találatot, melyben szerepel a ‘document’ szó.
Google.
Jött is egyből, hogy a cuccos az Office Tool-ok között található, és bár nem igazán volt rá szükség, de pár szóban le is írták, hogyan működik.

Nagyítás

Én még rövidebb leszek. A képet át kell konvertálni .tif formátumba, utána tudja beolvasni. Csak angol beállítással működik, azaz ezt a felismertetés előtt át kell állítani. (Figyelem, ez érinteni fogja a Word normal.dot template-et.)
Utána már csak a képen látható gombot kell megnyomni és megy is át a szöveg a Word-be. Elmentettem plain text formátumba, kijavítgattam a hibákat – ugye a remek dőlt karakterek – és kész is voltam.