Probleem
Bij het in gebruik nemen van een nieuwe laptop liep de aanmelding vast: Office activeerde niet correct en het account gaf een aanmeldfout bij het inloggen op de bedrijfsomgeving. Kort daarna, na het inschakelen van meervoudige authenticatie (MFA), viel ook de koppeling uit tussen de Microsoft 365-omgeving en een extern platform waarmee klantmail werd verstuurd — binnenkomende mail bleef gewoon werken. Dit gebeurde drie dagen voor een belangrijke vakbeurs. De softwareleverancier van dat platform had het probleem zelf al onderzocht en concludeerde dat het aan het IMAP-protocol lag ("SMTP werkt wel, IMAP niet") — een diagnose die het onderliggende probleem niet raakte.
Aanpak
In plaats van die diagnose over te nemen, is onderzoek gedaan aan de bron: de aanmeldings- en beveiligingslogboeken van de identiteitsomgeving (Microsoft Entra ID). Voor het laptopprobleem bracht dat een dieperliggende oorzaak aan het licht: het apparaat was nooit correct geregistreerd, en een eerste hersteltraject liep vast op een configuratieconflict tussen twee beheerlagen (mobiel apparaatbeheer en gegevensbescherming) die niet gelijktijdig op dezelfde gebruikers toegepast mochten worden.
Voor het mailprobleem is niet meegegaan in het IMAP/SMTP-spoor van de leverancier, maar zijn de aanmeldpogingen van de koppeling zelf op foutcode-niveau geanalyseerd. Toen bleek dat de leverancier voor herstel toegang tot een bedrijfspostvak nodig had, is bewust geen wachtwoord gedeeld met die externe partij — ook niet toen de accounteigenaar daar zelf mee instemde: een tijdelijk wachtwoord zou exact hetzelfde risico in stand houden. In plaats daarvan is gekozen voor een werkwijze waarbij de eigen organisatie zelf inlogt, terwijl de leverancier de technische stap aan zijn kant uitvoert. De oplossing is vastgelegd in een herbruikbaar diagnosedocument, zodat een vergelijkbare storing bij een volgend incident sneller te herleiden is.
Resultaat
Beide problemen zijn tot de daadwerkelijke oorzaak herleid in plaats van symptomatisch verholpen: de aanmeldfout bleek een combinatie van ontbrekende apparaatregistratie en een beheerconflict, en het mailprobleem bleek een verlopen autorisatietoken op de koppeling tussen het platform en de mailomgeving — niet het protocolprobleem dat de leverancier had gerapporteerd. Beide zijn hersteld vóór de vakbeurs waarvoor een werkende mailomgeving nodig was. Als bijvangst kwam tijdens het onderzoek ook een configuratiefout bij de leverancier zelf aan het licht — contactgegevens werden naar het verkeerde account gesynchroniseerd — die zonder deze analyse vermoedelijk onopgemerkt was gebleven.
Technologie
Microsoft 365 en Microsoft Entra ID (aanmeldings- en beveiligingslogboeken, Conditional Access, apparaatregistratie), Microsoft Intune (mobiel apparaatbeheer), en OAuth 2.0-koppelingen via de Microsoft Graph API tussen Microsoft 365 en het externe platform — genoemd omdat de diagnosemethode er rechtstreeks op steunde, niet als losse opsomming van vaardigheden.
Wat ik geleerd heb
Een leveranciersdiagnose is een hypothese, geen vaststaand feit. Pas na eigen logboekanalyse bleek de werkelijke oorzaak heel ergens anders te liggen dan waar de leverancier op had gewezen — en kwam er zelfs een fout bij de leverancier zelf boven water die anders onopgemerkt was gebleven.