Australialainen RADIUS- ja suomalainen Internet-insinööriosaaminen yhteen

Tamperelainen Internet-ratkaisutoimittaja Arch Red Oy laajentaa toimintaansa ostamalla australialaisen ohjelmistoyrityksen Open System Consultants Pty Ltd:n (OSC). OSC:n päätuote Radiator RADIUS on markkinoiden monipuolisin Radius-palvelinohjelmisto, johon perustuu laaja portfolio langattomia verkkoja (WLAN, 3G, 4G) yhdistäviä käyttäjätunnistusratkaisuja. Arch Red on tuottanut näitä ratkaisuja operaattori- ja yritysasiakkailleen yhteistyössä OSC:n kanssa jo useiden vuosien ajan.

Yrityskaupan myötä Arch Redille avautuu OSC:n kymmenien aktiivisten jälleenmyyjien verkosto lähes 50 maahan sekä suorat asiakaskontaktit kymmeniin operaattoreihin ja vielä useampiin suuryrityksiin, yliopistoihin ja organisaatioihin ympäri maailman.

"Yhdistämällä Arch Redin ja OSC:n pystymme tarjoamaan yhteisille asiakkaillemme ratkaisuja Internet- ja käyttäjäntunnistus- ja hallintapalveluiden toteuttamiseen entistä paremmin ja monipuolisemmin", kertoo Arch Red Oy:n toimitusjohtaja, Karri Huhtanen ja jatkaa:

"Emme tule pelkästään jatkamaan Radiatorin kehitystä vaan haemme nopeasti merkittävää lisäkasvua tarjoamalla myös valmiita käyttäjäntunnistusratkaisuja Internetin yli muun muassa tilauspohjaisina pilvipalveluina."

Lisätietoja:

Karri Huhtanen

toimitusjohtaja, Arch Red Oy

+358 44 087 6546

www.archred.fi

Taustaa yrityksistä

Arch Red on Internet-asiantuntijayritys, joka tarjoaa sekä tuotteita että palveluita palveluntarjoajille langattomien verkkojen (WLAN, 3G, 4G) käyttäjäntunnistukseen, -hallintaan ja näiden väliseen verkkovierailuun. Arch Red tarjoaa myös ratkaisuja ja palveluita white-label WLAN- ja yhteisöverkkojen käyttäjien ja vieraiden tunnistukseen.

Open System Consultants on australialainen yritys, jonka päätuotteena on Radiator RADIUS-palvelinohjelmisto, jolla on asiakkaita 180 eri maassa ja jälleenmyyjiä yli 46 maassa maailman ympäri. Radiator RADIUS-palvelinohjelmistoa käytetään operaattori- ja palveluntarjoajaverkoissa käyttäjäntunnistuksen, provisioinnin ja konfiguraationhallintaan. Radius-palvelin on keskeinen komponentti, kun toteutettaan esimerkiksi WLAN-verkkojen käyttäjäntunnistusratkaisuja tai kun niitä yhdistetään 3G/4G-verkkojen käyttäjätunnistukseen.

eduroamin vianselvitys, osa 2: Yleisimmät syyt autentikaatiovirheisiin

eduroamin vianselvitys, osa 2: Yleisimmät syyt autentikaatiovirheisiin

Taustaa

Seuraava lista pohjautuu meidän (Arch Red) kokemuksillemme sekä eduroam Suomeen että Langattomaan Tampereeseen kuuluvien organisaatioiden ongelmien ratkaisussa koottuihin kokemuksiin. Jos listasta tuntuu puuttuvan syitä tai jotkin kaipaavat lisäkommentteja niin blogiartikkelin kommentteihin voi lisätä kysymyksiä tai omia näkemyksiään aiheista. Esitellyt ongelmat eivät ole missään erityisessä yleisyys- tai muussa järjestyksessä vaan niitä on kerätty sitä mukaa kun niitä on tullut mieleen. Alunperin nämä tuli kerättyä sähköpostiin, josta parhaita paloja on jo käsitelty MobileFunet-työryhmässä.

Päätelaitteiden konfigurointivirheet

Yleisellä tasolla päätelaitteiden konfigurointivirheet on ongelma numero 1. Virheet harvemmin johtuvat RADIUS-palvelinten väärinkonfiguroinnista. Juuripalvelinten tilastoinnissa epäonnistuneita autentikaatioita voi näkyä organisaatioiden osalta suurissakin määrissä, mutta niitä tulee jokatapauksessa koska yksikin virheellisesti konfiguroitu client pommittaa kyllä onnistuneesti organisaation kotipalvelinta kasvattaen virheiden tai epäonnistuneiden tunnistautumisten määrää tilastoissa.

