Web Application Proxy és ami körülötte van

Írásom célja az, hogy tisztázzuk, hogy mi ez a technológia, mert a félreértések melegágya. A Web Application Proxy (továbbiakban WAP) egy kiváló reverse proxy megoldás ami a Windows Server 2012 R2-ben jelenik meg. A release preview verzióban bent van.

A WAP a távelérési technológiánkat egészíti ki és a kép így most platform oldalról tökéletesen kerek (pár év múlva úgy is azt mondjuk majd, hogy hiányzik innen még pár építokocka). Most ezek vannak:

• A Windows Server RDS Gateway -- segítségével VDI és Session host (aka terminal server) eroforrásokat tehetünk elérhetové a felhasználóknak.
• Windows Remote Access --  segítségével VPN kiszolgálót és / vagy Direct Access kiszolgálót alakíthatunk ki, amivel a belso hálózatot tehetjük elérhetové a felhasználóknak.
• WAP --  segítségével pedig a belso hálózatról tehetünk elérhetové Web alkalmazásokat a felhasználóknak.

Kiválóan összefoglalták ezt már helyettem a következo dián:

A WAP architektúrát “200km magasból” szemlélve, helyesen így ábrázolhatjuk:

Lelkesen ezen a ponton csattanhatunk fel, hogy jéé hát ez kb. olyan mint a TMG. Közben pedig NEM. De még csak nem is UAG ez. Nem kísért itt semmiféle szellem, ez IT.

Lássuk be, hogy a WAP valóban alkalmas web alkalmazások publikációjára, de nem úgy mint a korábbi TMG / UAG páros bármelyike.

A WAP (jelenleg még) egy speciális eszköz ami a BYOD trendet támogatja. Biztosan mindenki találkozott már azzal az igénnyel, hogy a fonöke szeretné az új “retinaégeto” eszközérol elérni a vállalati csoportmunka webhelyet, vagy böngészni a belso Intranet oldalt. A legkülönbözobb válaszreakciók születnek erre az egyébként tökéletesen jogos igényre:

• OK, publikáljuk ki. – de ekkor nem csak a fonök fogja azt elérni és nem csak arról az eszközérol
• Nem, nem tesszük elérhetové. – a fonök mérges lesz és azt fogja mondani, hogy nem vagyunk elég modernek
• Csináljunk VPN-t. – a fonöknek nem tetszik, kényelmetlen, nem tudja bedugni a smart-card-t stb.
• Használjunk DA-t. – a fonök ragaszkodik az eszközhöz, tehát nem lehet. Az IT közben jót szórakozik a DA-val és imádják.
• Csináljunk egy virtuális gépet a fonöknek és publikáljuk ki, RDP csak van az eszközén. – jó, de itt kolompot akasztottunk a pingvinek nyakába, vagy ha úgy tetszik akkor fából vaskarikát csináltunk, végül csak Windows-on köt ki a felhasználó. Ne feledjük, a fonöknek is van fonöke és kollegája és és és…szóval ez nem mehet a végtelenségig, vagy ha igen akkor az drága lesz, mert sok virtuális gépet kell majd futtatnunk.

Ha kicsit jobban belegondolunk, akkor észrevehetjük, hogy az alapveto probléma itt a következo (általában): nem akarunk a hálózatra csak úgy beengedni bármilyen nem menedzselt gépet. Ez egy nagyon régi probléma amire a történelem során már sok megoldást kiötlöttünk. A legújabb a WAP és nem ez az utolsó ebben biztos vagyok. Csak pár példa a múltból:

   

Távelérési technológia	Eszköz azonosítási technológia
VPN	Remote Access Quarantine (10 éve debütált); késobb Network Access Protection
Web publikáció	IAG 2007 ssl VPN kliens azonosítással, emlékszik még valaki erre?
Direct Access	Network Access Protection
RDS	Network Access Protection

  

Nagyon NAP szagú a megoldáskészlet. Ami jó, mert egy csodálatos technológia. De vajon hány hazai vagy külföldi ügyfélnél van NAP? Két nagyobb hazairól tudok és ha a nagy ügyfelek nem vezették be tömegesen, akkor a kicsik sem. További hátrányai a NAP-nak:

