Category: pki

Vissza a múltba

2012-07-19 / / 12 Comments

Kérdés jött az ügyféltől: hát mi most mit csináljunk? A helyzet röviden: lejárt a korábbi tanúsítványuk, meg szerették volna hosszabbítani, de a szolgáltató már nem volt hajlandó olyan SAN tanúsítványt kiadni, amelyikben belső név (cegnev.local) is szerepel. Ekkor viszont összedől az Exchange publikálásuk.

Első körben az volt a reakcióm, hogy szolgáltatót gyorsan kirúgni és keresni helyette egy másikat, amelyik nem ennyire vaskalapos. De mielőtt válaszoltam volna, a biztonság kedvéért futottam egy kört a guglin, és… eltátottam a számat.

  • http://help.securepaynet.net/article/6935?ci=72665&prog_id=wittyweb&isc=ssl-01

    • Ha jól értelmezem, akkor a tanúsítványszolgáltatók összedugták a buksijukat és arra jutottak, hogy az internet biztonságosabbá tétele érdekében legkésőbb 2016 októberéig mindegyikőjük visszavonja az összes olyan, általa kiadott tanúsítványt, amelynek akár a Primary Domain, akár a Subject Alternate Name mezőjében belső név, vagy privát IP cím szerepel.
    Ezzel gyakorlatilag ki is nyírták az összes olyan Exchange publikálást, ahol a belső tartományt nem split DNS alapon hozták létre, azaz a belső tartomány neve nem egyezik meg a cég külső nevével. Azaz hiába örvendeztünk pár évvel ezelőtt, hogy vége a tengernyi szopásnak, használhatunk SAN tanúsítványt az Exchange publikálásokhoz… ennek vége. Elvették a játékunkat.

    Informatikai közhely, hogy a biztonság és a kényelem egymást kizáró fogalmak: ha szigorítom a biztonságot, csökken a kényelem. Mindenki ismeri a sztorit, hogy az egyre hosszabb, egyre bonyolultabb jelszavak elméletileg növelik a biztonságot, de csak egy ideig, mert ha a felhasználó már képtelen lesz megjegyezni, akkor leírja egy papírra és kiragasztja a monitorra. Nesze neked, biztonság.
    Úgy néz ki, most is elértünk erre a szintre. Mit fog csinálni az egyszeri rendszergazda? Az, amelyiket komoly felvilágosító munkával éppen nemrég sikerült meggyőzni, hogy felejtse el a saját tanúsítványt és használjon szolgáltató által kiadottat? Szó nélkül visszatér a saját tanúsítványra. Itt olyan SAN tanúsítványt állít ki, amilyet akar, a terjesztését meg megoldja valahogyan. Mert akkorát szigorítottak a biztonságon, melyet már nem tud lekezelni.

    Illetve… van egy másik út, a mazochizmus útja. Nem, nem arra gondolok, hogy átnevezzük a tartományainkat, vagy létrehozunk egy új Active Directoryt és átmigrálunk bele mindent. Ez már nem mazochizmus, hanem öngyilkosság. Ellenben visszautazunk a múltba. Oda, amikor az Exchange 2003 publikálásoknál még nem volt SAN tanúsítvány. Persze azóta a világ sokkal bonyolultabb lett, de az elv maradt a régi:

    Végeztünk? Hát, ha szigorúan az Exchange könyvtáraira gondolunk, akkor igen. De mi is van az Outlook Anywhere mögött? Az RPC over HTTPS, mely gyakorlatilag két könyvtár az IIS default site alatt. Igen, default. Tehát ezeket is duplázni kell az új site alá. Létezik new-rpcvirtualdirectory parancs? Nem igazán. Mi a megoldás?
    Hekk.
    Meg kell keresni a default web site alatt az ApplicationHost.config fájlt, átmásolni az új site alá, majd átmásolni az rpc, rpcwithcert virtuális könyvtárakra vonatkozó részeket, értelemszerűen módosítva a sitenév bejegyzéseket. (Részletesen itt olvasható a módszer. Senkit ne tévesszen meg, hogy ez az RD Gateway szolgáltatásra vonatkozik, a gyakorlatban ugyanazokat a virtuális könyvtárakat használja, mint az Outlook Anywhere. Egy korábbi, az RD Gateway-t is érintő írásomban az egyik módszer konkrétan úgy is kezdődik, hogy a TMG-n használjuk az Exchange varázslót a publikáló szabályhoz.)

    Haladjunk tovább:

    • Az új site-hoz kötözzük hozzá a tanúsítványszolgáltató által kiadott tanúsítványt (melyben már nincs benne a cegnev.local név).
    • A reverse proxy-n (ISA, TMG, etc) gondoskodjunk róla, hogy az új site szolgáltatásai legyenek kipublikálva. (A nevekre figyeljünk oda, amennyiben szükséges, forgassuk a könyvtárneveket is.)

    Nagyjából ennyi. Az Exchange már működik. De olyan nagyon azért ne sóhajtsunk fel:

    • Mi lesz a Sharepoint szolgáltatásokkal?
    • Mi lesz az RD Web oldalunkkal?
    • Végül mi lesz az OCS\Lync szolgáltatásokkal?

    Agyhalál. Biztonságos internet. Ja.

    Aláírva

    2011-11-07 / / 1 Comment

    Haladni kell a korral, mese nincs. Nem lehetünk annyira kiberszerencsétlenek, hogy nincs saját tanúsítványunk. Hiszen jó dolog a nick, meg az avatar, de mennyivel vagányabb már, ha tanúsítvánnyal tudjuk igazolni, hogy mi vagyunk mi.

    Oké, értem én, a tanúsítványos játék soha nem volt igazán egyszerű. Illetve, ha megpróbáltuk egyszerűvé tenni, mindjárt drága lett. Csináljunk saját CA szervert? Hát, az elég macera, ráadásul ki fog csak úgy megbízni a szerverünkben? Kérjük meg az embereket, hogy léccilécci tegyék a szerverünk tanúsítványát a Trusted CA Servers tárolójukba? Aha. Akkor már inkább vegyünk egyet valamelyik nagy CA szervezettől. Persze, ez pénzbe kerül.
    A jó hír az, hogy nem mindig. Ha például magánszemély vagy, akkor a Comodo-tól(1) ingyen kapsz levelezésre használható tanúsítványt.

    (1) Vagy akinek jobban tetszik, InstantSSL. Mindenesetre, ahogy maguk állítják, ők a második legnagyobbak a piacon, azaz ahhoz mindenképpen elég nagyok, hogy az általuk kiadott tanúsítványt valószínűleg mindenhol elfogadják a világon.

    Meggyőztelek? Remek. Akkor nyomjál is rá bátran a megrendelő gombra.
    Illetve, ne, várj egy kicsit. Milyen böngészőt használsz?

    Elmesélem, hogyan jártam. Miután megrendeltem a tanúsítványt, közölték, hogy nagyon örülnek és küldenek a subject-ként megadott emailcímre egy levelet, melyben leírják a további teendőket. Ez nem volt bonyolult, rá kellett kattintani egy linkre. (Vagy elmenni egy weboldalra és beírni a levélben megadott emailcím/jelszó párost.) Oké, katt. Nagy büdös error.

    “The server returned an invalid client certificate. Error 207 (net::ERR_CERT_INVALID).”

    Mi van? A Comodo-t már megint meghekkelték? Márpedig bármelyik módszerrel próbálkoztam, mindig ezt az üzenetet kaptam. Benéztem a böngésző (Chrome) beállításai közé, hátha valahol túl szigorúra van állítva a tanúsítványok kezelése, de nem találtam semmit.
    Jó, nézzük a többi böngészőt. Kimásoltam a linket. Firefox. Egy abszolút értelmezhetetlen hibaüzenetet kaptam. Opera. Lefagyott. IE9. Na, ez végre meglepően őszinte volt, azt írta, hogy szerinte nem a megfelelő böngészőt használom.

    Ilyenkor marad a gugli. Nos, mondanom sem kell, az üzenetnek semmi köze a valósághoz. Szokás szerint.
    John Robbins írta le a frankót, igaz, ő egy fizetős Comodo (kódaláíró) tanúsítvánnyal szívott.

    A quick round with Comodo support and I find out Chrome and IE 9 are definitely not supported. They sent me a link with their instructions for downloading the certificate. The first line had me shaking my head:
    1) Open http://www.instantssl.com/code-signing/ in Internet Explorer (IE) 6 or 7 with ActiveX enabled. (Windows XP preferred)

    Hát, izé. Most akkor szedjem le az IE9-et, tegyem fel az IE8-at, kapjam le a tanúsítványt, majd upgradeljek vissza IE9-re? Elég rondán hangzik. Próbáltam kreatívan értelmezni az IE9 korábbi üzenetét. Mi van, ha a tanúsítványigénylő folyamat során a Comodo belerakott egy sütit a böngészőbe, mely később kellett a tanúsítvány letöltéséhez? Hiszen ez is belefér az üzenetbe.
    Újabb próbálkozás. Chrome-ból visszavonattam a kért tanúsítványt, simán megtette. Majd átléptem az IE9 alá, bízva abban, hogy a John írásától eltelt egy évben csak észrevették a Comodo-nál, hogy van IE9 is. Újabb igénylés, most IE alól léptem be a gmail fiókomba – és tadam. Megkaptam a tanúsítványt, be is tette a Personal fiókba. (Nyilván kimentettem, és eltettem biztos helyre is.)

    Tulajdonképpen ennyi. A többi már egyéni szociális probléma: a gmail-t ugyanis eddig senki nem értesítette, hogy egy levelet alá is lehet írni, sőt, akár titkosíthatnám is. Az hagyján, hogy a webes felületen erre semmi lehetőségem sincs, de ha aláírt levelet kapok, azzal sem tud mit kezdeni a kliens.

    From Segédlet

    A képen is látható, hogy a feladó publikus kulcsát tartalmazó tanúsítványt és az email lenyomatát is magában foglaló bináris cuccot a gmail egyszerűen csak egy p7s csatolásnak mutatja, anélkül, hogy értelmezné. Körbedolgozni persze lehet, a gépemen van Outlook is, abba felvettem a gmail fiókomat, aztán legfeljebb az aláírt leveleket innen küldöm. Csak éppen borzasztóan nem elegáns a dolog, mivel ekkor az elküldött levél nem ugyanabba a Sent Item folderbe kerül, márpedig én az esetek 99,99%-ában a webes felületről levelezek.

    Ha esetleg kedved van még a témával kapcsolatos anyázást olvasni, tudom ajánlani Jason Perlow írását a zdnet-en. A cím önmagában is telitalálat és remekül illeszkedik hozzá az illusztráció is.

    Sorvezető

    2009-07-16 / / 6 Comments

    Ha ISA 2006 szerveren keresztül szeretnénk Exchange 2007 webszolgáltatásokat kipublikálni, ahhoz ma már nem kell remegő kézzel nekifogni. Az internet tele van cikkekkel, írásokkal, tényleg minden információ begyűjthető. Konkrétan itt van egy MS cikk, ez alapján nem lehet semmi gond.

    Vagy mégis?

    Nos, amennyiben az Exchange szervered alatt Windows Server 2008 fut, akkor azért fognak érni meglepetések.

    Nem akarom végig leírni a folyamatot, az említett cikk tényleg nagyon jó. Itt inkább csak a buktatókat gyűjteném össze.

    Először is, a Windows 2003-as CA szerver nem fog tudni neked SAN tanúsítványt gyártani. A következő paranccsal lehet erre rábeszélni:
    certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
    Majd újra kell indítani a Certification szolgáltatást.

    Oké. Fogod, elindítod a böngészőt az Exchange szerveren, rácsatlakozol a http://ca-server.cegnev.hu/certsrv/ weblapra – és már nem emlékszem pontosan, mit kapsz válaszul, de nem a megszokott nyitólapot. Valami olyasmit mond, hogy ez a tartalom a számodra nem érhető el.
    Kedves.
    A magyarázat itt található: http://support.microsoft.com/kb/922706.
    A Windows Server 2003 alatti tanúsítványosztogató weblap olyan activex kontrollt használ, melyet a Windows Server 2008 / Vista undorral lök el magától. A megoldás: fel kell telepíteni egy patch-et a CA szerverre, hogy úgy is tudjon tanúsítványt osztogatni, ahogy az újabb fiúk kérik.

    Akkor most már mehetünk is vissza a weblapra. De mégsem. Azt mondja, immár a helyi böngésző, hogy a CA weblapjának https-en keresztül kellene jönnie. Addig ő nem fogja megmutatni a tartalmat.

    Kitérő: Szeneslapáttal igazítanám meg a frizuráját annak, aki ezt az egész nevetségesen idióta ‘Enhanced Security’ módú Internet Explorert kitalálta. Tipikusan az, amikor átesünk a ló túloldalára: használhatatlanná tesszük a terméket és a végtelenségig elbonyolítjuk az egyébként is meglehetősen érthetetlen konfigurálást. Ráadásul úgy tudom, W2k8 szerver alatt kikapcsolhatatlan – miközben ott már épp elég védelmet jelentene az UAC is. Amióta ez van, azóta az az első, hogy telepítem a Firefox-ot a szerverekre is. Szerveren úgyse nézeget az ember pornó oldalakat.

    Fogcsikorgatás. Nyilván valahol át kell kattintani valamit, melynek a neve még csak nem is utal arra, hogy mit befolyásol. Szerencsére itt van a net, ahol egy sorstárs már megtalálta rá a workaround-ot.
    Hurrá. Elérhető lett a CA weblapja.

    Lehetne igényelni az Exchange tanúsítványát… de ez mégsem ennyire egyszerű. Amennyiben az Exchange szerverünk Windows Server 2003 alatt fut, akkor – ahogy a cikk is írja – powershell-ből tudunk tanúsítványt generálni. Csakhogy jelen esetben már W2k8 az alap, ezen már van grafikus felület is. Összedobunk egy custom MMC konzolt, felvesszük bele a Certificates (local machine) snapin-t. A Personal folderen jobbkattintunk, majd a lenti képen elmegyünk a ‘Create Custom Request’ menüponthoz.

    Nagyítás

    Tulajdonképpen mehetnénk a ‘Request New Certificate’ menüpontba is, hiszen itt van, LAN-on belül a CA szerver, mindenki domaintag, ne kelljen már bináris fájl tartalmát kopipasztázgatni. Mehetnénk… de nem működik. A varázsló második ablakán minden szürke – és közli, hogy nekem bizony nincs lehetőségem webserver tanúsítványt igényelnem. Márpedig hidd el nekem, hogy ha nekem nincs meg ez a jogom, akkor senki másnak sem.
    Marad a custom request.

    Maga az igény összerakása nem túl bonyolult, egy kicsit szokni kell az újfajta grafikus elemeket, de nem vész. Rá kell kattintani minden izére, meg bigyóra, megnézni, mi is van mögöttük. (Shinder bácsi írása elég jól képbe rakhat bárkit.)
    Az alábbi ábrán azt a részt emelném ki, amitől SAN lesz a tanúsítvány.

    Nagyítás

    Igen, az alternatív nevek. Ahogy az előző linken is van – meg máshol is – beírtam a Subject mezőbe CN-ként a külső nevet, az Alternative Name alá meg az összes szóbajöhető lehetőséget, beleértve azt is, hogy bentről esetleg rövid névvel nyomul valaki. Amit a Subject mezőbe írtam, azt nyilván már nem írtam be az Alternative Name alá is. Aztán végigmentem a láncon, igényeltem, kiadtam, importáltam, majd exportáltam végül megint importáltam… szóval ahogy az első linken szépen le van írva – végül jött kintről az OWA teszt.

    Nem sikerült. Azt írta ki, hogy a tanúsítvány nem erre a weblapra szól. A Firefox ennél imformatívabb volt, kiírta azt is, hogy mely weblapokra lenne jó ez a tanúsítvány: csak azokra, amelyek az Alternative Name mezőben szerepeltek. A Subject, az nem jött szóba.

    Hozzáteszem, nem vagyok tanúsítvány guru. Fogalmam sincs, mennyire kötelező a Subject alatt CN tipusúnak megadni a nevet, nem tudom, lehet-e ott is DNS formátumot használni. Mindenesetre az egyszerűbb utat választottam, az Alternative Name alá is bedobtam a külső nevet – ahogy az ábrán is láthatod. Működött.

    ISA Server 2006 Sp1

    2008-07-19 / / 1 Comment

    I’m swamped in the snow.
    Ugye, mi azt mondjuk, hogy ‘el vagyok havazva’, az amerikaiak meg, hogy ‘I’m swamped’. Nos, ha lehet fokozni a kifejezés erejét, akkor én most be vagyok mocsarasodva into the hó.

    De a blog is kezd pókhálós lenni, így ha hosszú cikkben nem is, de legalább említés szinten ejtek pár szót arról, hogy kijött az ISA 2006 Sp1.

    Igen, tudom, az a blog neve, hogy Email és a Detektívek. Mit keres itt akkor az ISA?

    Tessék csak megnézni a feature listából ezt a tételt:

    Support for use of server certificates containing multiple Subject Alternative Name (SAN) entries
    Certificates with multiple SAN entries are now supported at the web-published servers.
    Previously, ISA Server was able to use only either the subject name (common name) of a server certificate, or the first entry in the SAN list.

    Illetve meg lehet nézni az előzményeket.

    Mi is az a SAN? Jelen kontextusban Subject Alternative Name. Érintett benne rendesen az Exchange 2007 is. Anélkül, hogy elmerülnék a részletekben: a SAN tanusítvány olyan tanusítvány, mely nem csak egy névre szól, hanem tartalmazhat alternatív neveket is. Márpedig ha a CAS szerverünket kintre is és bentre is publikálni akarjuk valós tanusítvánnyal, akkor SAN tanusítványt kell használnunk.

    Nos, összeállt a kép?

    Mennyi? Harminc!

    2008-03-31 / / 0 Comments

    Közben persze neki kellett ugrani a PKI rendszer feltámasztásának is. (Mely ugye rögtön az elején sikeresen összedőlt.) Tiszta lappal kezdtünk, méghozzá ‘ha már csináljuk, legyen jó’ felkiáltással: azaz legyen egy offline root CA meg egy online subordinate issuing CA.

    A történetet majd megírom egyszer, nem volt kispálya.

    Most csak egy apró frusztráció.

    Elkészült, átadtam. Egy hét múlva jött az üzenet, hogy nem megy a CA szolgáltatás. Ránéztem, tényleg.
    Eventlog megnéz, azt mondja a CA szolgáltatás nem tudja leellenőrizni, hogy nem vonták-e vissza véletlenül a tanúsítványát, ezért nem indul el. Azannya. Azaz nem tudja elérni az offline CA-t… mivel az offline. Gugli, turkálás. Azt írták, hogy állítsuk be a registryben a CRLFLAGS értékét 2-re. Beállítottam, service vidáman elindult. Én is, boldogan, haza.
    Pár napra rá megbeszélés az IT vezetőnél, teszteljük le élesben a CA szervert. Teszteljük. Megigényelték a tanúsítványt, szépen végigmentünk a varázslóval, aztán a végén kövér error. Ajjaj.

    Habár vannak események a naplóban, de az eventid.net nem tud mondani semmit. A konzolból azt látom, hogy egy ideig ment a tanúsítványkiadás, aztán egy időtől meg már nem. Miaf?
    Bősz guglizás. Végül találok egy parancsot:
    certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE.
    Ez ugye ugyanazt a registry értéket piszkálja, melyet korábban manuálisan állítottam be, csak éppen nem számot ír be, hanem egy ködös változót. Próbáljuk ki, milyen számot fog használni?
    Nos, egész pontosan azt mondta:

    New Value:
    CRLFlags REG_DWORD = a (10)
    CRLF_DELETE_EXPIRED_CRLS — 2
    CRLF_REVCHECK_IGNORE_OFFLINE — 8
    CertUtil: -setreg command completed successfully.
    The CertSvc service may need to be restarted for changes to take effect.

    Érted, ugye? Tehát a flag-be be kell rakni egy kettest – ezt tettem én is meg korábban – azért, hogy a szolgáltatás offline root CA esetén elinduljon és egy nyolcast, hogy rendesen is működjön. A végeredmény tehát 10, azaz a beírandó érték 0a. Be is írta, működik.
    Én pedig vegetative néztem az asztalt, azon meditálva, mennyire jó nekem, hogy ilyesmikkel foglalkozom.

    De most komolyan:
    Ez a nyomorult PKI egyébként sem egyszerű dolog, se a megértése, se az implementálása nem könnyű – és akkor telerakjuk ilyen csapdákkal. Feltúrni az internetet egy rohadt registry heckért, aztán kiderül, hogy több is van belőle… ahelyett, hogy lenne egy szájbanyomott checkbox valahol a subordinate CA tulajdonságlapján, hogy a root CA az offline.
    De biztos én vagyok a hülye.

    OCR a zsebben

    2008-02-09 / / 0 Comments

    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.

    Tartományi konszolidáció

    2008-01-03 / / 0 Comments

    A helyi erők a migrációt már elvégezték. Amikor odakerültem, már minden kongott az ürességtől.
    Az összeszorított fogak közül kiszüremlő kifejezések ennek ellenére már az első körülnézéskor előbukkantak. Ha azt mondom, hogy a megszűntetendő tartomány ebek harmincadján volt, akkor finom voltam. Tartományvezérlő, melyet egyszerűen csak kikapcsoltak és újratelepítettek máshol. Ugyanez Exchange szerverrel is. Az egyetlen fizikailag létező Exchange szerver külön Routing Groupban volt. Némileg cifrázta a helyzetet, hogy a Routing Group Connector-t viszont másfél éve lebontották. A postafiókokat pst-kkel lapátolták át. Kismillió public folder. Szükség van rájuk? Persze! – jött a válasz.

    Visszaépítettük az RGC-t. Kismillió replikációs konfliktust jelző levél söpört végig napokon keresztül a levelező szervereken. (Ugye tudjuk, a public folderek a két replikáció közötti párhuzamos módosítások esetén nem az időbélyeg alapján döntik el, melyik módosítás a frissebb, hanem levelet küldenek mindkét módosítónak, hogy csókolom, tessék leharcolni egymás között, kié legyen az érvényes. És itt volt másfél év, replikáció nélkül.)

    Végül mindegyik folderről született replika másik szerveren is, így levehettük a példányokat a megszűntetendő szerverről. Ez már csak napok kérdése volt. Az IT vezető itt kezdte el rágni a kefét, hiszen az egész tartománytörlésre egy nap volt ütemezve.
    De végre eltűntek a public folderek, lehetett eltakarítani az Exchange szervereket. Rögtön az elsőnél földön koppant az állam: az Add/Remove panel szerint a Windows szerveren két példányban is futott az Exchange szerver. Ráadásul az egyiknek olyan verziószáma volt, mely a hivatalos táblázatok szerint nem is létezett. Fejvakarás. Megpróbáltam mindkettőt eltávolítani. Az egyiknél már a telepítő sem indult el. A másiknál elindult, de amikor azt mondtam neki, hogy mars ki, azt válaszolta, hogy “There is no such object on the server”. Azaz a kettőből elméletileg egy sem létezett. Ismerjük el, azért van abban némi kihívás, hogyan távolítsunk el egy gépről két darab nemlétező Exchange szervert. Feltettem a hegesztőszemüveget, előkészítettem a registry editort, az adsieditet és a szokásos mmc konzolomat. Csak nagy vonalakban:

    • Exchange szolgáltatások leállít
    • Exchange registry beállítások kigyomlál:
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DAVEX
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ExIPC
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXOLEDB
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IMAP4Svc
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeActiveSynchNotify
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeADDXA
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeAL
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeES
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeFBPublish
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMGMT
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMU
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOMA
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSRS
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\POP3Svc
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc
    • IIS eltávolít a gépről
    • Másik gép Exchange System Manager programjából az Exchange szerver töröl
    • AD-ból a gép kiléptet.

    Egy szerverrel végeztünk. Jöhetett az utolsó Exchange szerver a Routing Groupban. Add/Remove, eltávolít… ugyanaz a hibaüzenet: “There is no such object on the server”. Eszelős guglizás. Ugyan eltávolíthatnám ugyanúgy, ahogy a másikat, de ez akkor is az utolsó szerver, legalább ezt tisztességesen kellene kirúgni. Aztán szerencsés találat, egy newsgroupban azt írják, hogy látszani ugyan nem látszik a postafiókok között, de minden szervernek van egy postmaster accountja is. A következő objektumon – CN=Configuration,DC=SUBDOMAIN,DC=DOMAIN,DC=COM\CN=Services\CN=Microsoft
    Exchange\CN=EXCHANGE\CN=Global Settings\CN=Message Delivery – meg kell keresni az msExchAdminMailbox tulajdonságot. Ennek értéke mondja meg, melyik felhasználóhoz van hozzárendelve a postmaster mailbox. Ha ez megvan, akkor adsieditből megnyitjuk a felhasználó objektumát és meglessük a HomeMDB tulajdonságát. Ha ez a letörlendő szerverre mutat, akkor töröljük. Ha nincs már meg a felhasználó, akkor az msExchAdminMailbox tulajdonságnál adunk meg egy másik felhasználót.
    És bejött. Egy már ezer éve nem létező service account userre mutatott az érték. Átírtam… és rögtön más hibaüzenettel állt le az eltávolítás. De ez már ismerős volt korábbról. Anélkül, hogy mélyebben belemennék, a HomeMDB értékekhez kapcsolódik egy backlink, a HomeMDBBL, abból lehet kimazsolázni a sunnyogó postafiókokat, lásd KB279202.
    Most már semmi akadálya nincs az eltávolításnak. El is indult a folyamat… majd az Information Store leállítása befagyott. Hosszú várakozás után közölte, hogy oké… pedig ádehogy. Újabb fejvakarás. (Csodálod, hogy kopaszodok?) Átnéztem a szolgáltatásokat… hát ilyen nincs. El volt indítva a Site Replication Service. Natív Exchange 2000 organizációban. Az eszem megáll. Leállítottam előre minden szolgáltatást, beleértve az IIS és Winmgmt szolgáltatásokat is – és innentől már tényleg leesett a gépről az Exchange.

    A többi már rutinmunka volt. Egy kicsit megpörgettem az ntdsutil-t (metadata cleanup), hogy eltávolítsam a szabálytalanul leállított DC-t, aztán dcpromo az utolsó DC-re végül egy óriási nagy takarítás az AD konzolokból, DNS-ből, WINS-ből, Exchange konzolokból.
    Hajnali egy óra és már végeztünk is.

    Második felvonásként rendezkedni kellett a gyökértartományban is. Az erdő szintű FSMO szerepeket birtokló tartományvezérlő… minden volt, csak nem acélos. Amennyit fagyott, attól akár Gorenje gyártmányú is lehetett volna. Olyan trükköt tudott, amilyet én még számítógéptől nem láttam: a szoftveres tükör mindkét lemeze külön-külön is látszott: az egyik C: néven, a másik meg talán V: néven. Nyilván ez így nem maradhatott. A FSMO szerepek szerencsére simán átmentek egy másik DC-re, jött volna a dcpromo. Jött is, aztán udvarias köhintéssel megkérdezte, hogy mit is csináljon a rajta lévő enterprise root CA szerverrel.
    – Ez mi? – néztem meglepve a rendszergazdára.
    – Nem tudom – vonta meg a vállát.
    – CA szervernek tűnik – tippeltem.
    – Lehet. Tudtam, hogy valahol van egy.
    – Kik használják?
    – ? – vonta meg a vállát.
    Itt a magam részéről befejeztem a munkát. Mondtam, hogy amíg nem tudják, kik és mire használják ezt a CA szervert, addig én nem bolygatom meg. Meg utána sem szívesen, mert CA téren nem mozgok olyan biztos lábakkal. A takarításnak ezt a részét az insource vállalta be. Lementették a CA adatbázist, dcpromo le, operációs rendszer újratelepítése – a CA miatt szigorúan ugyanolyan néven – dcpromo fel, CA telepítés, adatbázis visszatöltés. Itt futottak bele egy pofonba, mert a régi CA hol a C: meghajtóra hivatkozott, hol a V: meghajtóra – amely ugyebár megszűnt. De a srác becsületére legyen mondva, ügyesen összekötözgette valahogy a szálakat. Végül visszamásztak a FSMO-k is.

    Aztán jöttek a tartományvezérlő frissítések. Rendben meg is történtek. A rendszergazda éppen a drivereket telepítette fel a vacakabb, immár w2k3 tartományvezérlőre, amikor az úgy döntött, hogy elég volt neki ebből a világból. Olyan szinten szakadt össze, hogy esély sem volt feltámasztani. A fiúk vettek egy új vasat, és arra már közvetlenül w2k3 oprendszert telepítettek. És ekkor derült csak ki, hogy a CA adatbázis ugyan átkonvertálódott w2k3-ra, de az a géppel együtt elszállt. A mentésben lévő w2k formátumú CA adatbázistból meg nem lehet visszaállítani w2k3 CA alá semmit. Mivel közben a tartomány is natív lett, így elég bonyolult forgatókönyvek adódtak a visszaállításra. Olyannyira bonyolultak, hogy az IT vezető úgy döntött, inkább telepítsünk egy új CA szervert. Némileg kellemetlen, hogy még mindig nem lehet tudni, kik és mire használták a régit..
    Na, mindegy, a tartomány legalább szépen működött.