Outlook / Teams – TPM-turvapiiri vikatilassa
Outlook tai Microsoft Teams antaa ohjelman käynnistyksen yhteydessä TPM-turvapiiriin viittavaan virheilmoituksen. Kuitenkin Windowsin TPM -turvapiirin hallinta (tpm.msc) osoittaa TPM-piirin olevan kunnossa.
Virheilmoitus sisältää yleensä virhekoodin C0090016 tai 80090016 ja saattaa antaa esimerkiksi seuraavat tiedot:
tai:
Olen törmännyt myös kolmanteen virhekoodiin, josta minulla ei ole esittää tarkempia yksityiskohtia. Jos tarkastellaan virheilmoitusten osoittamaa Microsoftin dokumentaatiosivua https://www.microsoft.com/wamerrors, tunnistetaan sieltä ainakin toinen noista virhekoodeista “80090016“. Dokumentaatiossa sanotaan seuraavasti:
Mitä tuolla siis tarkoitetaan? Microsoft esittää, että vika voisi olla seurausta huonosta sysprep-näköistiedostosta. Sysprep on Microsoftin työkalu, jota käytetään käyttöjärjestelmän näköistiedostojen luomiseen, jotta niitä voidaan levittää verkon laitteille asennusta varten. Se poistaa käyttöjärjestelmästä sellaisia yksilöllisiä tietoja, joita ei haluta kloonattavan kohdelaitteille. Tästä syystä Microsoft pyytää varmistamaan, ettei näköistiedostoa otettu Sysprepillä Azure AD -rekisteröidystä tai -liitetystä laitteesta. Liitoksen yksilöllisiä tietoja ei kuitenkaan haluta muille laitteille, joille tullaan tekemään omat liitoksensa eri tunnuksin.
Entä, jos kyseessä on laite, jonka käyttöjärjestelmään ei ole koskettu, eikä sitä ole provisioitu mukautetusta näköistiedostosta?
Taustatietoa vian ymmärtämiseksi
Tätä voi esiintyä kaikilla Windows 10 -laitteilla, jotka ovat joko Azure AD-rekisteröityjä (työ- tai koulutili lisätty Windowsiin), Azure AD -liitettyjä tai Hybrid-Azure AD -liitettyjä. Vika ei tyypillisesti viittaa mihinkään fyysiseen ongelmaan TPM-turvapiirissä tai sen firmwareen, vaan pikemminkin ongelmaan Azure AD:n todennuksen kanssa. TPM-turvapiirin firmware-päivitys voi kuitenkin auttaa ennaltaehkäisemään ongelmaa, jos vika on toistuvaa.
Laitteiden rekisteröinti tai liittäminen Azure AD:seen mahdollistaa Seamless Sign-on (SSO) -tunnistautumisen pilviresursseihin. Tämä tarkoittaa sitä, ettei käyttäjien tarvitse syöttää tunnuksiaan jatkuvasti eri palveluihin, vaan kirjautuminen tapahtuu automaattisesti Azure AD -liitetyllä tai -rekisteröidyllä laitteella. Todennuksessa käytetään Primary Refresh Tokenia (PRT), joka on päätekijä SSO:n mahdollistamisessa.
Modernia tunnistautumista käyttävät Office-sovellukset todentavat oletuksena Active Directory Authentication Librarylla (ADAL). 16.0.7967 tai uudempaa versiota oleva Office käyttää Web Account Manageria (WAM) sisäänkirjautumiseen kaikilla Windows 10 -laitteilla, jotka ovat vähintään käyttöjärjestelmäversiossa 15063.138. WAM tai pikemminkin sen Azure AD WAM -lisäosa on Office-ohjelmien osalta se komponentti, joka käsittelee Primary Refresh Tokenia todennusta varten (ns. default token broker) ja mahdollistaa SSO-kirjautumisen. PRT:tä käytetään muiden access ja refresh tokeneiden pyytämiseksi ja päivittämiseksi. Tätä tapahtuu taustalla jatkuvasti.
PRT myönnetään Windows 10:n laitteelle Azure AD -rekisteröinnin tai -liitoksen yhteydessä. Rekisteröinnin yhteydessä generoituu kaksi salausavainparia, joiden yksityiset avaimet ovat sidottuja laitteen TPM-turvapiiriin. Julkiset avaimet taas tallentuvat Azure AD:seen, joka määrittää Windows 10:n laitteelle myös salatun istuntoavaimen PRT:n myöntämisen yhteydessä. Istuntoavaimen salaus voidaan purkaa vain toisella niistä TPM-piiriin tallentuneiden avainparien yksityisellä avaimella.
Kaikki token requestit Azure AD:seen allekirjoitetaan aina istuntoavaimella TPM-turvapiirin kautta. Jos token requestin allekirjoittaminen tai istuntoavaimen salauksen purkaminen epäonnistuu jostain syystä, saattavat Office-ohjelmat esittää viankuvauksen mukaisia virheilmoituksia.
Näistä syistä TPM-piiri on oleellinen myös Office-ohjelmien todennuksen osalta.
Korjaus
Tällaisia tapauksia on tullut vastaan useita ja virhekoodit voivat vaihdella. Pelkkä tietokoneen uudelleenkäynnistys on harvoin korjannut ongelmaa yhtä muistamaani tapausta lukuun ottamatta. Jos vika on toistuvaa, kattavin korjaus lienee TPM-turvapiirin firmwaren päivittäminen ja Azure AD:n uudelleenliitos. Azure AD:n audit- ja kirjautumislokeista voi myös yrittää etsiä virheilmoituksen antamaa korrelaatio-tunnusta. Lisäksi kannattaa tarkistaa Windowsin Tapahtumienvalvonnasta: Sovellus- ja palvelulokit > Microsoft > Windows > AAD > Operational lisätietoja varten.
Omien havaintojeni perusteella vika on kuitenkin hyvin nopeasti korjattavissa pysyvästi seuraavin toimin ainakin 80% tapauksista, eikä se edellytä Azure AD -uudelleenliitosta tai työtilin -lisäystä.
Tyypillisesti riittää, että uudelleennimetään Resurssienhallinnassa kansio:
C:\Users\%username%\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
.old -päätteiseksi:
C:\Users\%username%\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy.old
Tuo kansio liittyy sen Azure AD WAM -lisäosan toimintaan, joka hallinnoi token requesteja ja käsittelee PRT:tä. Uudelleennimeäminen ei kuitenkaan onnistu suoraan, sillä kansio on svchost.exe -prosessin käytössä. Prosessia ei kannata tappaa Tehtävienhallinnasta, sillä se vastaa useista muista tärkeistä taustapalveluista. Tappaminen johtaisi myös todennäköisesti mahdollisen etätukiohjelman yhteyden kaatumiseen.
Paras tapa on mennä Resurssienvalvontaan ja navigoida Suoritin-välilehdelle. Sieltä voi tarkastella suorittimen prosesseihin liittyviä kahvoja. Kirjoitetaan hakuun kansion sijainti, mutta huomioidaan, ettei ympäristömuuttujat toimi haussa, eli korvataan %username% -muuttuja komentokehotteen whoami -komennon tuloksella:
C:\Users\<whoami-komennon tulos>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
Resurssienvalvonta listaa suoraan kaikki kansiota käyttävät prosessit, jolloin saadaan tarkka prosessi-ID (PID), joka voidaan tappaa. Klikataan hiiren oikealla painikkeella löytynyttä prosessia “svchost.exe (NetworkService -p)” ja valitaan “Lopeta prosessi“.
Kun prosessi on lopetettu, kansion uudelleennimeämisen pitäisi onnistua. Uudelleennimetään kansio yllä mainittujen ohjeiden mukaisesti .old -päätteiseksi. Käynnistetään lopulta tietokone uudelleen.
Kirjaudutaan normaalisti takaisin tietokoneelle ja avataan se Office-sovellus, jossa ongelma tuli alun perin vastaan. Noin 30% tapauksista virheilmoitusta ei tule enää uudelleen näkyviin, ja lopuissa virheilmoitus tulee vielä kerran. Tässä voi vaikuttaa se, onko käyttäjä kirjautunut koneelle pilvitoimialueen tunnuksellaan, vai Windows Hello for Businessillä, mutta en ole pystynyt todentamaan asiaa varmuudella.
Tällöin painetaan kuitenkin virheilmoituksessa “Jatka“, minkä jälkeen ohjelma todentaa normaalisti, yhdistää palveluun ja korjaa työtilin ongelmat. Joskus käyttäjä saattaa saada ilmoituksen työtilin ongelmista välittömästi työpöydälle kirjautuessaan, jolloin Windows 10:n ehdottaa suoraan tilin korjaamista kirjautumalla sisään uudelleen. Kirjaudutaan kaikkiin Windowsin ja Office-ohjelmien tunnistetietokyselyihin, joissa Microsoft 365 -tunnuksia pyydetään.
Virheilmoitusta ei pitäisi enää noiden toimenpiteiden jälkeen tulla takaisin. Suosittelen tutustumaan seuraaviin Microsoftin dokumentaatioihin, jos aihe kiinnostaa:
- Troubleshooting hybrid Azure Active Directory joined devices.
URL: https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-hybrid-join-windows-current - What is device identity?
URL: https://docs.microsoft.com/en-us/azure/active-directory/devices/overview - Connection issues in sign-in after update to Office 2016 build 16.0.7967 on Windows 10.
URL: https://docs.microsoft.com/en-us/office365/troubleshoot/authentication/connection-issue-when-sign-in-office-2016 - What is a Primary Refresh Token?
URL: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token
Artikkelin on kirjoittanut Vetonaulan IT-asiantuntija Markus Pyhäranta.
