ISA 2004 – éles üzemben

Pénteken átálltunk. 14 saját protokol, 15 csoport, 2 computer object, 12 computer set, 4 web listener, egy URL set, 3 dmoain name set és 34 szabály, létrehozására, beállítására volt csupán szükség. Azt gondolom, hogy az ISA 2004-ben nem lehet csalódni. Azt és úgy tudja, ahogy azt ígéri, de ez persze nem mentesít attól, hogy a lelke mélyére bele  kell  látni. Összeszedem csokorba azokat a apróságokat, amelyekkel sokat küzdöttem, tanulságuk az "utánam jövőknek".
 
AZ ISA kezelőfelülete remek, átlátható, és még a gyökeresen más ISA 2000-ről is könnyű átszokni. Különösen a tűzfalszabályok tűnnek első látásra is teljesen érhetőnek. Nagy ugrás ez, hurrá. A tűzfal szabályokat a jobb oldalon egy "Toolbox" segíti, hogy a szbályokhoz szükséges elemeket, többek között a protokollokat létre lehessen hozni, esetleg a meglévőket lehessen módosítani. Az ISA felépítésekor, áttéréskor, csőstül jönnek a felhasználók definiálta saját protokolok. Jó lett volna, ha most is táblázat formára nyithattam volna a toolbox-ot (ahogy ez annak idején az ISA 2000-nél volt), mert rögtön látni lehetett volna, mely típusokat nem definiált még az ISA 2004, és melyek léteznek már a fejlesztők jóvoltából beépítve. Sajna a toolbox mérete adott,
táblázatról pedig szó sem lehet. Sebaj, átnéztem egyesével mindet, végül is hamar túlesik az ilyesmin az ember.
 
A tűzfal szabályok nézete még egy apró hiányossággal rendelkezik. Bár sorba rendezhetők a szabályok tetszés szerint, és azt is megadhatjuk, hogy milyen mezőket (oszlopokat) lássunk, szűrni, filterezni nem lehet, legfeljebb a beépített rule-okat jeleníthetjük meg, vagy rejthetjük el. harminc beépített és  még ennél is több saját szabály mellett már nem olyan könnyű eligazodni szűrés nélkül, még kevésbé kényelmes a szabályok helyes sorrendjének meghatározása. Apropó sorrend. Azt tapasztaltam, hogy az első olyan szabálynál, amely hitelesítést kér, elhasalt az összes SecureNAT kliens. Így aztán azokat a szabályokat mind ezen tiltó szabály elé kellett helyeznünk. A munkát azzal könnyítettem, hogy szabálykategóriákat állítottam fel. Így a SecureNAT szabályok általában RENDSZER, vagy SERVER előtagot kaptak, míg a felhasználók hozzáféréseit a USERS előnévvel illettem. Így már kicsit áttekinthetőbbé váltak a szabályok és könnyebb volt sorrendet is megadni.
Az VPN-RRAS témában két mókás történet is adódott a hétvégén. Pénteken kb. fél hétre álltunk azon a szinten, hogy már haza lehetett menni, pareto elv szerint a munka 80%-a kész volt az idő 20%-a alatt. Fürdetés, gyereklefektetés után már otthonról, VPN-en keresztül álltam neki tűzfalat konfigurálni – ami, ugye,
tudjuk, lehet veszélyes is, hiszen az alattam lévő kapcsolatot szapultam. Mindegy, este 8 és éjfél között nagyszerűen ment minden, aztán egyszerre csak kivágott a VPN és vissza sem engedett. OK, gondoltam, tényleg elvágtam magam alatt a fát, majd holnap megnézem bentről, mi is történt. Nos, a kritika nélküli módszerátvétel áldozata lettem.
(Egy pár mondatos kitérő: azt mindenki tudja, hogy az ISA az RRAS-t használja a VPN kapcsolatok létrehozásához, ám teljes mértékben ráül, ő konfigurálja. Ezért aztán amikor VPN-ről és ISA 2004-ről van szó, akkor a tanácsok egyike az, hogy "hagyd az RRAS mmc konzolt, bízz mindent az ISA-ra.)
Amikor még a Windows 2003 felkeményítésén dolgoztam és megtaláltam a Shinder Bá’ idevonatkozó cikkét, kritika nélkül átvettem azt a kitételét, hogy a szerep között ne szerepeltessem az RRAS-t. Később a szolgáltatások listájánál sem vettem észre, hogy a fenti szerep kivétele azt eredményezte, hogy az RRAS "Diabled" státuszt kapott. Szerencsére vagy szerencsétlenségemre az SCW szabályrendszerét egy GPO-ba exportáltam és azt alkalmaztam a tűzfalra, így éjfélkor, a GPO rendes újraalkalmazásakor az RRAS leállt. A megoldás is triviális volt, csak a GPO-ba kellett belenyúlni.
A másik fejjel a falnak szituáció az RRAS házirendekkel kapcsolatban ért. Az rendben van, hogy az ISA készít egy RRAS házirendet, és azt 1-es számmal az RRAS házirendek közé biggyeszti. Azt azonban már csak a működés közben tapasztalja a jóhiszemű rendszergazda, hogy a galád ISA nem csak ezt csinálja. Őrködik is a csemetéje felett. Módosítod ezt a házirendet? Visszaírja az eredeti értékeket! Lejjebb helyezed a házirendek sorrendjében? Visszatolja a sajátját az egyes pozícióba. Megkerestem, hogyan vágjam át a palánkon. Hát így:
  1. Létre kell hozni a helyi ISA-n operációs rendszerében egy csoportot, és nem kell beletenni senkit. Pl: Dummy RRAS Group
  2. Ezt a csoportot kell hozzárendelni az ISA konzol megfelelő VPN konfigurációs lapján
  3. Hagyni kell, hogy az ISA RRAS házirendje legyen az első a házirendek között
  4. Készíteni kell egy saját RRAS házirendet és azon beállítani mindent. (Pl.: hogy hagyja figyelmen kívül a felhasználók dial-in beállításait, meghogy csak VPN közegre jusson érvényre a házirend stb.) ISA a palánkon
És akkor végül pár mondat az OWA FBA-ról. A rendszergazdák mind egy cipőben járnak. Ismét csak Shider bá’ írt egy cikket arról, hogy a felhasználók képtelenek pontosan megadni egy hivatkozást egy böngészőben. Ha például azt kellene írniuk, hogy https://owa.mal.hu/Exchange, akkor csakazértis https://owa.mal.hu-t fognak írni. Na a cikk azt írja le lépésről lépésre, hogyan trükközhetünk az ilyen hibák ellen. Az említett háromból egyet oldottam meg, a másik nem lényeges, az igazi megoldás meg fizetős, úgyhogy azt kihagytam.
Nos, ennyi. Elkezdődött az élet az ISA 2004-el.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: