How to troubleshoot KMSI (Stay signed in) not appearing for a user?

Copper Contributor



We have contractors authenticate against our Azure AD tenant. We want the contractor to authenticate once, select Yes to the "Stay signed in?" prompt, and move along happily.  However, sometimes the "Stay signed in?" prompt doesn't appear.  How do we troubleshoot this?  Is there an Azure AD log we can look in or a log on the client laptop?


Background - it may be worth noting that often times we have to use the AzureAD PowerShell module cmdlet Revoke-AzureADSignedInUserAllRefreshToken.  This is because most companies appear to use Azure AD.  So contractors have laptops issued from their company.  When the contractor goes to authenticate against Azure AD, the laptop assumes it should provide the standard corporate credentials used to login to the laptop.  However, this fails because in this case as we expect an identity from our Azure AD tenant, not the contractor's tenant.  After we have the contractor flush his corporate refresh tokens, he can then authenticate against our tenant.  If he gets the "Stay signed in?" prompt and clicks yes - then for future authentications, he is prompted to choose to use either the account we gave him or his corporate account.  However, if the contractor doesn't get the "Stay signed in?" prompt, then every time he wants to use one of our services/apps, he has to go through this painful process to revoke his corporate refresh tokens in order to login to our tenant.  It's worth noting that when the contractor purges his refresh tokens he must re-authenticate for Office365, Teams, and any other web app/app using Azure AD.  Most companies use MFA/2FA making this especially painful.


Any suggestions appreciated,


1 Reply





To ensure that the KMSI prompt is shown only when it can benefit the user, the KMSI prompt is intentionally not shown in the following scenarios:

  • User is signed in via seamless SSO and Integrated Windows Authentication (IWA)
  • User is signed in via Active Directory Federation Services and IWA
  • User is a guest in the tenant
  • User's risk score is high
  • Sign-in occurs during user or admin consent flow
  • Persistent browser session control is configured in a conditional access policy

So did you verify  all of those scenarios . I would suggest also to clean the browser cache.