Együtt működés

Ügyfél úgy érezte, itt az ideje, hogy felrobbantsa felújítsa az informatikai rendszerét. Előbb-utóbb sor került a levelezésre is. A következő peremfeltételek szorongatták a projektet:

  • A telepített rendszernek a meglévőnél robusztusabbnak kell lennie. (Ezt nem volt nehéz megígérnünk.)
  • Licenszelési szempontból támadhatatlannak kellett lennie. Ez egész konkrétan azt jelentette, hogy mivel a felhasználók számához képest egynyolcadnyi Windows és Exchange CAL állt rendelkezésünkre, a többieknek valamilyen alternatív, de valamelyest igényes levelezést kellett biztosítanunk. (A maradék 7/8 egyébként laptopos-bolyongós külsős ember.)
  • Természetesen mindenki ragaszkodott hozzá, hogy mindenhonnan elérje a levelezését, minimum webes felületen és mobiltelefonon. Nyilván az utóbbit push metódussal.
  • A cégnek egy darab publikus IP címe van. A határon egy Cisco eszköz kezeli le a forgalmat.
  • A költségkeret adott volt. Emiatt fel kellett használnunk a korábbi licenszeket, így is éppenhogy maradt csak valami zsé új hardverre és licenszekre.
  • A meglévő rendszerhez képest Augeias istállója chipgyár tisztasággal bírt. Természetesen úgy kellett elvégezni az átalakítást, hogy minél kevesebb fennakadás legyen.
  • Függetlenül attól, hogyan oldjuk meg a levelezést, az összes alkalmazottnak ugyanazt a névteret – @cegnev.hu – kellett használnia. Egymás között is.
  • A meglévő levelezés nem veszhetett el, át kellett kerülnie az új levelezőszerverekre. Szerencsére public foldert nem használtak.

Hosszas tanakodás után egy Exchange-Zimbra kooperáció mellett döntöttünk. Zimbra esetében nyilván az Open Source Edition jöhetett csak szóba. A webes elérés evidens volt, a mobilokhoz pedig jó lesz a Z-push.
A router mögé egy ISA 2006 SP1 került. Sokat nem válogathattunk, ehhez volt licensz. Első elképzeléseink szerint majd ez osztja szét jól a https forgalmat.
Ja.

A TCP/IP-ből következően egy socketre (IP:port) csak egy listenert tudunk rakni. A HTTPS működéséből következően egy website-hoz csak egy tanúsítványt tudok hozzárendelni. Eddig oké.
Csakhogy az ISA belekeverte a mókába az autentikációt is, méghozzá listener szinten. Azaz ha olyat akarsz csinálni, hogy egy IP címen fogadsz a 443-as porton különböző belső szervereknek szánt forgalmat (a tanúsítvány SAN vagy wildcard), és ezek a belső szerverek háklisan autentikálnak… akkor nagy bajban vagy. Mert a listener autentikál. Pontosabban, meg lehet neki mondani, hogy ne autentikáljon, de ekkor senkinek sem autentikál és ráadásul még ez sem igaz… de erről majd később.

Akkor nézzük, miből élünk. Egy külső IP címünk van, azaz a socketből már csak a porttal tudunk játszani. Tudnánk. Csakhogy az Android alap Activesync kliense – legalábbis a Samsung telcsiken – nem enged portszámot beírni. Mivel a külsősök között informatikus még csak elvétve sincs, szóba sem jöhet, hogy letöltetünk velük valami appot. Ha létezik egyáltalán jó ingyenes. Tehát a Z-push és az Exchange ActiveSync (EAS) https forgalomnak ugyanazon a porton kell bejönnie, azaz ugyanaz a listener kell, hogy lekezelje. Ugyanazzal az autentikációval. Fincsi. (Nagyjából igaz ez a webes elérésekre is. A felhasználó kiszalad a világból, ha ilyen címet kell megjegyeznie, hogy https://exchange.cegnev.hu:50443/owa.)

Oké, nézzük, be tudjuk-e gyötörni egy autentikáció alá ezt a négy forgalmat. Az OWA és az EAS berakható, jelenleg is így működik. A listener FBA-t használ, azaz formon keresztül bekéri a credential adatokat, valamelyik DC-ről autentikál, az autentikáció delegáció basic, azaz http/basic autentikációval dobja át a credentialt az Exchange szervernek. Mivel az egész kommunikáció HTTPS alatt megy, így a basic nem probléma. Viszont, mivel az autentikációt – beleértve az autentikáló szervert is! – a listenerben állítjuk, a Zimbra esetében gond lesz. Lehetne úgy persze, hogy a Zimbra felhasználókat felvesszük az AD-be, majd onnan autentikál a levelezőszerver – de ez már Windows CAL. Az meg nincs.

From Segédlet

Mik a szóbajöhető opciók? Domain, egyéb AD, Radius. Az első kapásból kiesik. A másodiknál fel kellene húzni egy Samba szervert a Zimbrán, a harmadiknál pedig kellene egy-egy Radius szerver mind a Windows tartományba, mind a Zimbra mellé. (Ez egy külön szépség a listener struktúrában. Egy listener csak egyféle autentikációt ismer. Habár azt meg tudom csinálni, hogy a bejelentkezéskor megadott domainnév alapján más és más Radius szerver autentikáljon, de azt nem, hogy a bejelentkezéskor megadott domainnév alapján az egyik esetben Windows LDAP tartományból, a másik esetben külső Radiusból autentikáljon.)
Na jó. Kérdés a linuxos kollégához: meg-e lehet-e oldani? E? Fejcsóválás. Ha sima postfix lenne, akkor menne, de a Zimbra ennél kompaktabb cucc. Ha a megkerülésével piszkálnak bele az alatta lévő dolgokba, azok nem maradnának ott állandóan.

Jó. Ez az irány nem működik. Az Exchange autentikációs beállításai nem jók a Zimbrának.

From Segédlet

Akkor mi a jó? Nem húzom az időt, egyfajta beállítással tudtam csak átgyömöszölni a Zimbra forgalmát: a listeneren kikapcsoltam az autentikációt, a szabályban pedig az autentikáció delegálásánál azt adtam meg, hogy a kliensek a célszerveren közvetlenül autentikálnak. Ekkor feljött a Zimbra FBA autentikációs képernyője. Ez ugyan nem öröm, hiszen általánosságban azért csak jobb az, ha már a tűzfal lerendezi az autentikációt, de ez van. Igenám, de jó lesz-e ez az Exchange-nek? Elméletileg jó lehet. A nagykönyv szerint, ahogy korábban is írtam, az a helyes beállítás, ha a listeneren form-based autentikációt állítunk be, a szabályban a delegálásnál basic autentikációt, az Exchange szerveren pedig szintén basic-et. (A tanúsítványokról most nem értekeznék külön. Az se volt egyszerű kör, de végül mind a két rendszert befaragtuk ugyanazon CA alá.) Ezt a konfigot rúgtam fel, úgy, hogy beraktam az autentikáció nélküli listenert, a szabályban átírtam a delegálást közvetlenre, az Exchange szerveren meg engedélyeztem az FBA-t. Bentről szépen működött is – kintről viszont azt kaptam vissza, hogy a szerver elzárkózott a kapcsolat elől. Jött némi vajákolás, engedélyeztem az FBA-t közvetlenül az Exchange IIS alatt is az OWA könyvtáron, de nulla eredménnyel. Megnéztem az ISA logot – és jó magasra felugrott a szemöldököm. Beérkezik kintről a https, az ISA terminálja… majd az Exchange felé már http-n megy tovább, mely próbálkozást az Exchange – jogosan – undorral dob el. De miért? A szabályban a bridging fül alatt nincs engedélyezve a http. Akkor ezt most hogyan? Ellenteszt. Visszaállítottam mindent, rögtön https-sel próbálkozott az ISA, az Exchange pedig elfogadta. Furdalt a kiváncsiság, megnéztem az itthoni tesztrendszeremben ugyanezt TMG-vel – és ugyanez lett az eredmény is. Fura. Ha azt mondom a TMG-nek, hogy ne erőlködjön az autentikációval egy linux szerver felé, akkor nem is variál… ha viszont ugyanezt mondom neki egy Exchange szerverrel kapcsolatban, akkor átvált http-re, még akkor is, ha ez nincs neki engedélyezve.

Nos, ennyi volt a történet. Szomorú sóhajjal arrébb rúgtam az ISA szervert és betettünk elé egy Apache proxyt. Ez ugyanis nem tűzfal, de nem is fenyegetés elleni gateway, azaz nem foglalkozik az autentikációval. Terminálja a HTTPS kapcsolódást, a host header alapján tudja, milyen irányba kell továbbdobnia a kérést, immár egy új HTTPS kapcsolattal. Azaz az OWA és EAS mehet az ISA egyik hálókártyájára, a klasszikus listenerrel, a Zimbra forgalma meg mehetne az ISA másik lábára a ‘ne nyúlj hozzá’ listenerrel. (Azért használtam feltételes módot, mert a linuxos vonalnak nem ez lett a vége, de így is lehetett volna.)

Megjegyzem, ha az ISA tudná az SNI-t (Server Name Indication), akkor még sokkal egyszerűbb lenne a dolog, akkor már a HTTPS terminálása előtt tudná a megcélzott host nevét, és ennek alapján ő maga tudna forgalmat szeparálni. De nem tudja. (Talán az UAG. De azt nem ismerem.)

Tulajdonképpen ezzel a webes eléréseket lerendeztük. Az SMTP, na az szintén jó móka volt, de most hagyjuk. Ugyanis hátravolt még egy publikáció: egy belső RDS szerver alkalmazásait is ki kellett publikálnunk a külsősök felé. RdWeb, RDGW. Csakhogy: 1 IP cím. Az RDGW pedig ugyanazon a 443-as porton szeretne nyomulni, amelyiken már így is nagy a zsúfoltság. Az Exchange listenerje nem volt jó neki, innentől úgy gondoltam, ugyanazzal a trükkel bánok el vele, mint a Zimbrával: az Apache átdobja egy újabb virtuális kártyára, azon pedig olyan listenert csinálok neki, amilyet szeretne.
Jó. De milyet szeretne?

  • Egyik módszer
    Ez egy tipikus MS howto a Technet Library-ből. Semmi extra, a jó öreg “pofabe” módszer: a listener nem autentikál, a delegáció pedig közvetlen.
  • Másik módszer
    Ez egy cikk az isaserver.org-ról, Marc Grote írta. Határozottan unortodox módszert követett, a listener autentikáció integrated (azaz ntlm), a delegáció kerberos constrained.
  • Harmadik módszer
    Egy másik cikk a Technet magazinból, viszont ezt két MS nagyágyú jegyzi: Shinder és Diogenes. A trükk az, hogy mivel itt ugyanazt az /RPC/* website-ot publikáljuk, mint az Outlook Anywhere esetében, hát csináljunk meg mindent az Exchange varázslóval. A listener autentikáció basic, a delegálás közvetlen.

Erre szokták azt mondani, hogy a bőség zavara. Kipróbáltam mind a hármat. Egyik sem működött.
Ahhoz már hozzászoktam, hogy nekem valahogy mindig jobban emelkedik a pálya, mint másoknak, de azért a függőleges fal még mindig meg tud lepni.
Az RDS szerver oldalán minden rendben volt, rdweb, rdgw, tanúsítványok, házirendek. (Pedig itt sem volt egyszerű a pálya, ha próbáltál már eligazodni a kilométer hosszú nevek között egy _magyar_ nyelvű szerveren, akkor tudod, miről beszélek.) Odáig mindegyik módszerrel eljutottam, hogy az rdweb oldalon megjelentek az rdp ikonok. (A harmadik módszernél pluszban felvettem az /rdweb/* útvonalat.) Utána viszont állandóan csak autentikációs ablakokat kaptam, akármit is csináltam, akármilyen credential-t adtam meg.
A megoldás természetesen pofonegyszerű, de az autentikációra utaló hiba megzavart, ezért állandóan csak azzal gyötörtem magamat. Beletelt egy napba, mire a fejemre csaptam és felhúztam a DMZ-be egy Windows7 gépet és közvetlenül arról próbálkoztam. Természetesen mind a három módszer működött, szó sem volt autentikációs hibákról.
Egész egyszerűen az Apache nem tudja proxyzni az RPC over HTTPS-t, azaz nem fog menni az RDP over HTTPS sem. Amíg csak az RDweb-ig megyek, addig oké, az tiszta HTTPS… de utána váltunk, az indián meg elhasal. Kész szerencse, hogy az Outlook Anywhere nem volt benne a projekt szkópjában, mert az sem működne.

A többi már nem túl érdekes. Az ügyfél kapott egy ultimátumot, miszerint vagy szerez egy másik IP címet, vagy kilógatjuk az RDS szervert valami lehetetlen porton, persze ebben az esetben övé a felelősség a biztonsági kockázatért. (Sőt, ha már lúd, legyen kövér, ebben az esetben kérünk még egy IP címet és kiváltjuk az Apache proxyt is. Mert mégiscsak egy spof, meg plusz kockázat.)
De ez már nem technológia probléma.

7 Comments

  1. Sztem az UAG sem tudja, viszont ott nem kell ilyesmi, mert _mindent_ be lehet terelni egyetlen portálba és kész. Ja és a WS12 IIS8 viszont tudja az SNI-t 🙂

  2. “RPC over HTTP” – az a baj, hogy ez a kellemetlenkedő protokoll igazából nem HTTP, azaz nem felel meg ennek:

    http://www.w3.org/Protocols/rfc2616/rfc2616.html

    Az apache meg elég vaskalapos ahhoz, hogy ne implementáljon a webszerveréhez valamit, ami nem felel meg a HTTP protokollnak. (Csendben hozzátéve, hogy különösen nem akkor, ha az a valami főként Microsoft körökben használatos.)

  3. @Zizi: Így van. Ha belegondolunk, hogyan működik az RPC, feláll az ember hátán a szőr, hogy mindezt megpróbálják belegyömöszölni a http-be. Viszont ha már megemésztettük a gondolatot, akkor kiderül, hogy egészen praktikus: mind az Outlook Anywhere, mind a Remote Desktop Gateway korrekt megoldások egy másképpen körülményesen megoldható problémára.

  4. hrongyorgy

    2012-06-24 at 02:16

    Viszont folyamatosan az jar a fejemben, hogy lehet, hogy nginx-szel viszont menne a dolog, ugyanis asszem neki lehet olyat mondani, hogy oregem, csak addig foglalkozz a HTTP protokollal, amig a szukseges fejlecek megjonnek, donts gyorsan, es passthru. Egesz egyszeruen azert, mert amig az Apache egy tosgyokeres webszerver annak minden hatranyaval, addig az nginx eredetileg is reverse proxynak irodott. Az, hogy implementaltak benne egy rohadt gyors webszervert is – na ez az, ami extra benne. Az Apache-ban viszont epp a proxy funckcio az extra.

  5. csipem az apachet, de eszembe nem jutna proxykent hasznalni.
    hazudnek, ha azt allitanam, hogy pontosan lekovettem a mit-hova passzolunk manovereket, — ehhez meg legalabb 1x ujra kell olvasnom a cikket — de elso nekifutasra meg kell kerdeznem : a squidra nem is gondoltatok ?

  6. @hokuszpk: a squid elsosorban sima proxy nem reverse proxy. A reverse proxyra inkabb az nginx jo.

  7. lehet.
    ettol fuggetlenul squiddal a legutobbi ket randevunk reverse proxy modban volt, es ha joltudom ( bar sosem probaltam ) tud mit kezdeni az rpc over https -el.

Leave a Reply