Skalp – OWA, OMA, Activesync

Ezt a sápadtarcút is levadásztam. Sokáig tartott, akár azt is mondhatnám, hogy egy évig, de mégis. Olvasom (és persze szinkronizálom) a leveleimet az Exchange postaládámból az i-mate-el.

Haladjunk időrendben. Az utolsó bejegyzést a projektről akkor írtam, amikor az Exchange 2003 SP2-t telepítettem. Egy kicsi, apró lépés a sok közül. A teljes tevékenységlista nagyjából az alábbi volt:

 

1. Exchange 2003 migráció (erről bőven írtam itt, itt, itt , továbbá ezen, meg ezen, meg ezen (több részben is) meg itt)
2. Smartphone beszerzés Windows Mobile 5 verzióval
3. Exchange 2003 SP2 telepítés, hogy a lehető legtöbbet kihozhassuk a kliensből.
4. PKI infrastruktúra létrehozása (Egy Offline Root CA és egy Enterprise Issuing CA, némi előzmény itt)
5. Tanusítványok kiszórása a fürttagokra, a tűzfalra
6. OWA kiajánlás ActiveSyncestül
7. A kliens és a szerver "összelövése"

 

Elég macerásnak tűnik (az is lett), főleg, ha a Blackberry-vel hasonlítom össze. Már van egy éve, hogy két délutánt rááldoztam a rendszergazdai kézikönyvére, egy délutánt a telepítésre és aztán egy hónapig használtuk úgy, hogy rá sem néztem. Ráadásul nem kellett portot nyitni a tűzfalon, csak egy tűzfalszabályra volt szükség, hogy bentről kifelé indulhasson a kommunikáció. Mindenféle trükk nélkül azonnal keresett telefonszámokat az AD-ben, és kérésre fel is hívta azokat, úgyhogy nem azzal foglalkoztam, hogy a Nokia mobilomról áttegyem a névjegyeimet, hanem azzal, hogy az AD fel legyen töltve mobilszámokkal.

Mégis, a Blackberryt utáltam: nem csak azért, mert a készülék rossz PDA volt és még rosszabb telefon, hanem főleg azért, mert úgy éreztem: olyas valamit kellene megvennem, amit már egyszer az Exchange-ben megvettem. A kliens oldal meg mindegy, mert úgy is vagy Blackberry-re vagy Windows Mobile-ra kell átállni. Azon túl pedig nem tetszett, hogy a szolgáltatáshoz készüléket is kell vennem. (Ez azóta már nincs is így.)

Tehát a szép (és némi pénzbe kerülő) megoldás helyett a göröngyös, ám szakmai szépségekkel teli, és nem mellesleg "ingyenes" megoldást választottam. (Igen, és is olyan vadász vagyok…) A főnököm, aki pedig már egy éve i-mate SP3-at használ időről időre megkérdezte: mikor olvashatom itt a leveleimet?

Visszatérve a feladatsorhoz az igazán nagy falat a PKI összevarázslása volt. Nem mintha egy tanusítványkiadót nem lehetne 10 perc alatt feldobni, hanem azért, mert azt szerettem volna, hogy ez a PKI később mindenre jó legyen nekünk. Most csak adjon ki 3-4 tanúsítványt, de később bármihez, ami nem igényel külső CA hitelesítést, használhassuk azt, amit most megalkotok. Ráment a hétvégém, hogy legalább az alapfogalmakon túli alapokat megszerezzem, ehhez a Microsoft Wireless hálózatokhoz kiadott Guide-ját használtam, mert a PKI-t épp abból a szempontból közelíti meg, ahogy az most nekem kellett.

 

Nem írtam róla, csak a tervet emítettem, de miután november 24-én feltelepítettem a majdani Root CA operációs rendszerét, december elsején ugyanezt megtettem a leendő Enterprise Subordinate CA-nak kiszemelt géppel is (előtte meg volt még egy teljes firmware firssítési procerúra). Eután következett a tényleges PKI felhúzása. A Root CA szolgáltatás telepítésének nekifutottam vagy háromszor, mire minden felirat a helyére került. Végül mehetett az Issuing CA, amely már nem lesz Offline és tartományba rakjuk, Enterprise CA stb.  Elkészültem vele, a Root CA tanusítványát beimportáltam a legfelső szintű megbízható tanusítványok listájába, és még a  hitelesítő kiszolgáló tanusítványát is probléma nélkül a helyére tettem. (Az igazsághoz tartozik, hogy a fenti Wireless Guide-hoz tartozik egy Build és egy Operation Guide is, továbbá jónéhány script. Ezeket testre szabtam, hosszabbítva a tanusítványok élettartamát és ritkítva a CLR és delta CLR publikációs intervallumokat is. A scripteket gyakorlatilag bárki lefuttathatja, aki nem tudja elvégezni kézzel a fenti műveleteket.) Meg kellett még oldani az LDAP módszer mellett a webalapú CLR publikációt, szerencsére már mi felügyeljük a www.mal.hu-t, így nem volt nehéz kitenni egy virtuális könyvtárat. Abba viszont beletörött a bicskám, hogy webdav alapon felcsatoljam a mappát, hogy a későbbiekben egyszerű fájlmásolás legyen a CLR publikálás. SSL alapon ez nem is megy egyáltalán, mert a DAV redirector nem támogatja az SSL-t, de nem ment titkosítás nélkül sem, mert bár a felcsatlakozás sikerült, de a tényleges fájlcsere nem. Ezt a szálat majd elvarrom, ha nagyon fáj.

