Source
r/msp•
Poopmin

Scratching my head at an office 365 authentication issue...

Just when you think you know everything, something throws you for a loop. Hoping someone might have run into this before. Client environment is as follows:

  • On-prem AD
  • Azure AD connect w/password hash sync
  • Okta

Client had a password leak and we forced an AD password change for all users, with 'must change password on next login enabled'. They have a number of remote users who are not on domain-bound machines. The users were given instructions to log into Okta; Okta is able to perceive the 'must change' status on the user and force them to change the password. That would update AD, and AD would update 365. Easy.

Our expectation was that when we changed the password and the hash sync occurred, within an hour their Office 365 tokens would expire, and they would stop sending/receiving mail, and they'd have to play ball. From my testing, when 'must change password' is selected, you CANNOT sign into office 365, it treats you as if your password is wrong.

However, 48 hours later, I'm seeing a user who I know has NOT reset his password (it's what we set it to initially, plus the 'must change' box is still checked) still sending out mail; his 365 token has not expired. I know for a fact password hash sync is working, as I ran the diagnostics that confirmed it was working, I'm seeing 'recent sync' on the portal, plus test accounts are working when we change their password.

​

The only compelling explanation I could guess at is that even though his password has changed, since the box is checked, 365 did not sync over the new password, and for some reason, it's choosing to refresh the token as his password is not 'wrong' (since it doesn't know his new one). But to me, it's crazy that the OWA would recognize that he's not allowed to log in, but a separate outlook or activesync token would be refreshed, you'd think it'd use the same logic... I know they're separate systems, but still... one would expect.

I did not initiate a signout for the users on o365, that would've been a good move as well, I could do that for testing purposes. I would assume since the token was revoked, he wouldn't be able to get a 'new' one. He's basically getting grandfathered in with refreshes.

Thanks!

Posted May 20, 2020, 11:20 PM UTC

84
[deleted]•

The refresh tokens that mail clients use can be valid for up to 90 days unless the user gets signed out or changes their password. See https://docs.microsoft.com/en-us/office365/enterprise/session-timeouts

Usually when I change an authentication setting I run this command to revoke existing refresh tokens and force re-authentication:

Get-User -ResultSize Unlimited | foreach {Set-User -Identity $_ -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)}

11
PoopminOP•

That's the thing, though - the user's password was reset by us. That should invalidate the refresh token... But my hypothesis is that o365 doesn't 'know' the password has changed because the 'must change password' box is checked. It just feels flawed.

I hear you on the token revoke, it's what we'll end up doing, but I'm concerned because in this situation, it doesn't seem like it should be necessary. Thanks for weighing in.

2
[deleted]•

Correct, syncing the password when that box is checked is a feature you have to enable

2
benburhans•

Not an authentication issue. Hash sync from on-prem does not invalidate (many? most? all?) session tokens. Now that more people are working from home, I've seen users whose passwords have changed go weeks without noticing because their O365 stuff continues to function; they only notice when they hit the ever-decreasing on-prem AD or LDAP resources. Anyone with MFA may notice sooner because some expiration times differ for MFA, though.

Using the cloud protection app, Azure AD portal, or Powershell, you can force new sign-ins which revokes active tokens for most services.

1
FromMyFingers•

Your explanation is correct. When that box is checked, it doesn't translate to the cloud properly. We ran into the same problem. I don't believe we ever found any documentation for it, but we did open ticket with Microsoft and that was the explanation they gave us.

1