Month: March 2007

Majdnem-Herkules

2007-03-30 / / 0 Comments

Igen, ő a Muszáj-Herkules testvére.

Felteszem, mindenki tudásában vannak fehér foltok. Olyan területekre gondolok, melyeket ha máskor nem is, de vizsgára megtanultunk – aztán utána el is felejtettük, mert soha nem volt rá szükségünk. Nekem ilyen terület a biztonsági sablonok molesztálása.

Adott volt a következő feladat: telepítsünk egy egyszerű failover clustert multi ügyfél magyar leányvállalatához. A vasak egyszerű pengeszerverek, oprendszer, IIS (erőforrás lesz belőle az ügyfél alkalmazásában). A gép tartományba beléptetve, lokál admin jogunk van, tartományi admin jog nincs. Jól is néznénk ki.
Mielőtt még felhajigálnánk a clustert (pontosabban beizzítanánk, hiszen a WIndows2003 Enterprise változatban helyből települ), még le kell futtatnunk egy helyi specifikus alkalmazást: ez bekeményíti az operációs rendszert, bekonfigurál egy csomó mindent, felrak ezt-azt. Céges standard, kötelező.
Jöhet végre a cluster. Gyönyörűen fel is települ, majd amikor leokézom az utolsó ablakot, jön egy kövér error. Hogy access denied.
Első alkalommal ijedtemben eltávolítottam a node-ot. (Ami persze nem igazán egyszerű dolog, hiszen grafikus felületről nem látszik semmi. A megoldás: ‘cluster node <nodename> /forcecleanup’) De az újabb, alaposabb konfigurálásnál ugyanezt kaptam. Ráadásul a kollégák szóltak, hogy a cluster tulajdonképpen működik, kívülről elérhető. Csak éppen nem menedzselhető. Zorró, a fantomklászter. Jöttek a szokásos ráolvasások éjfélkor keresztútnál (filemon, regmon, user jogosultságok, gpresult), de nem sok sikerrel. Aztán az ügyfél ötletére ráhúztuk a rendszerre a ’setup security’ biztonsági sablont – és onnantól már a cluster szolgáltatás sem indult el. Viszont amint visszaállítottuk a cluster service account user jogosultságait a setup security sablonban, egyből menedzselhetővé vált a cluster.
Azaz a hardening csinált valamit, amitől elérhetetlenné vált a cluster management GUI – amint visszatettem egy gyengébb sablont, minden ment simán.
Azt hihetnéd, hogy örültünk ennek a megoldásnak. Óriási tévedés. A leánycégnek az égegyadtavilágon semmi ráhatása sincs arra, hogy a magasságos multi anyacégnél a biztonsági részlegen milyen hardening eljárást dolgoznak ki. Sőt, még tájékoztatást sem kapnak, hogy tkp. mi is történik a folyamat során. A maximum, amit ki tudtunk csikarni, az egy mérsékelt érdeklődés volt, és egy igéret, hogy ha kiderítjük, melyik beállítás okozza a hibát, akkor az eredményt felveszik a céges knowledge base-be.

Azaz identifikálni kell, ezerrel.

És itt jön be a képbe a Security Configuration & Analysis segédprogram. A Majdnem-Herkules.

Mielőtt tovább haladnánk a megoldási folyamatban, nézzük át részeletesen, hogyan is működik ez az eszköz.

Először is, az eszköz grafikus felülete csak MMC konzolból érhető el – azaz megfuttatjuk az mmc.exe progit, majd a snap-in-ek közé felvesszük a Security Configuration & Analysis konzolt. És ha már ott járunk, kapjuk fel a Security Templates konzolt is.

Nagyítás

Ha magunktól próbálunk rájönni az eszköz működésére, akkor gondban leszünk. Ugyanis ha nem ismerjük a logikáját, magunktól soha nem fogjuk kitalálni.
Az elv az, hogy van egy működő rendszer. Ez az, amely éppen dübörög a gépen, amelyen vizsgálódunk. És van egy munkaterület, ahová boncolási célzattal betölthetünk biztonsági sablonokat. Egyszerre mindig csak egyet. Ezt a munkaterületet adatbázisnak nevezték el. Az összes műveletnek ez a két terület az alanya.

  • Össze lehet hasonlítani a munkaterületen lévő sablont a jelenlegi beállításokkal. (Analysis.)
  • Tetszőlegesen módosíthatjuk a munkaterületen lévő sablont, majd elmenthetjük.
  • A munkaterületen lévő sablont ráhúzhatjuk a működő gépre. (Configuration.)