• csak Microsoft platformon érheto el, a kezdeti Cisco együttmuködés hamar elsüllyedt
• nincs lényegi reportolási lehetoség
• beépített ellenorzési képességek nagyon nehezen egészíthetoek ki egyedi ellenorzésekkel

Mindezt figyelembe véve már nem is annyira meglepo, hogy a NAP deprecated státuszba került a Windows Server 2012 R2 preview bejelentésével egyidoben. A Windows Server 2012 R2-ben és Windows 8.1-ben még bent van / lesz. Az újabb Windows verziókban azonban a jelenlegi információk szerint nem lesz többet. Bejelentés itt (több egyéb funkcióval): Features Removed or Deprecated in Windows Server 2012 R2 Preview

A fenti táblázatban levo technológiák amúgy is jó 5-10 évesek. 5-10 évvel ezelott a végfelhasználói eszközkészlet egészen másként nézett ki, mint napjainkban. Az akkori technológiákat hiába is forgatjuk, a mai eszközökkel és a mai felhasználókkal (igazából az elvárásaikkal, az igényeikkel) nem állnak össze egységgé. Valami más kell. Itt jön be a képbe a BYOD és a WAP. A BYOD és az alapveto probléma (nem akarunk a hálózatra csak úgy beengedni bármilyen nem menedzselt gépet) nagyon nehezen egyeztetheto össze. De fúrjunk kicsit mélyebbre.

Mi számít menedzselt gépnek? Egyszeru megfogalmazás, de talán muködik: az amirol az IT tud és amin az IT tud futtatni programokat. A menedzselt gépek általában kivételes helyzetben vannak, nekik szabad azt is, amit másnak nem, vagyis hozzáférhetnek olyan szolgáltatásokhoz is, amit más gépekrol nem lehet elérni. Így hát a megoldás adott. Rendeljük hozzá egy felhasználóhoz az ilyen gépeket, akkor az IT már tud róla, bekerül a megfelelo technológiai rendszerekbe és máris tudunk ez alapján döntést hozni a hozzáférési kérelmek kiértékelése során. Natív Microsoft környezetben ez a legegyszerubb dolog a világon. Be kell léptetni a számítógépeket a tartományba. De mi a helyzet az otthoni Windows géppel vagy a nem Windows alapú eszközökkel? Azokat nem tudjuk egyszeruen beléptetni a tartományba. Helyette valami más, lazább kapcsolat szükséges. Az új elképzelt világunkban ez az úgynevezett Wokrplace Join. A Workplace Join egy laza kapcsolat: a számítógép a vállalati környezet és felhasználó között.

A WAP pedig a Workplace Join egyik fontos pillére. A Workplace Join funkció segítségével regisztrálhatják a felhasználók a saját gépeiket az IT technológiai környezetében és így menedzseltté válik. Regisztrálni lehet a belso védett hálózaton keresztül, vagy az Interneten keresztül is. Ezt a regisztrációs az Internetre a WAP segítségével publikálhatjuk.

A WAP segítségével összességében publikálhatjuk:

• Workplace Join szolgáltatást
• Work Folders szolgáltatást
• Egyéb webes szolgáltatásainkat

A WAP egy nagyon egyszeru alkalmazás proxy kiszolgáló. Annyira egyszeru, hogy még Authentication (AuthN) és Authorization (AuthZ) szolgáltatást sem tartalmaz. Ezek a funkciók teljesen outsource jellegu kiszervezésben vannak. AuthN és AuthZ szolgáltatást ADFS biztosítja. Egy aránypárral tudom ezt az összefüggést a legjobban leírni:

• A RADIUS szerver úgy aránylik az ISA-hoz, ahogy az ADFS aránylik a WAP szerverhez

Tehát ha ismered a RADIUS és ISA kapcsolatát, akkor részben ismered az ADFS és a WAP viszonyát is.

A WAP szerver nem dönti el, hogy van-e hozzáférésed vagy sem. Egyszeruen továbbítja a kérést az ADFS szervereknek és majd azok döntenek a szabályrendszer alapján. Azonban tudni érdemes, hogy a WAP szerver nem játssza el a színjátékot a kliens felé. A kliens valójában egy ADFS azonosítással és annak végeredményével (ADFS cookie) találkozik.

