Hello,
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.
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 (https://autologon.microsoftazuread-sso.com ) to the intranet zone.
There are two ways to modify user intranet zone settings:
Enable the policy, and then enter the following values in the dialog box:
Select OK , and then select OK again .
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 .
Turn on the policy setting and then select OK .
Enter the following values in the appropriate fields, and then click OK .
Key path : Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings \ ZoneMap \ Domains \ microsoftazuread-SSO.com \ 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 https://autologon.microsoftazuread-sso.com/ 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).
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 https://autologon.microsoftazuread-sso.com 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.
Thanks
Hi,
I had success by adding the mentioned url by @tjnihal, (https://autologon.microsoftazuread-sso.com/) 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:
#AutoLogon URL to IE11 TRUSTED SITES (VALUE 1 = LOCAL VALUE 2 = TRUSTED SITES
$TestRegistry = Test-Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\autologon.microsoftazuread-sso.com"
if ($TestRegistry -eq $true) {Write-Host '[https://autologon.microsoftazuread-sso.com](https://autologon.microsoftazuread-sso.com/) is in Trusted Sites!' -ForegroundColor Green}
if ($TestRegistry -eq $false) {
Set-Location "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
Set-Location ZoneMap\Domains
New-Item autologon.microsoftazuread-sso.com
Set-Location autologon.microsoftazuread-sso.com
New-ItemProperty . -Name https -Value 2 -Type DWORD
}
Thanks
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!!
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.
Thank
Hello
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.
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.
I have been experiencing this error with Microsoft Teams, and I found that the following steps helped to resolve it:
I hope this helps! others too.
Hi,
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:
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 autologon.microsoftazuread-sso.com 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 autologon.microsoftazuread-sso.com 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!