Nézzük részletesen.

Mielőtt bármit csinálnánk, munkaasztalt – adatbázist – kell definiálnunk. Jobbklatty, open database.

Nagyítás

Itt beírjuk a létrehozandó adatbázis (.sdb) nevét. Ezzel létre is jön. De mielőtt még kiérnénk a kuruzslóból, megkérdezi, hogy vajh melyik sablont szeretnénk betölteni? Válasszuk ki valamelyiket.

Nagyítás

Amivel egész biztosan nem okozunk galibát, az az összehasonlítás. Csapjunk bele.

Nagyítás

Rögtön az elején megkérdezi, hová mentse az összehasonlítás során keletkező log fájlt. Ezt jegyezzük fel, mert később szükségünk lehet rá. (Persze ha konzolból nyomjuk, az meg fogja jeleníteni a jobb oldali ablakban.)

Nagyítás

Aztán dolgozik az analízis. (Menj analízisbe, Ofélia.)

Nagyítás

Imhol a végeredmény. Látható, hogy a security fa melyik ágán vizsgálódunk és mely tulajdonság egyezik, mely pedig nem. Az eltérést a mismatch jelzi.

Nagyítás

A konkrét ábrán például láthatjuk, hogy a User Rights ágon belül a System Time állítgatási jog beállításai eltérnek az adatbázisban és az éles rendszeren. Nézzük meg, hogy hogy is néz ez ki a grafikus felületen:

Nagyítás

Igen, láthatjuk, hogy a munkaasztalon lévő sablonban a megfelelő beállítás előtt egy ikon jelzi, hogy ott valami nem stimmel.
Egész pontosan az ikon a következőket jelezheti:

  • Piros körben fehér iksz: a beállítás eltér a valós rendszer és a vizsgált sablon között.
  • Fehér körben zöld pipa: a beállítás megegyezik a valós rendszerben és a sablonban.
  • Kérdőjel: A beállítás nem létezik az adatbázisban, ergo nem is került kiértékelésre.
  • Felkiáltójel: Pont fordítva: a beállítás nem létezik a valós rendszerben.
  • Nincs semmilyen jel: A beállítás egyik helyen sincs definiálva.

Például a korábban a szövegfájlban látott mismatch így jelenik meg a grafikus felületen.

Nagyítás

Természetesen a munkaterületre betöltött sablont nem csak boncolhatjuk, hanem műthetjük is. Bármelyik beállítást módosíthatjuk, majd az így létrejövő sablont exportáljuk valamilyen új néven.
Értelemszerűen ahhoz, hogy ez a menüpont megjelenjen, előtte be kell tölteni egy sablont a munkaterületre, majd összahasonlítani az aktuális beállításokkal. Utána lehet menteni.

Nagyítás

Új sablont nem csak létezőből kiindulva hozhatunk létre – igaz, ehhez már egy másik konzolra lesz szükségünk. A Security Templates snap-in-ben jobbkattintás, majd New Template…

Nagyítás

Látható, hogy ez egy teljesen üres sablont hoz létre. Miénk a terep, tetszőlegesen perverz kombinációk létrehozása előtt nyilik meg a lehetőség. Csak arra vigyázzunk, hogy magunkat ne zárjuk ki a módosítási engedéllyel rendelkező személyek közül. Onnantól ugyanis unalmas hétköznapunk egy kicsit pörgősebbre fog változni.

Nagyítás

Itt pedig azt láthatjuk, hogy a Security Templates konzolban létrehozott MacskaRugjaMeg sablont mentés után már a Security Configuration and Analysis konzol munkaterületére is betölthetjük, további fazonírozás céljából.

Nagyítás

