Skalp – OWA, OMA, ActiveSync – 2. rész

Amikor újra elkezdtem a munkát, azt gondoltam, hogy gyors sikert érek el. Hamarjában ráakadtam ugyanis arra a tudásbázis cikkre, amely részletesen leírja hogya működik együtt az OWA-OMA-Activesync-Form Based Authentication (FBA) négyes. A cikk lényege, hogy az OMA és az ActiveSync a többiektől eltérően nem működik Basic hitelesítéssel, neki kell az Integrated, ezért vagy frontend-backend architektúrát építünk ki (ami pénzügyileg és pillanatnyilag technikailag is kivitelezhetetlen) vagy ütjük vágjuk az Exchange által használt website-ot, megreszeljük a registry-t nem mellesleg sztoikus nyugalommal lemondunk az FBA-ról, mert az clusteren nem megy. Megtettem amit megkövetelt a cikk, és láss csodát, az OMA fürgén elindult!
Miután körberohangáltam az első jóhírrel, szomorúan kellett tapasztalnom, hogy az Activesync, mivel szigorúan  nem engedélyezi a friss, ropogós Root CA tanusítványomat, továbbra sem működik. Ami ennél még sokkal-sokkal szomorúbb az az, hogy beimportálni sem hagyja a Root CA tanusítványt, mondván, nincs rá jogosultságom! (Akkor mi a fenének ez az import lehetőség?) Újabb telefon Szalontay Zoliéknak, majd némi döbbenet a kapott információktól: A Windows Mobile-ok két törzsbe tartoznak, az egyiket "Pocket PC"-nek a másikat Smartphone-nak hívják. A mobilom ez utóbbi típusú OS-el rendelkezik. A memóriája három részre oszlik, és a lényeg, hogy az olyan szállítók, mint például a T-mobile korlátozhatják az egyes memóriákhoz való hozzáférést, az én esetemben is ez történt. A lehetőségeink:

  1. Igényeljünk egy olyan tanusítványt, amelynek a kiállítója benne van a Windows Mobile Root tanúsítványtárolójában
  2.  Kérjük meg a T-mobile-t, hogy kódolják át a mobilt olyan módon, hogy mi hozzáférhessünk és írhassuk  a tanusítványtárat
  3. Nem támogatott műveletek végrehajtása.🙂

Elkezdtem webezni. Mit, ne mondjak, érdekes találataim voltak. Az első, Jason Langridge naplója (ő Mr. Mobile), annak is egy október 23-i bejegyézése. Eszerint a fenti problémára van megoldás a Windows Mobile 2003 alatt, mert letölthető a DisableCertChk.exe, de ugyanez az eszköz már nem érhető el a Windows Mobile 5 esetén. Ezek szerint a főnökömnek lesz majd pull-jellegű szinkronizációja (push nem, mert DisableCertChk után továbbra is feljön egy figyelmeztetés, legfeljebb tovább lehet lépni), nekem viszont még ilyen sem? Az is kérdés, hogy ez egyáltalán megoldás-e, hiszen egyszerűen kikapcsolom az SSL titkosítás elllenőrzését, bár magát az SSL-t nem.

Az másik is egy webnapló a Windows Mobile Team blogja, november 3-i keltezéssel, ahol rendesen elküldték őket a tanusítványok kezelhetetlensége miatt. Mert az rendben van, hogy egy kívülről elérhető weblaphoz egy "Ámerikáner" cég simán vesz egy Verysign által aláírt tanusítványt, és a probléma már nem is létezik, csakhogy ez i-mate SP5m tud ám Wi-Fi-t is! És melyik az a cég, amelyik a belső Wireless rendszerét úgy oldaná meg, hogy külső tanusítványkiadóval iratná alá a RADIUS szervereinek a tanusítványát? Senki. A válasz? " You’re right, wi-fi is the other major reason to need to add a root cert. We are very very aware of this problem. In the meantime…" Érdemes elolvasni az összes hozzászólást.

