15. RADIUS névtér a hitelesítésnél
Ahogyan említettem a jogosultságok, hitelesítési lehetőségek eszköztára is kibővült. Ez azt jelenti, hogy egyáltalán nem szükséges az Active Directory direkt használata, azaz egyáltalán nem kötelező beléptetni a tartományba az ISA kiszolgálót, akkor sem ha a címtárból szeretnénk felhasználói fiókokat, csoportokat használni. A RADIUS névtér elsődleges használata persze azt eredményezi, hogy pl. UNIX platformról érkező hitelesítési kéréseket is képes feldolgozni az ISA 2004 web proxy-ja, azaz a RADIUS-on keresztül érkező felhasználók kiszolgálója is lehet egy ISA Server 2004. Sőt, mondok jobbat, pl. VPN kliensek esetén képes az ISA Server 2004 a felhasználói nevek automatikus hozzárendelésére, azaz az ún. "user mapping"-ra.
Mindent összekötünk mindennel
Ez az opciót azért találták ki, hogy az értelemszerűen nem egy tartományból érkező, ergo Windows-os hitelesítésre képtelen felhasználói fiókot megfeleltessünk egy tartományi felhasználóként. Így ha egy azonos nevet kreálunk a címtárban, akkor gyakorlatilag össze is kötöttük (de csak az ISA-n érvényesülő) jogosultsági szempontból a két névteret. Ha ezt megtesszük, akkor a RADIUS-on már túljutott (hitelesített) felhasználót az ISA 2004 firewall szervize az adott tűzfal szabálynak megfelelően feljogosítja a web proxy használatára, ugyanúgy mintha a Windows névtérből érkezne. Tetszetős kis folyamat, nem?
Visszatérve az ISA 2004 tartományba léptetésének szükségtelenségére, a megoldáshoz szintén a RADIUS-t, illetve a Windows RADIUS-át, az IAS-t (Internet Authentication Server, azaz egy teljesen RFC kompatibilis, Windows Server 2000/2003 alá egyaránt feltelepíthető komponenst) kell használnunk. Egyszerűsítve a leírást, ekkor az ISA 2004 RADIUS kliensként viselkedik, az IAS lesz a kiszolgálója, és az IAS lesz egyúttal a kapocs a címtár és az ISA között. Ha az ISA web proxyjának szüksége lesz hitelesítési információra, akkor végigjárva ezt az utat, megkaphatja a címtárból. E megoldás feltétlen előnye, hogy teljesen elválasztjuk az ISA kiszolgálónkat a tartománytól, azaz az (alapesetben meglehetősen) paranoid tűzfalgazdák is nyugodtabban alszanak. Plusz információ, hogy többek között ezt is kipróbálhatjuk egy hivatalos ISA MCP tanfolyamon, személyesen is tudom garantálni, hogy megfelelően működik ez a felállás :D.
16. A "Basic" hitelesítés delegálása
A publikált webszervereknél (nemcsak a sima IIS mappáknál, hanem Exchange OWA, FBA, RPC over HTTP, stb. esetén is.) az ISA 2004 átveszi a jegyvizsgáló kalauz szerepkört, azaz még a belső webszerver előtt megvizsgálja a hitelesítési információkat, és el is bírálja ezeket. Ez egy kedves gesztus, hiszen így kevésbé terheljük a belső webszervert, ráadásul a nem passzoló kérést nem engedjük be a belső hálózatba, már a kapunál lebukik. Azonban logikusan gondolhatnánk azt is, hogy akkor még egyszer meg kell adnunk a minimálisan szükséges usernév / jelszó párost az ISA-n túljutva, a webszerver kérésére? Szerencsére nem, az ISA szépen továbbadja ezt az információt a webszervernek, ergo nem lesz duplikált hitelesítés. Ez egy szép kerek történet, ami hiányzik még belőle: a megvalósításhoz keressük fel az adott publikáló szabályunkat (egyesével) és pipáljuk be a "Forward Basic authentication credentials (Basic Authentication)" négyzetet a "Users" panelen.
17. Valós IP információk a webszerver logban
A jelenlegi állapot szerint nem sok minden derül majd ki a webszerver logból
Akár jelentéktelen dolognak is tekinthetnénk eme opciót, de azért gondoljunk bele: jobban örülnénk, ha a belső webszerverünk naplói az ISA kiszolgáló belső IP címét tartalmaznák állandóan, az igazi "érdeklődők" IP címei helyett? Kissé nehéz lenne ebben az esetben például korrekt statisztikát készíteni, mivel az ISA IP-je mindent vinne, hiszen a webszerver nincs közvetlen kapcsolatban a nagyvilággal, csak az ISA kiszolgálóval.