Amennyiben a megfelelően módosított sablont rá akarjuk húzni, akkor az Analysis menüpont helyett a Configuration menüpontot válasszuk – ekkor a munkaterületen lévő beállítások rámásolódnak az aktuális számítógépre.

Nos, nagyjából ennyi. Egész jó kis segédprogram.
Lenne.
Ha a program tervezése során figyelembe vettek volna egy átkozottul reális igényt: azt, hogy a meglévő gép biztonsági beállításaiból sablont gyárthassunk. De nincs. Tessék ilyen szemmel végigolvasni az eszköz működését: mindenhol a munkaterületet exportálhatjuk, oda meg már létező sablont tudunk csak betölteni. Ez egy akkora öngól, hogy még ma sem tudom igazán elhinni. Programozástechnikailag semmibe nem került volna összedobni, a sablongyártásban pedig óriási segítség lett volna.

Érted már, hogy miért Majdnem-Herkules?

Térjünk vissza a megoldandó problémához. Van egy gép, induláskor a setup security sablonnal. Ezen begerjesztem a cluster szolgáltatást, felkonfigurálom a clustert. Innentől már eltértünk a sablontól, tekintve, hogy a telepítés/konfigurálás belerondít rendesen. Aztán jön a multi cég hardening folyamata, mely aztán végképp összezavarja a szálakat.
Nekem arra lenne szükségem, hogy mielőtt ráengedném a hardeninget, le tudjam menteni sablon formában az épp aktuális beállításokat, majd a bekeményítés után visszatölthessem a munkaterületre és ki tudjam analizálni közöttük a különbséget. Nyilván még ez sem lenne túl egyszerű, kicsit ‘tű a szénakazalban’ jellegű a munka… de valahogy így lehetne nekiállni.
Ehelyett… kinlódunk. Nem tudom lementeni a sablont, tehát maximum a setup security kiindulási pont és a hardening végső pont között tudok különbséget képezni – azaz a feladat jellege megmaradt, csak a szénakazal lett jóval nagyobb.
Illetve… trükközhetek. Felkonfigurálom a clustert, majd összehasonlítom a valós rendszert a setup security sablonnal. Ekkor megkapom azokat a beállításokat, melyeket a cluster telepítés érintett. Gyújtok egy gyertyát Szent Antalnál és reménykedek, hogy ez a halmaz nem lesz nagy – és tartalmazni fogja azt a beállítást, melynek átállítása okozza a galibát.
Most jöhet a hardening, majd ezt összehasonlítom a setup security sablonnal – de csak a korábban manuálisan kiszűrt beállításokkal fogok foglalkozni.

A megoldás kicsit olyan ’szarva között a tőgyét’ jellegű – de akár működhet is. Talán.
Ha nem, akkor kénytelen leszek felvenni a csempetépkedő kesztyűt.

ps.
Amikor az ember először morog, utána gondolkodik. A ‘secedit /export /mergedpolicy /db /cfg’ mintha pont ezt csinálná.

MVP Summit, Redmond, 2007

2007-03-16 / / 0 Comments

1.nap

Ma végre tényleg az Exchange lett a főszereplő. Mit saccolsz, melyik verzió?
Nem találtad el: szinte mindenkit az Sp1 érdekelt. Hogy miért csak ennyi van benne? Hogy miért kötik a Longhornhoz a megjelenést, amikor nagyon fontos változásokról lesz benne szó – melyek nagy része ráadásul nem is Longhorn specifikus? (A válasz egyébként az volt, hogy ez üzleti döntés, a fejlesztők nem tehetnek róla.) Aztán jött, hogy miért lett elegük a Public Folderből? A választ nem részletezem, a mozdulatot és arckifejezést úgysem lehet szavakkal visszaadni.
Kihasználva a zűrzavart, egy agresszívabb MVP felhánytorgatta, hogy miért léptek vissza: miért álltak rá telephelyen belül az RPC-re az SMTP helyett? Én egyből elfogadtam a magyarázatot: a levelekből külön kell kibányászni a parancsot, az SMTP-nek adatbázisa van, külön motort kell neki fenntartani – az RPC egyszerűbb. A kérdező nem így tett, így volt egy kis ordítozás arról, hogy mi is számít evolúciónak. (Mondjuk nem ez volt a jellemző, inkább nagy összevigyorgások voltak, időnként beleszőve, hogy ugye mindenkinek van NDÁ-ja?)
Külön szép, hogy elméletileg ez egy szűkkörű előadás lett volna az Exchange2007-ről, architektúráról, szerepkörökről. Ehelyett egy gumilabda stílusú hapi kiült az asztal szélére és elrikkantotta magát, hogy „Hi guys! Let’s question!” – és már dőltek is a kérdések.

