Microsoft Teams frequent SSO authentication pop up?


I have an Office 365 Business Premium license. I am using Microsoft Team for a long time.

Suddenly this pop up appearing in my Microsoft Teams by the message it seems it’s a Single Sign-On login for Microsoft Teams.

MicrosoftTeams SSO 999tech

No matter how many times I give the credentials this pop up again appears the next day.

Please, anyone, tell me what needs to be done??


here is the solution for it :

Hi @syed12,

You can gradually implement seamless single sign-on for users by following the instructions below. To get started, add the following Azure AD URL ( ) to the intranet zone.

There are two ways to modify user intranet zone settings:

“Group Policy preference” option

  1. Open Group Policy Management Editor.
  2. Edit Group Policy that applies to some or all users. This example uses the default domain policy.
  3. Go to User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security . Then select the location entry for assigning zones.

  1. Enable the policy, and then enter the following values in the dialog box:

    • Value name : Azure AD URL where Kerberos tickets are forwarded.
    • Value (data): 1 indicates the intranet zone.
      The result will look like this:
      Value name:
      Value (data): 1
  2. Select OK , and then select OK again .

  3. Go to User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone . Then select Allow updates in the status bar using a script .

  4. Turn on the policy setting and then select OK .

“Group Policy preference” option

  1. Open Group Policy Management Editor.
  2. Edit Group Policy that applies to some or all users. This example uses the default domain policy.
  3. Go to User Configuration > Preferences > Windows Settings > Registry > New > registry item.


  1. Enter the following values in the appropriate fields, and then click OK .

    • Key path : Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings \ ZoneMap \ Domains \ \ autologon

    • Value name : https

    • Value type: REG_DWORD

    • Value data: 00000001


Hope the above steps helps


Hi @syed12,

It was confirmed bug by Microsoft, some have confirmed that after adding to the intranet site will solve this issue. Follow the steps mentioned by @tjnihal and let us know if that worked.

Also Microsoft has confirmed some known issues regarding Azure Active Directory (Azure AD) Seamless Single Sign-On (Seamless SSO).

Known issues

  • In a few cases, enabling Seamless SSO can take up to 30 minutes.

  • If you disable and re-enable Seamless SSO on your tenant, users will not get the single sign-on experience till their cached Kerberos tickets, typically valid for 10 hours, have expired.

  • If Seamless SSO succeeds, the user does not have the opportunity to select Keep me signed in . Due to this behavior, SharePoint and OneDrive mapping scenarios don’t work.

  • Office 365 Win32 clients (Outlook, Word, Excel, and others) with versions 16.0.8730.xxxx and above are supported using a non-interactive flow. Other versions are not supported; on those versions, users will enter their usernames, but not passwords, to sign-in. For OneDrive, you will have to activate the OneDrive silent config feature for a silent sign-on experience.

  • Seamless SSO doesn’t work in private browsing mode on Firefox.

  • Seamless SSO doesn’t work in Internet Explorer when Enhanced Protected mode is turned on.

  • Seamless SSO doesn’t work on mobile browsers on iOS and Android.

  • If a user is part of too many groups in Active Directory, the user’s Kerberos ticket will likely be too large to process, and this will cause Seamless SSO to fail. Azure AD HTTPS requests can have headers with a maximum size of 50 KB; Kerberos tickets need to be smaller than that limit to accommodate other Azure AD artifacts (typically, 2 - 5 KB) such as cookies. Our recommendation is to reduce user’s group memberships and try again.

  • If you’re synchronizing 30 or more Active Directory forests, you can’t enable Seamless SSO through Azure AD Connect. As a workaround, you can manually enable the feature on your tenant.

  • Adding the Azure AD service URL to the Trusted sites zone instead of the Local intranet zone blocks users from signing in.

  • Seamless SSO supports the AES256_HMAC_SHA1, AES128_HMAC_SHA1 and RC4_HMAC_MD5 encryption types for Kerberos. It is recommended that the encryption type for the AzureADSSOAcc$ account is set to AES256_HMAC_SHA1, or one of the AES types vs. RC4 for added security. The encryption type is stored on the msDS-SupportedEncryptionTypes attribute of the account in your Active Directory. If the AzureADSSOAcc$ account encryption type is set to RC4_HMAC_MD5, and you want to change it to one of the AES encryption types, please make sure that you first roll over the Kerberos decryption key of the AzureADSSOAcc$ account as explained in the FAQ document under the relevant question, otherwise Seamless SSO will not happen.

