About Microsoft 365 Service Sessions

This article explains sessions when logging in to Microsoft 365 services
via TrustLogin.

Note: The content of this page assumes that
 SAML integration has already been configured between TrustLogin and Microsoft 365.

Session After Logging In to Microsoft 365 Services

Session Duration

When you log in to a Microsoft 365 service via TrustLogin,
the session duration on the destination service depends on that service's own specifications.
Therefore, TrustLogin cannot control it.

Note: Session duration depends on the specifications of each service, not just Microsoft 365.

For details on session duration for Microsoft 365 services, please refer to
the following Microsoft documentation.

Reference: Microsoft 365 session timeouts

When Re-authentication Occurs

When the session (token) held on the Microsoft 365 side expires, re-authentication becomes necessary.

However, if your TrustLogin session is still active at that time, re-authentication is not required.

Microsoft 365 Session TrustLogin Session Re-authentication
No Yes Not required
No Required

When Frequently Prompted to Sign In to Microsoft 365 (Office 365)

We have confirmed cases in which users provisioned through TrustLogin's Microsoft 365 (Office 365) integration
are frequently prompted to sign in.

■Cause

When an Azure AD user is provisioned, the "LastPasswordChangeTimestamp" attribute
cannot be synchronized from TrustLogin (the external identity provider),
which causes the refresh token required to maintain the session to expire after a maximum of 12 hours.

Reference (Microsoft documentation):
Federated users are frequently required to sign in to Azure AD

■Affected Azure AD Users

Users provisioned in Microsoft 365 (Office 365) via TrustLogin

■Solution

This can be resolved by using PowerShell commands to set
the "LastPasswordChangeTimestamp" and "StsRefreshTokensValidFrom" attributes for the Azure AD user.

Note: The MSOnline PowerShell module was deprecated on March 30, 2024. For information about the new commands, please see this article.

  1. Run the following commands to import MSOnline and sign in with your Azure AD administrator account.
    Import-Module MSOnline
    Connect-MsolService

  2. Extract the accounts whose LastPasswordChangeTimestamp attribute is blank.
     Note: The text shown in red is an example — please replace it to match your own environment.
     Note: In this example, accounts containing "@example.com" are the search target.
    Get-MsolUser -All | where {($_.UserPrincipalName -like "*@example.com")-And ($_.LastPasswordChangeTimestamp -like "")} | select displayName,UserPrincipalName,LastPasswordChangeTimestamp,StsRefreshTokensValidFrom


  3. Set the attributes on the accounts extracted in step 2.
    $date = Get-Date
    set-msoluser -UserPrincipalName UPN of user -LastPasswordChangeTimestamp $date -StsRefreshTokensValidFrom $date

■Additional Notes 
Note: The text shown in red is an example — please replace it to match your own environment.

  • Checking the values set for the two attributes

    Get-msoluser -UserPrincipalName UPN of user | select-object UserPrincipalName,LastPasswordChangeTimestamp,StsRefreshTokensValidFrom
     If no value is set: The result is returned blank.
     If a value is set : The token's last update date/time is displayed.

  • Checking the two attributes in the Azure AD admin center

    Open the Users > [target user] > Properties screen.
     "Last password change date/time" corresponds to the LastPasswordChangeTimestamp attribute.
     "Sign-in session validity start date/time" corresponds to the StsRefreshTokensValidFrom attribute.
    tempsnip.png

About Microsoft 365 Service Sessions

This article explains sessions when logging in to Microsoft 365 services
via TrustLogin.

Note: The content of this page assumes that
 SAML integration has already been configured between TrustLogin and Microsoft 365.

Session After Logging In to Microsoft 365 Services

Session Duration

When you log in to a Microsoft 365 service via TrustLogin,
the session duration on the destination service depends on that service's own specifications.
Therefore, TrustLogin cannot control it.

Note: Session duration depends on the specifications of each service, not just Microsoft 365.

For details on session duration for Microsoft 365 services, please refer to
the following Microsoft documentation.

Reference: Microsoft 365 session timeouts

When Re-authentication Occurs

When the session (token) held on the Microsoft 365 side expires, re-authentication becomes necessary.

However, if your TrustLogin session is still active at that time, re-authentication is not required.

Microsoft 365 Session TrustLogin Session Re-authentication
No Yes Not required
No Required

When Frequently Prompted to Sign In to Microsoft 365 (Office 365)

We have confirmed cases in which users provisioned through TrustLogin's Microsoft 365 (Office 365) integration
are frequently prompted to sign in.

■Cause

When an Azure AD user is provisioned, the "LastPasswordChangeTimestamp" attribute
cannot be synchronized from TrustLogin (the external identity provider),
which causes the refresh token required to maintain the session to expire after a maximum of 12 hours.

Reference (Microsoft documentation):
Federated users are frequently required to sign in to Azure AD

■Affected Azure AD Users

Users provisioned in Microsoft 365 (Office 365) via TrustLogin

■Solution

This can be resolved by using PowerShell commands to set
the "LastPasswordChangeTimestamp" and "StsRefreshTokensValidFrom" attributes for the Azure AD user.

Note: The MSOnline PowerShell module was deprecated on March 30, 2024. For information about the new commands, please see this article.

  1. Run the following commands to import MSOnline and sign in with your Azure AD administrator account.
    Import-Module MSOnline
    Connect-MsolService

  2. Extract the accounts whose LastPasswordChangeTimestamp attribute is blank.
     Note: The text shown in red is an example — please replace it to match your own environment.
     Note: In this example, accounts containing "@example.com" are the search target.
    Get-MsolUser -All | where {($_.UserPrincipalName -like "*@example.com")-And ($_.LastPasswordChangeTimestamp -like "")} | select displayName,UserPrincipalName,LastPasswordChangeTimestamp,StsRefreshTokensValidFrom


  3. Set the attributes on the accounts extracted in step 2.
    $date = Get-Date
    set-msoluser -UserPrincipalName UPN of user -LastPasswordChangeTimestamp $date -StsRefreshTokensValidFrom $date

■Additional Notes 
Note: The text shown in red is an example — please replace it to match your own environment.

  • Checking the values set for the two attributes

    Get-msoluser -UserPrincipalName UPN of user | select-object UserPrincipalName,LastPasswordChangeTimestamp,StsRefreshTokensValidFrom
     If no value is set: The result is returned blank.
     If a value is set : The token's last update date/time is displayed.

  • Checking the two attributes in the Azure AD admin center

    Open the Users > [target user] > Properties screen.
     "Last password change date/time" corresponds to the LastPasswordChangeTimestamp attribute.
     "Sign-in session validity start date/time" corresponds to the StsRefreshTokensValidFrom attribute.
    tempsnip.png