Vanhemmat päätelaitteet ja tunnistamismenetelmäoletukset

Tälläisistä parhaana esimerkkinä toimivat Nokian vanhat puhelimet ja niissä 802.1X:n konfiguroinnin vaikeus. Symbian oletuksena tarjosi WPA/WPA2-autentikoiduille verkoille EAP-SIM/EAP-AKA -tunnistamista oletuksena. Tämä jouduttiin aktiivisesti kääntämään pois päältä sekä syöttämään sekä ulkoinen (eli vaikka anon@tut.fi) että sisäinen (karri@tut.fi) username erikseen sekä valikoimaan PEAP/EAP-TTLS asetuksista päälle. Tämä ongelma ei ole enää niin olennainen iOS-, Android- ja Windows Phone -laitteiden yleistyessä ja Symbianin vähitellen hävitessä. Myös kannettavien käyttöjärjestelmissä tämän konfigurointi on muuttunut helpommaksi, joskaan ei välttämättä turvallisemmaksi. Tämä virhe näkyy tyypillisesti 3gpp-realmien yrittämisenä organisaation proxyävällä RADIUS-palvelimena tai viimeistään juurella, jonne nuo realmit maadoitetaan.

Varmenteiden tarkistusongelmat

Kaikki WPA-asiakasohjelmat (WPA supplicant) eivät toimi samalla tavalla. Jotkut WPA-supplicantit on konfiguroitu toisia tiukemmaksi RADIUS-palvelimen varmenteen tarkastuksessa. Jos varmenteen tarkastus ei onnistu (tai tarkemmin jää kesken), eivät useimmat supplicantit luovuta vaan yrittävät aina vain uudelleen. Jotkut supplicantit eivät mahdollista varmenteen tarkistusta (ja joudutaan luottamaan MSCHAPV2 haaste-vasteeseen). Jotkut tarjoavat vain SSH:n tyyliin fingerprintin ja ilmoittavat uudelleen, jos varmenne on muuttunut (tämä ei ole varsinaisesti huono tapa). Jotkut taas vaativat, että supplicantille on määritelty palvelimen varmentavan CA:n varmenneketju, ja että RADIUS-palvelin palauttaa sen varmenteiden yhteydessä. Virheet RADIUS-palvelimen konfiguroinnissa tai käyttäjän tekemässä supplicantin konfiguroinnissa sitten aiheuttavat jälleen kerran epäonnistuneita autentikointiyrityksiä ja yleensä paljon ja nopeallakin vauhdilla.

Salasanan vaihtovaatimukset organisaatioissa

Tietyn kuukausimäärän sisään vaihtuvan salasanan käytäntö aiheuttaa sen, että käyttäjien päätelaitteisiin jää vanhoja salasanoja, jotka eivät kelpaa, mutta joita päätelaite sitten yrittää uudelleen ja uudelleen.

Kirjoitusvirheet konfiguraatiossa

Kirjoitusvirheet konfiguraatiossa esim. tuon aiemmin mainitun  ulomman kuoren ja sisemmän kuoren tunnusten määrittelyssä aiheuttavat päätelaitteita, jotka jatkuvasti yrittävät hakata päätään organisaation tunnistuspalvelimelle tai verkkovierailupalvelun seinään.

Organisaatioiden virheelliset konfiguraatio-ohjeet: Ei realmia ohjeistuksessa

Tätä Suomessa on käsittääkseni vähemmän tavattu, mutta kaikki ne organisaatiot, jotka hyväksyvät organisaationsa sisällä tunnistautumiset, joissa ei konfiguroida realmia sekä ulko- että sisä-EAP:piin, saisivat muuttaa ohjeistustaan ja konfiguraatiotaan niin, että ilman tuota realmia, autentikaatio ei onnistu organisaation sisälläkään. Tämän perustelu on se, että käyttäjä pystyy tekemään organisaation sisällä näennäisesti toimivan, mutta roamauskelvottoman konfiguraation, joka ei sitten tietenkään toimi vierailtaessa jossain muualla.

Organisaatioiden virheelliset konfiguraatio-ohjeet: RADIUS-palvelimen varmenteen tarkistuksesta lintsaaminen

