Android Teams login fails during ADFS federation with SSL error
Hello Android mobile users cannot sign in to Microsoft Teams The login fails during the ADFS federation step due to an SSL error Environment Android OS versions 10 to 14 Microsoft Teams mobile app Entra ID federated with on premises ADFS ADFS service URL is masked Public certificate issued by Sectigo Issue description After entering the account in Teams the sign in process redirects to ADFS The page does not load correctly and shows infinite loading or a blank screen The same account works normally on PC browser PC Teams and Outlook Web The issue occurs only on Android mobile apps that use WebView Android log summary OAuth2 WebView client received SSL error Primary error SSL untrusted Wildcard certificate for masked domain Certificate issued by Sectigo Public Server Authentication CA Troubleshooting performed Device date and time verified Teams app cache cleared and app reinstalled Issue reproduced on multiple Android versions and devices PC authentication works with the same certificate Questions Can Android WebView or Microsoft mobile authentication fail with SSL untrusted when the ADFS server does not provide a complete certificate chain Is full chain certificate configuration required on ADFS IIS for mobile authentication Can SSL inspection or proxy interception cause this issue only on Android apps while PC browsers work normally Are there official Microsoft recommendations for certificate configuration when using ADFS federation with Android mobile apps Additional information The same behavior occurs in other Microsoft mobile apps The suspected causes are incomplete certificate chain or network SSL inspection Thank you
Google Federation with Entra ID - doesn't support MultipleAuthN SAML claim
Entra ID has a new Microsoft-managed conditional access policy that will be enabled from October 2024. However, Google doesn't support the MultipleAuthN claim that ADFS (and other IdPs) do. Is there a work-around for this, or we just need to ensure that the new Microsoft-managed conditional access policy is disabled for all users? Otherwise, we somehow need to enable double MFA (MFA at both Google and Microsoft). I imagine this might be an issue for any other federated IdPs that don't support this specific SAML claim. There is a new alternative to the `SupportsMFA` setting in the `Set-MsolDomainFederationSettings` powershell command, but it doesn't allow you to 'always assume MFA is utilised in the federation' - https://learn.microsoft.com/en-us/graph/api/internaldomainfederation-update?view=graph-rest-1.0&tabs=http#federatedidpmfabehavior-values Thanks in advance, NigelO365 Email Migration to Another Tenant while Deferring Migration of Sharepoint files
Hi, This is the context: ChildCompany has O365 and it has an Azure AD in hybrid mode synchronizing to a on-prem AD server. They have an internal domain ChildCompany.com, and an external domain ChildCompany.com where they also receive and send email using O365. ParentCompany is going absorb the ChildCompany some time in next year, and I was asked about the integration options. According to this https://download.microsoft.com/download/b/a/1/ba19dfe7-96e2-4983-8783-4dcff9cebe7b/microsoft-365-tenant-to-tenant-migration.pdf I could do a phased migration, where the end state is that they decomm their onprem AD and that they only use our ParentCompany systems. The business requirement is to start their integration with Email, and then in later phases do the Sharepoint integration as that requires way more analysis on their data sources, as they also have wikis and many other on prem legacy stuff. They are less than 50 users, so I can use Quest migration tools for the email part, but I wonder what needs to happen in what order. This is what I have in mind: Migrate their current O365 into our ParentCompany Office 365 subscription, so that they can continue logging in into their domain joined windows machines using childCompany.co, so they start using ParentCompany.com email addresses, but the problem then is how can they continue using their sharepoint and onedrive resources associated with the Azure and local domain at ChildCompany.com? This is more or less what I have in mind, for the intermediate step, the cutover: Child Company ParentCompany --------------------- ---------------- On-Prem | MS Cloud: | MS Cloud: ---------------|----------------------|-------------- Local AD (ADFS)| Azure Subscription | Azure Sub | Azure AD | Azure AD |--------------------- |--------------------- | O365 Sub -> | O365 Sub | Exchange mailboxes-> | Exchange mailboxes | Sharepoint? -> | ??? | -------------------- |--------------------- I wonder how could it be possible to defer the sharepoint and onedrive migration, so that the child company users can still work on their sharepoint files using their normal auth methods, while disabling childcompany.com as MX so they start using ParentCompany.com mailboxes.Is that even possible? Would make more sense to try to migrate everything at once? That is way more work, but I'm weighting my options.
Authentication request goes in infinite loop
We have several users in our org have been experiencing authentication issues, as specially on their iOS and Android device, when they enroll a new device or setup Outlook, Teams or any other MS apps on their mobile devices and try to authenticate to setup an account, they all get below error. MSIS7042: The same client browser session has made '{0}' requests in the last '{1}' seconds. Contact your administrator for details. We checked the ADFS and everything appears to be fine that end and ADFS successfully issues token to the request. it seems like MS identity platform or relaying party application is misbehaving and is not successfully consuming the token issued by AD FS, and the application is sending the passive client back to AD FS, repeatedly, for a new token. AD FS will issue the passive client a new token each time, as long as they do not exceed 5 requests within 20 seconds. We also opened up a case with Microsoft but so far, no updates and as usual they have no clue. Any help resolving this issue will be greatly appreciated.
Self Service Password Reset for trusted domain
Hi, I manage a self-contained Forest/Domain in Geo1 which has a two way AD trust with our parent company in Geo2. The Geo1 domain sits in the Geo2 owned and maintained Azure/M365 tenant. SSPR is selectively enabled in Azure by way of Domain Local AD group into which all required AD groups from other business units within the organisation are nested and this works fine for users in Geo1 (all users in Geo1 are in domains which are in the same AD forest as the parent organisation). A Domain Global AD group from Geo2 has also been nested in Geo1's Domain Local Group so, in theory, SSPR should be available to Geo2 users but it isn't working (we see a message on the SSPR page stating that SSPR 'isn't available for this user'). The Geo2 forest syncs to the Geo1 managed Azure AD via AAD connectors located in Geo1's data centres. I can see our users in the Azure Portal and have access to all permitted M365 apps such as Exchange Online, SharePoint et al. All users are have either E3 or E5 licenses. Can anyone suggest a reason why SSPR isn't working for the Geo1 users or maybe point me to any documentation which might deal with this particular scenario? Regards Paul
Microsoft Authenticator Still Prompts Users for MFA after Switching to new MFA option on IPhones
Good Morning All, Our company recently made the change from Microsoft Authenticator to utilizing Duo through ADFS for our 365 MFA solution. The deployment was a success but we have noticed an issue involving all of our users who have iPhones and issues they run into when trying to sign into any of their Office 365 apps on their phone. Any user who goes to sign in on their iPhone is being prompted for MFA by the Microsoft Authenticator despite the Authenticator being disabled as an option in our tenant. This seems to be the case on brand new phones as well if both the authenticator and another 365 product are installed on the phone. The login is usually successful and the Microsoft Authenticator is seemingly doing nothing but just prompting the user to approve the login but it has caused some issues for certain users by giving them failed logins. We've found that removing the Authenticator app fixes this but that's not always a solution as some users have more than one account linked to the Microsoft Authenticator. Has anybody else run into this issue before and have you found any solutions to stop the Microsoft Authenticator from prompting users after switching to another MFA solution?AD Connect and ADFS
Hi, are there any known risk involved connecting ADFS to Office 365 while migration of users are in the process? Migration of users to Office 365 via AD Sync/AD Connect are in the works and we want to implement blocking access to Office 365 outside the corporate network using ADFS. Any ideas? Thanks.ADFS - Service Unavaible over WAP
Hi, We have a simple ADFS enviroment with a WAP in a DMZ and an internal ADFS server. Problem is that we are not able to access the Test-Signon-Page (https://fqdn.domain.com/adfs/ls/IdpInitiatedSignon.aspx) or published OWA over the WAP. Internally everything is working fine and also from the WAP I can access the internel ADFS Server with the Test-Signon-Page and OWA with ADFS without problems. But from the internet over the WAP we are always getting: Through WAP we are also publishing Exchange Activesync which is working without problems. I dont see any events in the eventlog, also with tracelogs. I don't see anything interesting in Fiddler on the client. Do you have any ideas? Kind regards PatrickADFS Device Registration cross forest
Hi all, is it possible to do device registration (and claims) across a forest trust? it looks to me like it isnt possible due to the limitation of the Enable-AdfsDeviceRegistration -DeviceLocation command being "a domain within the same forest" is there any other way to make this work cross forest? or is this a scenario for additional ADFS farms or moving to Azure AD registration and authentication? (tagged ADFS 2016, its actually 2012 R2) Thanks Pete
