The call came on a Monday morning. A team manager wanted to talk about one of his analysts. She had been unable to access Microsoft 365 since the previous Thursday, three full business days. On Friday she had missed a client call because she could not open the file she needed. He was not happy, and he had already decided it was an IT mistake.
I told him I would dig in and come back within two hours. Then I opened the ticket.
The Monday morning call
The ticket had been open since Thursday afternoon. It was in the right queue. It had not been touched. That part was on us, and I was not going to pretend otherwise. A three-day turnaround on an account access issue is too slow, full stop. I noted that before I looked at anything else, because it would need to be said plainly in the conversation ahead, separate from the question of what had actually caused the lockout.
Those are two different things. Why it happened, and why it took three days to fix. Confusing them in the explanation usually makes both look worse.
What the logs actually showed
I pulled her Azure Active Directory account. Her user principal name had changed. sara.omondi@... had become sara.kariuki@.... Her surname had been updated in the HR system. She had recently got married and the HR team had processed the name change, as they should have. The Azure AD Connect sync ran on its regular schedule, a couple of hours after the HR update, and propagated the new UPN into Active Directory and then into Azure AD. All of that was correct.
The problem was one step further down. The Microsoft 365 licensing policy for her role was built on a group membership rule. That rule used a UPN pattern filter as one of its conditions: a string match on the old domain format. When the UPN changed, she no longer matched the filter. The policy engine re-evaluated her license eligibility, found she did not meet the condition, and revoked the license. No warning. No grace period. The license dropped and her access went with it.
The whole chain took roughly four hours from the HR update to the moment her M365 access disappeared.
When every system works and the user is still locked out
I sat with this for a few minutes before calling the manager back, because I wanted to be sure I had it right.
The HR system had done exactly what HR asked it to do. The Azure AD sync had done exactly what it was configured to do. The M365 licensing policy had evaluated the new UPN against its conditions and applied the correct outcome based on those conditions. No system had malfunctioned. No one had pressed the wrong button. There was no bug in the classic sense.
The gap was at the intersection. The HR team processed a name change and did not know that downstream, a license policy used a UPN pattern as part of its evaluation criteria. The IT team had built a license policy using a UPN string filter and had not accounted for what happens when that string changes legitimately. Three systems that each did their job correctly combined to lock someone out of every tool she needed for three days.
That is a different kind of failure from the ones that are easy to assign. It lives in the design, not in the execution.
The conversation I had to have
I called the manager back about ninety minutes after the first call. I had already restored her access, so that part was done. What remained was the explanation.
I started with the ticket turnaround. Three business days on an account access issue was unacceptable, and I said so directly. We had a gap in our triage priority rules: access outages were not automatically flagged as high priority the way hardware failures were. That was mine to fix and I was going to fix it that day. He appreciated having that named first. It changed the tone of the rest of the conversation.
Then I walked through the root cause: the name change, the sync, the license policy condition, and the gap between them. I was careful about one thing here. I did not frame it as "the HR system caused this" or "the HR team did something wrong." Because they did not. They changed a name. What caused the outage was that no one had designed a process for how a name change flows through three systems that were never explicitly connected to each other.
Ownership of resolution does not require ownership of the root cause. Your job is to fix it and prevent recurrence, not to find someone to hand the blame to.
The manager asked a reasonable question: why was the license policy using a UPN string filter in the first place? Honestly, because it was built a few years ago by someone who was solving a different problem, and no one had revisited it since. That is also a real answer, and I gave it to him without dressing it up.
What we changed, and why it holds
Three things changed after this conversation, and they addressed three different layers of the problem.
The first was the license policy itself. I removed the UPN string filter as a licensing condition and replaced it with a proper security group membership check. The group is managed by HR role, not by name pattern. A name change does not affect group membership. That policy now survives name changes, preferred name changes, and any future domain restructuring without anyone needing to do anything.
The second was an alert. Any M365 license drop for a user who was licensed the previous day now fires a notification within four hours. Not an email to a queue: a direct message to the on-call IT contact. The cost of a false positive from a deliberate offboarding is one ignored notification. The cost of another three-day access gap is not worth the trade.
The third was a process addition between HR and IT. Name changes now trigger a brief IT notification before the HR system sync runs: first name change, surname change, preferred name change. IT does a quick license policy check against the new name before the sync propagates. Takes about ten minutes. It is not automated yet, though it could be. For now the manual step is fine because name changes are infrequent and the cost of missing one is high enough to justify the overhead.
The analyst got her access back on Monday afternoon. She was understanding about it, which I was grateful for, and she did not escalate further. The client call she had missed got rescheduled. There was no lasting damage, but there could have been.
The kind of gap that only shows up when someone falls in
What stayed with me about this one was not the technical part. The license policy fix was not complicated once I knew what to change. What stayed with me was the shape of the failure.
Most IT incident investigations end at the proximate cause: the certificate expired, the disk filled up, someone deleted the wrong row. This one did not have a proximate cause in that sense. Nothing expired. Nothing filled up. Nothing was deleted. The gap was in the design: three systems that each behaved correctly had never been explicitly connected in the IT team's mental model of how a name change travels through the environment.
Those gaps are the ones that do not appear in any alert or monitoring dashboard. They only become visible when someone falls in. The way to find them before that happens is to trace the full journey of a lifecycle event, not just the systems involved. Onboarding, offboarding, role change, name change, department move. Each one travels through multiple systems. The question to ask is: at what points along that journey could a downstream system make a decision based on data that is no longer current?
I added name changes to our quarterly access review checklist after this. The review now includes a sample check: take a handful of recent name changes, follow the data through every downstream system, and confirm that the license and access state matches what it should be. It takes about thirty minutes and it has already caught one similar near-miss in the year since.
If you are thinking through identity lifecycle processes in your environment and want to compare notes, reach out here.
Comments