10. A kiterjesztett protokoll-támogatás
Az ISA 2000 (egyébként nem kevés elemet tartozó) előredefiniált protokollkészlete kibővült az ún. IP szintű protokollok támogatásával. Így válik lehetővé a TCP, az UDP és az ICMP protokollok mellett például az említett PPTP kiszolgáló publikálás (IP 47), vagy a ping és tracert használata a kliensoldali alkalmazásokból, vagy akár az előző pontban említett IPSec forgalom engedélyezése.
11. A komplex protokollok használata
A streaming média és az egyéb audio/video forgalmat képező alkalmazások arra kényszerítik a tűzfal szoftverek készítőit, hogy komplex, többszörös elsődleges és másodlagos protokoll támogatást is beépítsenek a termékeikbe. Az ISA 2000-nél állítólag (bevallom ilyet anno én nem csináltam sosem vele), ezeknek az igényeknek megfelelve bonyolult szkriptekkel kellett megtámogatni illetve kibővíteni a kimenő forgalom elsődleges protokollszabályait. Az viszont bizton állíthatom hogy az ISA 2004-nel nincs erre szükség, az új protokoll varázslóval ez nem okoz gondot, felvehetünk több elsődleges illetve másodlagos protokollt is. (Kapcsolódva a témához zárójelben megjegyzem, hogy a házon belüliek mellett a konkurens streaming média szerverek alkalmazásszűrői is szép számmal képviselve vannak az ISA 2004-ben.)
12. Testreszabható protokoll definíciók
Amikor az ISA 2004-ben egy tűzfal szabályt kreálunk, akkor van lehetőségünk arra, hogy bármely protokoll tulajdonságai között (a panel jobb alsó sarokban keressük) határokat szabjunk - vagy ellenkezőleg: egyáltalán ne limitáljuk - a használható forrás- illetve célportok tekintetében. Ez a lehetőség értelemszerűen megtalálható a publikáló szabályoknál is, kibővítve a tűzfal és maga a publikáló szerver vonatkozó portjainak megszorításával együtt.
13. ISA felhasználói csoportok
ISA 2000 esetén ha szeretnénk felhasználók szerint különbséget tenni pl. az internet elérés fokozataiban, azaz hitelesítéshez kötjük a web proxy használatát, akkor a felhasználói fiókokat csak a lokális felhasználói adatbázisból vagy az tartományi címtárból vehettük - közvetlenül. Ez egyúttal azt is jelentette, hogy ha teljesen logikusan csoportokat szerettünk volna létrehozni ezeknek a fiókoknak, a hozzáférés mértékének megfelelően, akkor ehhez ezeket a forrásokat többnyire rendszergazdai jogosultsággal kellett elérnünk és muszáj volt pl. közvetlenül a címtárban matatnunk. Ennek akár vége is lehet, mert az ISA 2004-ben közvetlenül is hozhatunk létre csoportokat, majd azokba bele helyezhetjük a különböző névterekből (pl. az AD-ból) betallózott felhasználókat, csoportokat. Nagyobb szervezetek esetén ez azért is fontos, mert ennek megfelelően el lehet szeparálni egymástól az "ISA Admins" és a Domain Admins csoportokat (ellenben a helyi rendszergazda csoportban továbbra is bent kell lennie az ISA-t telepítő / üzemeltető felhasználói fióknak).
14. A tűzfal kliens jogosultság továbbítás
Már a korábbi ISA-nál is működött az a lehetőség, hogy a tűzfal kliensek gyorsítótárra vonatkozó alázatos kéréseit a HTTP Redirector elküldte a web proxy szerviznek, ergo a tűzfal kliensek is megkaphatták a gyorsítótár tartalmát. A bibi a dologban csak ott volt, hogy a felhasználói jogosultságok egyúttal elvesztek ebben a folyamatban és ha muszáj volt a web proxynak azonosítania, akkor a kérés gyakorlatilag negligálódott és ez így eléggé szomorúan hangzik, de igaz. Ennek apropóján viszont elmondhatom, hogy az ISA 2004-ben elképesztően jó irányba alakult át a web proxy szolgáltatás illetve a függőségi viszonyai, azaz nincs többé külön web proxy szerviz (alkalmazásszűrő lett belőle, amelynek csak előnyei vannak a korábbi implementációhoz képest), nincs többé HTTP Redirector, van viszont intelligens HTTP filter, ami egy-egy az egyben képes átadni minden adatot pl. a tűzfal kliens és a gyorsítótár közötti forgalomban (is, mert az SNAT kliensek ugyanilyen kéréseivel is ez a helyzet, csak ott nem beszélhetünk jogosultságokról és hitelesítésről). A web proxy szolgáltatást viszont ebbe a körbe már nem szükséges bevonni, ergo ez a probléma is a múlté.