Egyébként tök jó nevek vannak a hallgatóságban: 50-60 ember, ebből eddig Petri-t és Lefkovics-ot sikerült beazonosítanom.

A masszív nemalvás azért meghozta a gyümölcsét, az első etap végén többször is leesett a fejem a padlóra. A mellettem ülő kövér japán se könnyítette meg a dolgom: gátlástalanul horkolt.

A szünetben kimentem egy kicsit a szabadba. Addigra már jeges eső esett. Egy kicsit álldogálltam benne, pusztán felébredési célzattal. Utána jött egy nagy akó kávé – meg a következő előadás. Négy ember – SCR, CCR projekt menedzserek – beszéltek volna SCR-ről, CCR-ről, DR-ről – de a főelőadó itt is elkövette azt a hibát, hogy az elején megkérdezte, van-e valakinek kérdése. Gyakorlatilag az első ppt-n nem jutott túl.
Nem is lenne ezzel baj – ha tudnék ennyire angolul. Az előadás megértése valahogy még menne – de az ilyen össze-vissza csapongások finom nüanszainak megértése jelen állapotomban heroikus kísérlet. A legtöbbször csak pislogtam bambán, hogy most meg min röhögnek.
De azért néhány dolog átjött. Körülbelül háromszor magyarázták el, hogy sem a CCR, sem az SCR nem backup – ezek rendelkezésre állást javítanak, semmi közük a backup/restore mókákhoz. Majd ezekután egy tudálékos angol MVP még egyszer megkérdezte ugyanezt. Látni kellett volna az illetékes PM arcát: többször is levegőt vett, hogy mond valami csípőset, majd mindig meggondolta magát – de nem jutott eszébe semmi udvariassági formula. (Egyébként sem nézett ki úgy, mint aki kettőnél többet ismer. És ebből az egyik a „How do you do” lehet.) Jól elpattogott a levegővétel/semmitmondás szélső értékek között.

Mondanom sem kell, itt is az SP1 játszotta a főszerepet, lévén, hogy az SCR ebben fog majd egyáltalán megjelenni. Naná, hogy ez nem tetszett a nagyérdeműnek.

Ja, hogy mi mit jelent?

  • CCR: Cluster Continous Replication
    Tulajdonképpen log shipping-ről van szó failover clusterbe telepített Exchange 2007 szerverek között. Láthatod, ez nem normális cluster, tulajdonképpen csak a tranzakciós logok replikálódnak egy megosztáson keresztül. Egy minden tekintetben kimerítő webcast sorozat elérhető itt.
  • LCR: Local Continous Replication
    Ugyanaz, mint az előbbi, de mégis más. Nem kell hozzá failover cluster, egyszerűen a log csak egy helyi merevlemezre másolódik biztonságilag. Látható, hogy ha a gép dől ki, akkor lőttek a biztonsági lognak is. És az is látható, hogy hiba esetén matyó asszonyok kellenek, akik visszakézimunkázzák az adatbázist.
  • SCR: Standby Continous Replication
    Gyakorlatilag arról van szó, hogy a teljes adatbázis – logokkal együtt – replikálódik egy másik Exchange2007 Sp1 szerverre. Ha az alapszerver megborul, egyszerűen berúgjuk az árokba – és már ott is van a helyettese. Részletesebben lásd itt. (Természetesen Russ is itt van. Fel is tette a kérdéseit. Szomorú vagyok, de a válaszokat nem értettem. Annyi rémlik, hogy a dumpsternél megzakkant a csapat, többen is kellettek, hogy összerakják a választ.)
  • DR: Disaster Recovery.
    Ezt azért tudhattad volna.

Ebéd után kettéváltunk. Az Exchange csapat egy része a levélpucolgatás mellett tette le a voksát (láttam köztük Jim Mcbee-t), a másik rész Evan Dodds-szal (Powershell project manager) félrevonult egy tárgyalóba Powershell-t vesézni. Én az utóbbi csapattal tartottam.
Elvonultunk egy félreeső szobába és családias hangulatú beszélgetés alakult ki. Előadás, az nem. Amikor azt mondtam, hogy „családias”, akkor nem egészen normális családra gondoltam: egy hapi meg egy nő igen keményen szívatta egymást – akár férj és feleség is lehettek volna. Mindenesetre az előadás után együtt távoztak. Volt olyan kérdés is, melyre a frappáns válasz annyi volt, hogy „Mars kifelé!” – de ezen mindenki jót derült. Én is, mert végre megértettem egy poént.
Nos, a beszélgetés során sok új dolog nem hangzott el, de az meglehetősen értelmesen. Többször láthattuk munka közben a demo ördögét (Evan valami frappáns szót használt rá, de olyan gyorsan mondta, hogy nem ragadt meg). Igazából az egész bemutató arra ment ki, hogy mi is az igazi erőssége a Powershell-nek, hol domborítja ki igazán a tudását. Nem, nem azokon a pontokon, ahol az 1.0 adminok elől elrejtett beállítások piszkálhatók. Éppen ellenkezőleg, pont az ő feladataikat könnyíti meg a tömeges módosítási lehetőséggel.
Persze ehhez ember kell, szálas. Az 1.0 admin nem fog shell parancsokat böngészni – ezzel szemben le fogja tudni futtatni az evolúció fejlettebb fokára jutott admin által írt szkriptet. (Ebből egyébként jött is egy kis vita. Biztonsági szempontből tényleg megrázó, hogy olyan ember kezébe adunk szkriptet, aki nem is tudja megállapítani, hogy az írás miről is szól – de a lefuttatásához meglesz a jogosultsága. Jellemző módon Evan még a kérdést sem értette. El sem tudott képzelni ilyen szituációt a valós életben. Azt mondta, hogy akinek ilyen szintű jogosultsága van, annak értenie kell a powershellhez.)

És tulajdonképpen ez volt az egész beszélgetés kicsengése. Aki előre gondolkodik, már most tanulja az Exchange 2007-et(1). Aztán pár hónap múlva, amikor megjelennek az égen az első fecskék és a többiek elkezdenek ismerkedni a termékkel, ő már a Powershell-t tanulja. Hogy tartsa a lépéselőnyt – hiszen az Exchange2007 adminisztrálás felső foka lesz a Powershell.

(1) Kivéve Fóti Marci. Van, aki képes egyből a Powershell-lel kezdeni.

2.nap

Ez egy érdekes kísérlet lesz. Megpróbálok úgy írni, hogy közben nem mondok semmit.
A mai fél napon ugyanis a két előadásnyi időben, sok apró előadásban az E14-ről hallhattunk érdekes dolgokat. Külön jó, hogy tegnap az Exchange2007 Sp1 volt terítéken – mintha a jó öreg Exchange2007 már nem is létezne.
Na most, E14. Gondolhatod, hogy itt tényleg harapnak az NDÁ-ra. Bár jó humoruk volt a srácoknak. Hagytak mindenkit fényképezni, nyomta is a plebs a fotókat a ppt-kről – aztán a végén megjelent a korábban már emlegett antipatikus főPM és udvariasan megkért mindenkit, hogy töröljék a képeket, mert különben gyorsított főbelövés.
Én viszont dacolok velük és írok a termékről. Kezdjük a legfontosabbal, a névvel. Az egyik MVP felrótta nekik, hogy az E12 után miért E14 a következő kódnév?
– Babonások vagyunk, azért – válaszolták – Baj?