Just do a double check it might also help you.




I had success by adding the mentioned url by @tjnihal, ( is to our Trusted sites - seems to fix all our devices so far. If you have a lot of devices to update you should seek Group Policy as mentioned by @tjnihal or the Powershell below would add this for you:

$TestRegistry = Test-Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\"
if ($TestRegistry -eq $true) {Write-Host '[]( is in Trusted Sites!' -ForegroundColor Green}
if ($TestRegistry -eq $false) {
Set-Location "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
Set-Location ZoneMap\Domains
New-ItemProperty . -Name https -Value 2 -Type DWORD


1 Like

I tried to reproduce the same issue with test domain environment. But what I found is, this authentication pop-up only appears at the start of Teams, once we close the pop-up it is not re-appearing and everything is working fine.

This issue sounds like an issue that our users started to report, only it alternates between a modern authentication prompt and the old style one, while the Azure sign in logs alternate between the application “Microsoft Office” and “Microsoft Authentication Broker” (possibly not in that order).

Weird thing is it’s only affecting people working remotely (which makes sense, due to the conditional access policies with location-based exclusions, but makes nailing down the contributing factors more annoying).

We have just finished ruling out two potential causes for our issue with another couple still on the list to work through (all of which are actual issues that need fixing, whether or not they’re causing this - mostly things like outdated AAD Connect versions and fragments of legacy Azure AD computer registrations that pre-date our hybrid joins, etc). I currently have a lot of variables and not much clarity, plus a generally tech-unsavvy userbase in often distant timezones, and underdeveloped support function for troubleshooting and gathering proper data for me to work with, so it’s pretty slow going.

Glad we are not alone here and will be watching his thread closely for updates!!

1 Like

The problem is a bug with the Office 365 Web Apps integration with the Azure Seamless Signon authentication - opening a files from Microsoft Teams or redirecting like a Word/Excel file for editing inside of Teams or opening some Office 365 application can often trigger it.

You can fix it by modifying the Intranet zone setting as suggested above, but this does NOT help users’ personal devices which will have the same problem.

Its easiest to control for domain environment as you can use group policy deployment features but for non-domain PCs you have to manually add the url to your intranet zone using the various options suggested above.




I hope this will help you

Turning off domain federation is pretty straightforward using the Convert-MsolDomainToStandard cmdlet.

Some things to be aware of:

If you are using AADconnect, make sure passwords are syncing so that that when users start logging in through O365 their password still work.
If you are not using AADconnect, the cmdlet about will let you reset your users passwords, you will need to coordinate this.
You can except some service interruption while your domain is being converted, up to 2 hours.

1 Like

I had this problem a few weeks back too, and @Mr.Robot helped me.
This is an old thread now and I assume everyone is working OK.

1 Like

I have been experiencing this error with Microsoft Teams, and I found that the following steps helped to resolve it:

  1. Open the Microsoft Teams app.
  2. Click on your profile picture in the top right corner.
  3. Select “Settings”.
  4. Click on “Accounts”.
  5. Under “Single Sign-On”, click on “Manage”.
  6. Click on “Remove” next to the account that is causing the error.
  7. Re-add the account and sign in.

I hope this helps! others too.


I’ve seen this issue before, and it can be caused by a problem with the Azure Active Directory (Azure AD) Single Sign-On (SSO) cookie.

To troubleshoot this issue, you can try the following:

  • Delete the AzureADSSOAcc account from your computer. Azure AD uses this account to store SSO credentials.
  • Delete the cookie from your browser. Azure AD uses this cookie to keep you signed in.

To delete the AzureADSSOAcc account, open the Computer Management console and expand the Local Users and Groups node. Then, right-click on the Users folder and select Users. Find the AzureADSSOAcc account and delete it.

To delete the cookie, open your browser’s settings and go to the Privacy and Security section. Then, click on the Cookies and other site data button. Find the cookie and delete it.

After you have deleted these items, restart your computer and try signing in to Microsoft Teams again.

If you are still having problems, contact Microsoft support for assistance.

I hope this helps!