Dynamics CRM 2016 ja Outlook clientin jatkuvat salasanakyselyt

Kuten lukijamme varmasti tietävät, Fenixin tarjoamaan kuuluu oma Dynamics CRM-pilvipalvelumme: SuomiCRM.fi. Kuluvana vuonna olemme toteuttaneet versiopäivityksen 2016:een, uusimpien päivityspakettien kera. Kyseinen versio toi mukanaan monia hienoja toiminnallisuuksia ja käytettävyyttä parantavia ominaisuuksia. Myös rajapinnat kokivat suuren kehitysaskeleen, kun Dynamics CRM Web API julkaistiin virallisesti tuotantokäyttöön. Web API ennen kaikkea helpottaa muiden sovellusten liittämistä CRM:ään käyttökokemuksen rikastamiseksi. Esimerkiksi omaa Oppokonettamme tukeva OppoApp-mobiilisovellus kehitettiin helposti Web API:n avulla.

”Outlook-client kyselee tunnuksia päivittäin”

Versiopäivitystä varten luonnollisesti teimme kaikille asiakkaillemme testiorganisaatiot uuteen ympäristöön kopioimalla tietokannat vanhasta ympäristöstä. Testien varrella saimme asiakkailtamme havainnon, että ”Outlook-client ei tallenna kirjautumistietoja, vaan kyselee tunnuksia päivittäin”. Koska kuitenkin joillain käyttäjillä ongelmaa ei esiintynyt, oli vian pakko olla käyttäjän koneessa, eikä yleisissä palvelinasetuksissa. Ensin tietenkin helpdeskimme tutki erilaisia Outlookiin liittyviä vaihtoehtoja käyttäjän koneen Windowsin Credential storesta Internet Explorerin asetuksiin ja ties mitä, mutta tuloksetta. Ongelmaa selvitettiin myös Microsoftin tuen kanssa, mutta erinäisistä yhteisistä sessioista huolimatta ratkaisua ei löytynyt.

Testikäytössä saimme havaintoja, että ”Outlook-client ei tallenna kirjautumistietoja, vaan kyselee tunnuksia päivittäin”. Koska ongelmaa ei esiintynyt kaikilla käyttäjillä, vian oli oltava jossain muualla kuin yleisissä palvelinasetuksissa.

OAuth ja Outlook-clientin salasanakyselyt

Eräässä sisäisessä palaverissamme nousi kuitenkin esille tuore tapaus, jossa yksi asiantuntijoistamme oli tehnyt vastaavan versiopäivityksen erään asiakkaamme On-Premise -ympäristössä aiemmin tänä vuonna. Kuluneella viikolla hän oli muita kehitystarpeita varten kytkenyt OAuthin päälle, jonka jälkeen oli noussut esille aiemmin kuvattu ongelma Outlook-clientin kanssa. Tämä uusi teoria OAuthin vaikuttamisesta salasanojen kyselyyn piti tietenkin vahvistaa testaamalla, ja kyllähän se totta oli.

Web API vaatii On-Premise IFD-ympäristöissä OAuth-autentikoinnin, ja muutenkin OAuth kirjautumistapana mahdollistaa monta uutta lisäarvoa tuovaa liitännäistä. Näin ollen OAuthia ei haluttu jättää pois päältä vain siksi, että jotkut käyttäjät (eivät todellakaan kaikki käytä Outlook-clientia) joutuisivat muutoin syöttämään salasanansa päivittäin. Asiaa piti tutkia lisää (armotonta googlettamista uusilla hakusanoilla ja oljenkorsiin tarttumista) ja pian teimmekin muutaman hyvin mielenkiintoisen havainnon:

1. Jos CRM-palvelimella on OAuth kytkettynä käyttöön ENNEN kuin Outlook-clientilla yhdistää organisaatioon ensimmäisen kerran, niin siinä tapauksessa client käyttää oletuksena autentikointitapana OAuthia. Tätä ei pysty mitenkään muuttamaan clientin käyttöliittymän kautta.
a. Jos vastaavassa tilanteessa OAuth ei ole päällä, niin silloin client käyttää Windowsin Credential storea ja siten muistaa autentikoinnin.
2. Jos AD-palvelimella käytössä olevan Relying Party Trustin “TokenLifeTime” on asetettu yhtä suureksi tai suuremmaksi kuin ADFS:n SSOTokenLifeTime, niin OAuthin Refresh tokenia ei muodosteta, sillä se vanhenisi samalla (tai ennen) kuin itse sessio joka haluttaisiin uusia.
3. Outlook-client tallentaa Windowsin rekisteriin tiedot kustakin käyttämästään organisaatiosta. Näiden organisaatiokohtaisten tietojen joukossa on myös avain ”AuthenticationProvider”, jossa on numeraalisesti asetettu käytettävä autentikointitapa.
a. Oleellisia arvoja ovat 2 (Credential store) ja 5 (Oauth).

Miten saada autentikointi taas toimimaan?

nämä ovat pitkälti sisäisiä dokumentoimattomia asetuksia. Kyseistä rekisteriarvoa saa kuitenkin muuttaa sallitusti (ks. https://technet.microsoft.com/fi-fi/library/hh699760.aspx)

Havaintojen perusteella muodostettu ratkaisu koostuu siis seuraavista vaiheista (jos Outlook-client on jo päivitetty, kohdat 1-2 voi ohittaa):

1. Vanhan Outlook-clientin asennuksen poistaminen
2. Clientin uuden version asentaminen
3. Uudella versiolla CRM-organisaatioon yhdistäminen (tässä vaiheessa kirjautuu OAuthilla)
4. Outlookin sulkeminen
5. Rekisterimuutos:

a. HKEY_CURRENT_USER\Software\Microsoft\MSCRMClient\{organizationid}
b. Muuta AuthenticationProvider -avaimen arvo 5 -> 2

Näiden vaiheiden jälkeen Outlook-client käyttää taas Windows Credential storea autentikointiin. Pidemmälläkin aikavälillä voimme todeta, että tämä on ollut hyvä ja toimiva ratkaisu.

Toisena vaihtoehtona olisi AD-palvelimella Tokenien voimassaolojen muuttaminen, mutta se puolestaan tuo omat tietoturvariskinsä. Huomionarvoista on myös, että se olisi tosiaan palvelinkohtainen asetus, jolloin vaikutus koskisi kaikkia saman pilvipalvelun käyttäjiä, joilla on mikä tahansa OAuthia hyödyntävä liitännäinen käytössään. Rekisterimuutos on käyttäjäkohtainen, jolloin riskitkin ovat paljon pienemmät. Toisaalta voidaan myös todeta, että yleisellä tasolla salasanojen tallettaminen koneen muistiin on jo itsessään oma tietoturvariskinsä, mutta se keskustelu kuuluu johonkin toiseen blogikirjoitukseen.

Tämä teksti kertoo yhden tapauksen Fenixin koodipajan arjesta. Koodipajan pitää aina silloin tällöin tukeutua vähän erikoisempiin ratkaisuihin virallisten teiden johtaessa umpikujaan.

Kirjoittaja työskentelee Systems Specialist -tehtävissä Fenixin Turun toimistolla ja on Microsoft Certified Solution Expert (MCSE).