Nézzünk egy egyszeru példát. Adott egy Web Application Proxy, egy ADFS környezet és egy fontos üzleti alkalmazás (LOB). A LOB alkalmazás a https://lob.fabrikam.com címen van publikálva, az ADFS pedig a https://sts.fabrikam.com elérési úton. Az architektúra így néz ki:

Az azonosítási folyamat a következo (nagyvonalakban):

• A user csatlakozik a WAP szerverhez és szeretné elérni a https://lob.fabrikam.com címen az alkalmazást
• A WAP szerver ellenorzi a konfigurációját, hogy ilyen alkalmazás publikálva van-e, ha igen, akkor a kliensnek visszaküld egy HTTP 302-es üzenetet (redirect) és átirányítja azt az ADFS szerverhez. Ebben a redirectben azt mondja a kliensnek válaszként, hogy a https://sts.fabrikam.com –hoz csatlakozz.
• Az ADFS szervert a WAP publikálja, tehát a kliens visszajut a WAP szerverhez, de ezúttal a kérése az, hogy az ADFS szerver adjon neki egy ADFS sütit. A WAP szerver a felhasználó nevében egyeztet az ADFS szerverrel. A kliens által küldött ADFS auth kérésben szerepel az is, hogy melyik szolgáltatáshoz szeretne hozzáférni, ami esetünkban a https://lob.fabrikam.com.
• Az ADFS szerver megvizsgálja a kérést, egyeztet az Active Directory-val és dönt, hogy a felhasználó az adott alkalmazást elérheti-e vagy sem. Technikailag ezen a ponton van lehetoség arra is, hogy megvizsgálja, hogy az adott kliens géprol is elérheti-e a felhasználó az adott alkalmazást (aka végpont azonosítás, a cél azonos mint a NAP esetében). Ha a felhasználó elérheti, akkor a WAP-on keresztül egy ADFS sütit visszaküld a felhasználónak, amit a gépén tárolunk.
• A felhasználó az ADFS sütivel együtt újra megpróbálja elérni a https://lob.fabrikam.com alkalmazást. Az ADFS sütit a WAP szerver elfogadja és Kerberos Constrain Delegation (KCD) segítségével a felhasználót megszemélyesítve továbbítja a kérést a LOB alkalmazásnak. A LOB alkalmazás azt látja, hogy bejövo kérés a felhasználó nevében (user security context) érkezik. Méghozzá Kerberos azonosítással.
  • ahhoz, hogy a KCD muködjön, a WAP szervert fel kell jogosítani arra, hogy Kerberos Delegation-t használhasson, méghozzá KCD-t. Ez röviden annyit tesz, hogy az általa bármilyen azonosítási protokollal, de azonosított felhasználók nevében Kerberos ticket-et igényeljen és azzal érje el az alkalmazásokat.

Most már nagyjából látjuk és értjük, hogy mire való a WAP szerver és hogy egy azonosítási folyamat miként megy végbe. Egy fontos témakört azonban még nem hoztam elo. A WAP szerver segítségével nem csak ADFS azonosítást használva publikálhatunk alkalmazásokat.

Összesen két módszer van a publikálásra:

• ADFS – a korábban ismertetett muködési móddal. A publikált alkalmazásnak támogatnia kell a Kerberos azonosítást. A kliens oldali alkalmazásnak támogatnia kell az ADFS azonosítást.
• Pass-through – ebben az esetben nem történik a WAP szerveren azonosítás. Egyszeruen pre-auth nélkül publikálhatjuk a webes alkalmazásainkat az Internetre. Az alkalmazásnak nem kell ismernie a Kerberos azonosítást, a klienssel szemben nincs semmilyen követelményünk.

A WAP szerver igazi elonye a TMG / UAG párossal és a NAP integrációval szemben az ADFS alapú azonosítás használatával élvezheto. Pass-through módban publikált alkalmazások esetében nincs semmi lényegi elonye. És ezen a ponton kell, hogy összeálljon a kép minden Exchange és Lync adminisztrátornak. Amennyiben még nem teljesen tiszta, akkor az alábbi kérdéseket próbáljuk megválaszolni:

• Az Exchange / Lync támogatja a Kerberos azonosítást? – részben. HA környezetben alapértelmezett módban nem muködik a Kerberos azonosítás. Extra konfigurációt igényel amit nagyon-nagyon kevesen végeznek el. Az Exchange Server 2013 esetében pedig extra komplikált ez a beállítás és a pre-Vista klienseket részben kizárjuk.
• Az Outlook / Exchange ActiveSync / Lync kliens támogatja az ADFS azonosítást? – Nem. Nincs sok magyaráznivaló. Nem és kész.

A fentiek okán Exchange és Lync esetében a legtöbb amiben szakmailag gondolkodhatunk az egy Pass-Through módban történo publikálás a WAP-al. De miért tennénk ezt? Ha most UAG / TMG segítségével publikáljuk, akkor nincs ok amiért a WAP-ra kellene váltanunk. Csak veszíthetünk vele. Pre-authentikálni nem tudjuk a kéréseket és látható, értheto – legalábbis remélem az elozo sorok alapján –, hogy a WAP a BYOD iniciatíva mentén egy szép új modern világra készült. A legacy szolgáltatások publikációjának kiváltása nem cél.

A WAP, a BYOD, a Workplace Join, a végfelhasználói eszköz azonosítása stratégiailag fontos irány számunkra a publikációban. A TMG és az UAG nem romlott el az elmúlt 1 évben, szóval lecserélése még nem indokolt. A végfelhasználói eszközök és az alkalmazott programok számára az ADFS azonosítás egyre nagyobb teret fog kapni a következo idoszakban. De ma még nem ez a helyzet. Ha mindezt most összefozzük, akkor a végszámlán az szerepel, hogy a WAP-al ne akard publikálni az Exchange és a Lync alkalmazást. Még ha esetleg azt is mondjuk, hogy pass-through módban támogatott lesz. Használd bátran tovább a TMG / UAG páros neked tetszo változatát, ahogy tetszik. A WAP-al ma még nem ez a célunk. Azonban a BYOD, a Workplace Join, a böngészo alapú alkalmazások esetében az irány tiszta. Itt az ido ezzel a szép új világgal megismerkedni és kialakítani, mert a trend nyílvánvaló, a haszon az IT és a végfelhasználó számára szintén könnyen belátható és értelmezheto.

u.i.: igen a képeket a korábbi konferenciáinkból ollóztam össze.

Comments

• Anonymous
  January 01, 2003
  Hello Balu,Sajnos több. Lent pár link segítségként. A gond az, hogy ha van HA / NLB megoldásod, akkor az SPN-t egy közös security alanyhoz kell rendelni. Ezek a szoftvereink alapértelmezésben nem egy közös service account nevében futnak. Így aztán nem egyértelmű az, hogy kihez / mihez kell regisztrálni az SPN-t. Mindkét terméknél az a megoldás, hogy egy közös account-t létre kell hozni, az SPN-eket ahhoz kell regisztrálni és a szoftvert rá kell beszélni arra, hogy a bejövő Kerberos ticketeket ennek a közös accountnak a nevében dekódolja.Remélem ez segít.Az Exchange Server 2010 esetében: - technet.microsoft.com/.../ff808313(v=exchg.141).aspx - blogs.technet.com/.../recommendation-enabling-kerberos-authentication-for-mapi-clients.aspxAz Exchange Server 2013 esetében majdnem pontosan így megy, de arra még nincs dokumentációnk. Kicsit változik / változott.Lync 2013 esetében:- technet.microsoft.com/.../gg398976.aspxLync 2010 esetében:- technet.microsoft.com/.../gg398976(v=ocs.14).aspx
• Anonymous
  July 02, 2013
  Szia Zoli! Kérdezném a "Az Exchange / Lync támogatja a Kerberos azonosítást? – részben" résznél, hogy ez csak SPN konfigurációt jelent HA-nál, vagy ennél több? Köszönöm...