Tätä harrastetaan jonkin verran Suomessakin, sillä vastaan on tullut useampiakin ammattikorkeakoulujen ja yliopistojen ohjeita, joissa ohjeistetaan kääntämään esim. Windowsissa RADIUS-palvelimen varmenteen tai nimen tarkistus pois päältä. Kun RADIUS-palvelimen varmenteen tarkistuksen ohjeistamisesta on tällä tavoin lintsattu, aiheutetaan ongelmia niille käyttäjille, joiden supplicant vaatii sitä, että se konfiguroidaan tarkemmin tuon palvelinvarmenteen varmentamista varten. Tyypillinen tälläiseen johtava virhe konfiguraatio-ohjeissa on se, että ohjeistetaan, että RADIUS-palvelinvarmenteen varmentaminen pitää kytkeä pois päältä. Tälläinen lintsaaminen olisi syytä kitkeä pois ja ohjeistaa sekä CA-varmenteiden asennus, että tuo fingerprintin tarkistus, joka esim. Mac OS X:ssä ja Windows 8:ssa on käytössä.

Päätelaitteiden bugit käyttöliittymässä ja varmenteiden hallinnassa

Mm. Nokian N900- ja Nokian N9- sekä joillain Android-laitteilla, laitteistovalmistaja on tehnyt itse supplicantin hallinnan, siihen varmenteiden konfiguroinnin ja yleisen käyttöjärjestelmän varmenteiden hallinnan. Mainituilla Nokian laitteilla mm. eräs ongelma oli, että RADIUS-palvelimeen varmenteen varmistusta varten ei pystynyt käyttöliittymästä konfiguroimaan olemassa olevia juurivarmenteita kelvolliseksi varmentamaan RADIUS-palvelimen varmennetta. Ongelmaa pystyi jossain määrin kiertämään asentamalla päävarmentajan varmenteen uudelleen tai käyttämällä privaattipäävarmentajaa.

Androidissa puolestaan jotkut laitteistovalmistajat eivät tarjoa mahdollisuutta ollenkaan varmistaa RADIUS-palvelimen varmennetta. Jos varmenteen tarkistus on mahdollista, päävarmentajan varmenteet on asennettava erikseen ja mitä vanhempi Android-versio, sen hankalampi käyttäjälle. Tilanne on hieman parantanut Android 4.0+:ssa, mutta turvallisen konfiguraation tekeminen sielläkin vaatii hyvää ohjeistusta tai automatisointia. Kuten muissakin tilanteissa, virheet näissäkin sitten kostautuvat lisääntyneinä virhemäärinä tilastoissa.

Puolinaisen konfiguraation teko päätelaitteisiin

Tämä ongelma perustuu tilanteeseen, jossa käyttäjä aloittaa konfiguraation teon, mutta tekee konfiguroidessa jonkun virheen ja viallinen/puolitoimiva konfiguraatio jää mobiililaitteeseen. Käyttäjän tietämättä mobiililaite kuitenkin yrittää tuolla viallisella konfiguraatiolla verkkoon aiheuttaen kuormaa ja virheitä tilastoihin. Esim. vaikka tilanne, että ulkoinen realm on kunnossa, mutta sisäinen käyttäjätunnus, salasana tai niihin liittyvät asetukset on pielessä. Jälleen saadaan virheitä tilastoihin ilman, että käyttäjä edes huomaa laitteensa yrittävän hakata itseään sisälle eduroam-verkkoon.

Vaihtelevat eduroam-verkon konfiguraatiot

Tämä tarkoittaa organisaatioissa olevia erilaisia eduroam-verkon konfiguraatioita ja niitä aiheutuvia ongelmia. Esimerkiksi se, että eduroam-verkko tarjoaa sekä WPA2 että WPA1 -kykyisen tunnistaumisen, voi aiheuttaa sen, että osa päätelaitteista konfiguroituukin käyttämään ja olettamaan, että eduroam tarjoaa aina molemmat autentikaatiotavat tai vähintään WPA1:n. Erityisesti Windows voi kunnostautua siinä, että sille ei kelpaa saman nimisestä verkosta sekä WPA- että WPA2-profiilit, vaan käyttäjän on valittava joko tai. Olisikin yleisen toiminnallisuuden kannalta suotavaa, että eduroam lukittaisiin jo WPA2 only -profiiliin kaikkialla Suomessa ja WPA1 sekä siihen liittyvät kryptot poistettaisiin konfiguraatioprofiileista kaikkialla.

Loppukommentit