És ha már a legfontosabb információt kiszivárogtattam, jöhetnek a kevésbé jelentősek is.

  • Például a stratégia. Az ugyanis látszik, és annyira nem is titkolják. Az Exchange2007 fogja törni az utat. Ha elkezdenek áttérni rá a cégek, az azt is jelenti, hogy elterjednek a 64 bites levelezőszerverek – azaz el lehet kezdeni igazi nagypályán focizni, jöhetnek a Datacenter kategóriájú levelezőszerverek. Mik is jellemzők erre a világra? Nagy teljesítmény, nagy rendelkezésre állás, fájdalommentes backup/restore illetve disaster recovery folyamatok. Azért valljuk be, mindegyik területen van mit fejlődnie az Exchange-nek. Fog is…
  • Nézegetem a jegyzeteimet… annyi mindenről jó lenne írni. De nem lehet.
    Azért nem tudom megállni, hogy a végére ne dobjak be egy sokkoló célozgatást. Az utóbbi évek alatt kezdted megismerni, megszelídíteni a Storage Group szervezésű adattárolást? Lassan kezdheted elfelejteni…

Most abbahagyom egy kicsit az írást, éppen dörömbölnek az ajtómon…

Aktívan

2007-03-06 / / 0 Comments

5 órája az ActiveSync-kel szopok. Amit be lehetett kapni, azt már mind bekaptam. Igaz, a feladat nem túl egyszerű: hozzunk szinkronba két laptopot és egy PDÁ-t.
Le kellene higgadnom, hogy pontosan leírjam a tapasztalatokat – de erre már nincs idő. Így csak átabotában:

  • A combine rossz. A combine gusztustalan. A combine opciót felejtsd el.
    A gond csak az, hogy nincs más. Amikor észleli ez a dög, hogy itt is, ott is vannak adatok, akkor a következő választást adja fel:

    • Combine a két hely.
    • Felülírjuk a PDÁ-t.
    • Nem csinálunk semmit.

    Ha te pont olyan helyzetben vagy, hogy a PDÁ-n vannak a jó adatok, akkor elvesztél. Csak a combine marad… meg a hajtépés. Ez az idióta ugyanis nekiáll gondolkodni. Helyetted. Például az összes családi ünnepet – a franc se tudja, honnan ismeri fel – berakja a ‘családi ünnep’ kategóriába. Ekkor természetesen mindegyik megduplázódik, mert lesz eredeti kategóriás, meg kiegészített kategóriás változat. A telefonszámok elől véletlenszerűen lehagyja a ‘+’ jelet – és ez természetesen megint duplázáshoz vezet. No, mindegy, kár is részletezni, a lényeg, hogy egy combine durván 3-4000 duplikált bigyót hoz létre. Minden alkalommal. Természetesen manuálisan kell kigyomlálnod a folyamat végén. Mindet.
    De akkor sem jársz jobban, ha van két totálisan összelőtt géped és mindkettőnél azt mondod, hogy mindkettő a PDÁ-t írja felül. A sokezer különbözet állandóan meglesz és egyszer csak meg kell nyomnod a combine gombot. Ahelyett, hogy lenne egy olyan opció, hogy a PDA írja felül a desktop gépet. Idióták.

  • Ez valószínűleg BB-t fogja érdekelni. Mivel nem győztem várni a tabletpc-re, először a benti géppel szinkronizáltam, kihagyva persze az emailt. Utána jött az otthoni gép – és nem engedte a levelek szinkronizálását, mert ezt mondta, hogy két partneri kapcsolat mellett ez lehetetlen. Azaz ugyanazt a hibát kaptam, melyet Jani is pár héttel ezelőtt. A különbség csak az, hogy nekem – ugyanezekkel a szoftverekkel, ugyanezekkel a hardverekkel ez a keresztszinkronizáció egyszer már működött.
    Nem részletezném az odavezető utat, elég csak a megoldás maga. Törölni kell mindegyik partneri kapcsolatot, majd először azzal a géppel kell kapcsolódni, amelyikkel email szinkronizációt is szeretnénk. Mivel ekkor még csak egy partner van, a szinkronizáció remekül létrejön. Utána jöhet a másik partneri kapcsolat, értelemszerűen itt már nincs emailszinkronizáció – de a többi működik.
    Most már csak azt nem értem, hogy ha ez működik, akkor miért kell kapásból tiltani, amikor fordított sorrendben rakom össze? Idióták a négyzeten.