Users are getting a "change your password" notification that won't go away

Brass Contributor

Several users have reported that Office 365 (specifically, SharePoint, but the Office 365 portal shows it too) keeps showing them a notification that says "your password will expire in X days" with a link to change it.password-expiry-sp-not.png

 

In two recent cases, the users' passwords were indeed about to expire, but after the users changed their passwords, logged off, logged back on, etc., the notifications are still showing up for them, days later. Dismissing the notification doesn't help; it comes back after a little bit.

 

The affected users are all federated. We are using ADFS 2012 R2 and Azure AD Connect. We have not enabled password hash sync, nor have we enabled password writeback. Our password policy in Office 365 is set to never expire. (Since these users are federated, I don't think that should matter.)

 

I'm not sure what else to try. Has anyone else seen this issue?

4 Replies

Your AD FS is most likely configured to send the "password expiration" claim to Office 365, which in turn uses it to surface this notification when needed. The expiry relates to the on-premises password. Not sure why it keeps showing for some users though, I'd suggest changing the corresponding attributes and capture the full list of claims being sent.

@Vasil Michev, thanks for your reply.

 

I came across that in my searching as well, but when I looked at our claims rules, it appears we already have those claims being sent. Here's the rule we have:

c1:[Type == "http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime"]
=> issue(store = "_PasswordExpiryStore", types = ("http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime", "http://schemas.microsoft.com/ws/2012/01/passwordexpirationdays", "http://schemas.microsoft.com/ws/2012/01/passwordchangeurl"), query = "{0};", param = c1.Value);

 

I'd suggest changing the corresponding attributes and capture the full list of claims being sent.

I'm not sure which attributes you're referring to.

Well yes, because you are sending the claim you get the notification in O365. However, if the claim is set in error, this can explain the behavior you are observing. So my point was to check the actual claim being sent for one of those users, which you can do by using the event logs or via tools such as Claims X-Ray: https://adfshelp.microsoft.com/ClaimsXray/TokenRequest

@Vasil Michev Thanks for that. I just did some testing with the Claims X-Ray tool, adding in the claim rule I mentioned before.

 

I tested with one of the original users facing this issue. She has recently changed her password. On "Forms" authentication, she only has the "passwordexpirationtime" claim. On WIA, no password expiration claims are sent.

 

I tested with another user, whose password will expire in a few days. On "Forms" authentication, she is receiving the "passwordexpirationtime", "passwordexpirationdays", and "passwordchangeurl" claims. On WIA method, again, no password expiration claims are sent.

 

Doing a little more testing, here's what seems to be happening:

 

Using the "Windows Integrated Authentication" method, no password expiration claims are sent at all. (This is our users' default method because we have our ADFS server address in the Local Intranet zone so users aren't required to enter their password in browsers on their workstations.)

 

Using the "Forms" authentication method, the following claims are being sent:

  • passwordexpirationtime* – sent to all users (twice, if their password will soon expire)
  • passwordexpirationdays – only being sent to users whose passwords will soon expire
  • passwordchangeurl – again, this is only being sent for users with passwords soon to expire