Shibboleth IdP + O365 Modern Authentication client issue

[Tim Murphy]

Hi all

Just following up on this issue to let you know how we solved this issue (note that this issue is not specifically with Shibboleth IdP, but with many third-party IdPs which are used in a Azure AD federated domain and therefore may help others in the future here as many Educational orgs use Shibboleth + O365). Our on-prem directory is not a traditional Active Directory domain (we use OpenLDAP) and so we chose not to use Azure AD Connect.

I discovered that this is a known issue for federated users. The solution (among others!) was well burried in Microsoft's documentation<https://support.microsoft.com/en-us/help/4025960/federated-users-in-azure-ad-are-forced-to-sign-in-frequently>. Our setup means that we provisioned the users manually using Powershell, and as such we did not use Azure AD Connect and did not sync any LastPasswordChangeTimestamp field as no password is set for federated users in Azure AD.


The solution is to sync the LastPasswordChangeTimestamp attribute using Azure AD Connect or set it in Powershell as follows

    $RefreshTokensValidFrom = Get-Date

    Set-MsolUser -UserPrincipalName john at contoso.com -StsRefreshTokensValid>From $RefreshTokensValidFrom

https://support.microsoft.com/en-us/help/4025960/federated-users-in-azure-ad-are-forced-to-sign-in-frequently


Cause
Federated users who do not have the LastPasswordChangeTimestamp attribute synced are issued session cookies and refresh tokens that have a Max Age value of 12 hours. This means that the program can silently retrieve new tokens to keep the user’s session alive only up to 12 hours. After that time, the users are returned to the original IdP to re-authenticate.

This occurs because Azure AD cannot determine when to revoke tokens that are related to an old credential (such as a password that has been changed). Therefore, Azure AD must check more frequently to make sure that the user and associated tokens are still in good standing.

For more information about token lifetimes and how they are managed, see the following Microsoft Azure article:
Configurable token lifetimes in Azure Active Directory (Public Preview)<https://docs.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes>"


Hopefully this might help someone else in the future. Again I know this is not specifically a Shibboleth issue but thought it might help someone, someday.


Regards,
Tim.
________________________________
From: users <users-bounces at shibboleth.net> on behalf of Joseph Fischetti <Joseph.Fischetti at marist.edu>
Sent: Monday 9 March 2020 5:52 PM
To: users at shibboleth.net <users at shibboleth.net>
Subject: RE: Shibboleth IdP + O365 Modern Authentication client issue


We’re having the same behavior, for a subset of our users.



Outlook will display a “Needs Password” notification in the bottom and won’t receive any new emails.  Users will click that notification and after being prompted to log in (to the shib login page), it’ll fail to get them on.  Checking the shibboleth logs shows a valid/successful login at the time of the outlook failure (read:  It’s not a shibboleth problem).



In every case that I’ve seen: When it happens, if the user reboots their machine instead of entering their password, outlook reconnects without a prompt (like it should).  In addition, in every case that I’ve seen, when the user is being asked for their password, the status of their refresh token in Azure is still valid.



It’s not every user (and there’s nothing we can do from a office365 point of view). It’s not even like we can figure out what version of the client is experiencing the problem.  I’ve seen it with multiple builds of Office 2019 (and I have no recorded instances of a user with 2016 having the issue… though that’s not to say it doesn’t exist).



Joe





From: users <users-bounces at shibboleth.net> On Behalf Of Tim Murphy
Sent: Monday, March 9, 2020 12:57 PM
To: users at shibboleth.net
Subject: Shibboleth IdP + O365 Modern Authentication client issue



[EXTERNAL EMAIL]

Hi all



Just wondering if anyone has seen this before. We have set our Office 365 domain to federated mode and configured it to use our Shibboleth as the Identity Provider. All works so far and users have configured their clients with our IdP.



However we are noticing about every 24 hours that users are being signed out of the mobile/desktop clients, and being asked to login again. Has anyone seen this behaviour when using Shibboleth IdP and Office 365? Normally mobile/desktop clients should be persistent and shouldn't force a user out, but asking here just in case.



We have set our Azure AD Org policy, conditional access policy etc all to extended sessions on mobile apps, tried disabling MFA etc but to no avail. It should be noted that our IdP stores sessions for a max of 24 hours or if you change IP.





Regards,

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200423/2a08de3b/attachment.html>