Ehdottomasti suurin osa eduroamin ongelmista liittyy nykyään siihen, miten organisaatioiden pitäisi ohjeistaa ja hoitaa käyttäjien päätelaitteiden konfigurointi tai sen oikeellisuus. Terena Mobility -työryhmässä tätä on pyritty ratkomaan ja siellä on kokeiltu apuohjelmia mobiilipuhelimiin (tämä voi mielestäni auttaa) sekä erillisiä supplicanteja kannettaviin (tämä taas on mielestäni huonompi idea). Konfiguraatiota avustava ohjelma/webbipalvelu on mielestäni hyvä idea siksi, että sillä tavalla voidaan puskea varmemmin toimiva konfiguraatio päätelaitteisiin. Oma supplicant on puolestaan huono idea sen takia, että erilaisia laitteita on paljon ja tuollaisen asentaminen voi sotkea niiden toimintaa muuten. Omaa supplicantia parempi lähestyminen on, että pysytään niistä standardi WPA2-autentikointitavoissa, joita päätelaitteiden käyttöjärjestelmien omat supplicantit tukevat natiivisti ja keskitytään niiden konfiguraation ohjeistamiseen ja automatisointiin.

eduroamin vianselvitys, osa 1: Juuripalvelun rooli

eduroamin vianselvitys, osa 1: Juuripalvelun rooli

Idea näihin blogipostauksiin lähti CSC:n meiltä tekemästä kyselystä siitä, että olisiko meillä (Arch Redillä) Suomen eduroamin juuripalvelun ylläpitäjinä tietoja siitä, mitkä ovat 10 yleisintä autentikaatiovirhettä eduroam-verkoissa. Tälläisiä virheitä tulikin sitten mietittyä, mutta niitä analysoidessa kävi selväksi se, että mitkään niistä eivät varsinaisesti liittyneet tai olleet selvitettävissä tai ratkaistavissa juuripalvelun kautta. Päinvastoin suurin osa niistä oli selvitettävissä ainoastaan organisaatioiden omien tunnistuspalveluiden ja käytäntöjen kautta.

Ymmärtääkseen kuitenkin kokonaiskuvan on tärkeä hahmottaa ensin se, mikä on juuripalvelun rooli ja kyvyt eduroam-verkkovierailussa. Yksi eduroamin parhaista ominaisuuksista nimittäin on myös sen heikkous ajatellen yleistä vianselvitystä. Eduroamin autentikaatioliikennettä ei nimittäin pystytä välityspisteissä purkamaan vaan autentikointi tehdään salatun putken suojassa käyttäjät kotiorganisaatioon. Näin ollen myös lähes kaikki ongelmiin ja epäonnistumisiin liittyvä tieto on kerättävissä pelkästään organisaatioiden (IdP) RADIUS-palvelimen lokeista ja tiedoista.

Juuripalvelimelta ei siis pystytä selvittämään sitä, miksi joku autentikointi epäonnistuu ellei sitä pystytä päättelemään ulomman kuoren reititysongelmaksi (väärä realm) tai organisaation RADIUS-palvelimen vastaamattomuudeksi. Sisällä liikkuvaan tietoon ei välityspisteissä päästä käsiksi. Edes kaikki epäonnistumisetkaan eivät juuripalvelussa näy vaan jos esim. varmenneongelman takia TLS-tunnelin muodostus keskeytyy, tätä ei nähdä epäonnistuneena tai onnistuneena autentikaationa juuripalvelimella ollenkaan. Vain selvät IdP:n päätökseen johtaneet verkkovierailut näkyvät lokeissa onnistuneina tai epäonnistuneina autentikaatiopyyntöinä, eikä näistä useinkaan nähdä varsinaista syytä onnistumiseen tai epäonnistumiseen vaan nämä tiedot on organisaation tarkistettava omilta autentikaatiopalvelimiensa lokeista.

Tästä syystä tunnistamisongelmien syyt sekä niihin liittyvä vianselvitys tai yleisempien vikojen tilastointi pitää tehdä organisaatioiden RADIUS-palvelimilta. Juuripalvelimilta tuota tietoa ei pystytä keräämään.

Arch Redissä me olemme kuitenkin avustaneet monia yliopistoja liittymään eduroamiin. Joillekin olemme toimittaneet avaimet käteen integrointeja ja auttaneet tukisopimusten puitteissa selvittämään RADIUS-palvelimeen liittyviä autentikaatiovirheitä. Tälläiset autentikaatiovirheet ovat olleet juuri niitä, joita juuripalvelusta ei pääse näkemään vaan jotka kokemuksen kautta tulevat vastaan useimmin organisaatioiden omissa verkoissa. Seuraavassa osassa käydäänkin läpi yleisimmät eduroam-organisaatioissa autentikaatiovirheitä aiheuttavat tekijät.