Amin igazán meglepődtem az az volt, hogy a PKI másnap semmilyen formában nem volt hajlandó webtanusítványt kiadni: sem a CA mmc konzoljáról, sem egy request fájlból, sem egy web enrollment weblapról, sem pedig egy IIS szerver automatikus kéréséből. Kicsit megriadtam, hogy most a tanusítványsablonokban is el kell merülnöm, de aztán kiderült, hogy csupán "helyi sajátosság"

okozta a megakadást: a sablonokon csak a erdő gyökértartományának Enterprise Admin, Domain admin, Domain Computer stb. stb. csoportoknak volt joga, az alatta lévő gyermektartomány hasonló csoportjainak nem. (Akkor készítettem azt a képet, ahol a bekötött 2002-es 2003-as tech.net magazinok mellett látható a Windows Server 2003 Resource Kit is) Persze, a Guide csak egyetlen tartománnyal számolt, nem többel. Megadtam hát a megfelelő hozzáférési jogokat a tanusítvány sablonokhoz (elvégeztem előtte a Windows 2003-ra való frissítést is), és lám, mindjárt működött minden. Igaz, addigra vagy már 70 kérelem futott zátonyra, a tartományvezérlők ugyanis rávetették magukat az Issuing CA-ra és kérték a maguk tanusítványát. Hiába na, nem fogadtam meg a Guide azon kérését, hogy a nem használt sablonokat törölje a kiszolgáló listájáról, ezért történt a fenti eset.

Elkészültek tehát a tanusítványok, méghozzá a következők: egy mail.mal.hu nevű, amely majd a tűzfalra került privát kulcsostól. Egy <ExchangeServer> nevű, amely a fürtünk mindkét node-ján el kellett helyezni, hogy a failover ne befolyásolja a titkosított kapcsolatot. (Szalontay Zoli és főleg Fülöp Miki rámszánt néhány percet telefonon és MSN Messengeren, hogy tisztázzuk pontosan mit hova kell tenni, ezúton is köszönöm nekik.)

Következett egy újabb esti munka: az ISA 2000 kiszolgálónkra annak idején nem tettük fel a Feature Pack-et (mivel egyetlen szolgáltatását sem használtuk), ezt most pótolnom kellett. Ez egyúttal egy ISA SP2 újratelepítést is jelentett, továbbá ha már frissítés, akkor megnéztem van-e nem felrakott ISA csomag, hát volt, azt is pótoltam. Ismét következett egy zökkenő: az ISA nem volt hajlandó engedi a frissítések után weblapok böngészését. Rövid technetezés (ilyenkor jól jön a CD alapú változat) és már jött is a megoldás: az utolsó hotfix felrakása után nem lehetséges belülről kifelé netezni úgy, hogy az Integrated mellett a Basic hitelesítés is engedélyezett. Basic kikapcs, Webböngészés visszajött. Most már jöhetett az OWA Wizard.
Jött is, látott is és győzött is, még szerdán elindult a OWA SSL alapokon. Jelentős pillanat a MAL IT életében! Az OMA és az ActiveSync azonban nem ment, teljesen eltérő hibaüzeneteket produkálva. Az Outlook Mobile Access megkapta a tanusítványt, jelezte, hogy a Root CA tanusítványa nincs a Tanusítványtárolóban, és megkérdezte, hogy lépjen-e tovább. Lépjen! De nem tette, hibaüzenettel leállt. Az Activesync ennél szigorúbb volt. A Root CA tanusítványának "megbízhatatlansága" arra késztette, hogy ne is próbálkozzon egyáltán. Nem is próbálkozott. A megoldás a következő napokra maradt.

Folytatom…