Most már nem akartam feladni, és persze hamar jött a megoldás "csak bátor fiúknak". Íme ( forrás alapvetően innen)

  1.  Le kell tölteni a HTC által aláírt regeditSTG.zip fájlt.
  2.  A fájlt át kell másolni a mobilba, majd ki kell csomagolni.
  3.  El kell indítani az exe-t. Ez nem más, mint a neve: egy regedit.
  4.  Módosítani kell az alábbi kulcsokat

 HKLMSecurityPoliciesPolicies0001001 = 1 (RAPI)
 HKLMSecurityPoliciesPolicies0001005 = 40 (Cert)
 HKLMSecurityPoliciesPolicies0001017 = 144

  1. Le kell tölteni egy SDA_ApplicationUnlock.exe nevül alkalmazást
  2. Rá kell kapcsolni a SmartPhone-t a PC-re, majd a PC-ről futtatni a SDA_ApplicationUnlock.exe -t. Kérdez egyet, majd kikapcsolja a tanusítványtároló védelmét.
  3. Smartphone újraindítás
  4. Be kell másolni a megfelelő root tanusítványt a SmartPhone-ba, amelyet DER formátumban, cer kiterjesztéssel korábban ki kell exportálni bárhonnan.
  5.  Kettőt kattintani a cer fájlon. Jön egy figyelmeztetés, hogy "Biztosan importálod?" Yesss.

Nem egyszerű, ugye? És 60-70 vagy netalán többszáz Smartphone esetén? Az i-mate Sp5m-re működik, és egy másik típusnál? És egy következő operációs rendszer verzió esetén? A siker mellett itt azért jócskán maradtak kételyek is.

Ezután már mehetett volna az ActiveSync frissítés, ámde mégsem ment. Az telefonon egy 0x85010014 hibakód jelent meg, míg az Exchange szerver kiszolgálón egy 3005-ös ActiveSync hiba. A képen nagyon fontos, hogy HTTP 400-as a megadott hiba. Megnéztem az Exchange alatti IIS HttpErr logját is, ott meg 500-as Internal Server Errorokat fedeztem el. Ez eléggé vakvágányra vitt, mert nem tudtam, hogy 400-as vagy 500-as hibára keressek. A Google az 500-as hibából hozott ki több találatot, úgyhogy ezen a nyomon indultam el. Találtam egy újabb MS tudásbázis cikket , be is állítottam, habár nem éreztem a magam konfigurációjára nézve relevánsnak. Nem is változott semmi. Aztán rábukkantam egy összefoglaló weblapra, amit megint csak érdemes az első betűtől az utolsóig elolvasni. A mókás részek mellett (ask the sysadmin – I am the sysadmin) rávilágít az ActiveSync egyik leggyakoribb hibájára, azokra az tudásbázis cikkekre, amely lehetséges megoldást adhatnak, és  főleg arra, hogy az eltérő architektúrák, értelemszerűen, eltérő megoldáskeresési módszert igényelhetnek. Ezzel együtt itt sem találtam a megoldást. További böngészés során egy újabb lapon akadt meg a szemem. Itt sincs ugyan semmi kézzelfogható, viszont ezt a mondatot érdekesnek találtam: " initially started getting permission errors, HTTP_400, and HTTP_500, these were fixed by correcting user email addresses, and fixing a firewall configuration allowing port 80 without NAT redirecting the port." A tűzfalon kellene körülnéznem? A HTTP 400 azt jelenti "Bad Request". Mi lehet a tűzfalon, amitől "Bad request" a válasz. Hát például ezen a konfig lapon ott van a "Send the original host header to the publishing server instead of the actual one". bingó! Balklatty, OK. ÉS MŰKÖDIK AZ ACTIVESYNC!!

Egy utolsó szépségtapasz: A fenti host header továbbítást épp ellenkezőleg kéri az OWA, tehát két web publishing rule-t kellett létrehozni, egy host header-est, meg egy anélkülit. Most már tényleg kész.

Skalp az övön. Jöhet a főnököm mobiljának beállítása.

3 Responses to Skalp – OWA, OMA, ActiveSync – 2. rész

  1. Petrenyi Jozsef says:

    Remek cikk. Többször is végig kellett olvasnom, mire megértettem az összes zegzugos utat. Szép, úttörő munka, benne a rendszermérnöki lét összes izgalmával.:)Egy kérdésem lenne: akkor ha jól értem, jelen állapotban Smartphone-ra felejtős a push jellegű szinkronizálás?

  2. Tamas says:

    Ja, egyébként pillanatnyilag az "Always-Up-to-Date" (AUTD) funkció lenne elérhető, csak még nem ellenőriztem, hogy van-e olyan szolgáltatás aktiválva az előfizetésemre, ami azt csinálná, hogy egy adott e-mail-t sms-ben küldene el nekem a készülékre. Ha ez megy, akkor a cím bepötyögése után működni kezd az AUTD.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: