When using proxy on localhost teams fails to establish TCP connection for login
This is a strange problem, and it took us quite a while to get to the bottom of it. We tested on Windows 10 and Windows 11 with the latest Teams app. What is the problem? We are working on a solution the monitors network traffic for a safe school environment. As part of that we install a local proxy on Windows devices. The proxy is configured as manual proxy in the proxy settings. When requesting to sign into Teams, Teams establishes a connection to `login.microsoftonline.com`. Without the proxy that works without problems. Teams establishes a TCP connection, sends a CONNECT, TLS handshake and then encrypted data. When activating the local proxy any connection is fine (e.g. `teams.events.data.microsoft.com`, `nav.smartscreen.microsoft.com` are established just fine), but the one to `login.microsoftonline.com` is not established. In Teams this results in an error page that the login page can't be reached (it reports a 404, but it's not a 404). We ensured that nothing was blocked and there are no lower level connection errors, then we dug deeper with Wireshark. Once accessing the login page (which would trigger connection making for `login.microsoftonline.com`) we see a `SYN` being sent to establish the TCP connection, but there is never a `SYN/ACK`. The local proxy never receives this `SYN` (no connection is ever established), somehow it never reaches the destination but is "dropped". We can see that Teams tries to re-transmit the SYN, but it never arrives at the destination. A tcp `SYN` not reaching it's destination points to it being blocked somewhere, so we: - Turned the firewall off (anything that can be turned off is turned off) - Added specific allow rules for any other device control that could block. This did not help, the problem keeps persisting. (Note: We were able to reproduce this problem with a different proxy solution as well. Once we configure the proxy on localhost we run into this issue.) We also tried: - Configure the local proxy with the IP address of the machine within the local network (i.e. 10.12.128.2) instead of `127.0.0.1`: Leads to the same problem. - Run the local proxy on another Windows machine, turn off firewall and connect to the proxy on the other machine: No problems with this solution, the connection is established fine. We then tried to configure the proxy via PAC file (without a DIRECT fallback), which result in different weird behavior. In the browser the behavior is as expected - pages that are blocked by the proxy report a connection failure, pages that are allowed can be accessed. For Teams login we don't run into problems with the PAC file based settings, but Teams does not route the connection to `login.microsoftonline.com` through the proxy! The connection to `login.microsoftline.com` somehow implicitly bypasses the system wide proxy settings when using a PAC file (i.e. I see the connection in Wireshark, but it's directly established, not going through the proxy even though it is configured via PAC file). Other connections related to Teams are established through the proxy as expected. I don't think this is expected behavior. I have Wireshark traces that show all the different behaviors. If needed I'm happy to add them to this ticket. It would be great to get help with a better understanding what could be the problem. What could cause this behavior (in Teams / in Windows)? With a better understanding of the behavior we could work on overcoming this problem.
Adding Custom Header to Microsoft Teams Login Requests Using mitmproxy Causes HTTP 404 Error
Hi Team, We are using mitmproxy to add a custom header to all requests during the login process in the Microsoft Teams Windows application. The purpose of adding this custom header is to verify that the request is coming from a specific device by checking this header on our sso server. Unfortunately, we are unable to bypass the login URLs. Adding the custom header is a crucial part of our verification process. However, we are encountering the following issue: When using mitmproxy to modify requests, the Microsoft Teams app fails to connect and shows the error: "We can't connect you. HTTP 404 login.microsoftonline.com" Is there a way to add a custom header to requests from the Teams app without breaking the connection to the Microsoft login endpoint? We appreciate any guidance on how to resolve this issue or insights into how Teams validates its login requests to avoid potential interference. Looking forward to your reply. Thanks
Block Teams web client whilst allowing Teams desktop client - using proxy
[UPDATE 29/09] We have identified that the Teams desktop client puts a Teams entry in the user-agent string and use a specific Chrome version that is different to the Chrome the users have so we are using this to block traffic to teams.microsoft.com and seems to working so far. Not all traffic has the user-agent though i.e. video. Initially we blocked teams.microsoft.com except user-agent Teams* but this blocked video. Does anyone have detail on Teams video traffic so we can investigate further options? ------------------------------------------------------------------------------------------------- Is there a way to identify traffic from Teams web client, distinct from Teams desktop client so we can use proxy config to block Teams web client whilst allowing Teams desktop client? The reasons for this specific ask and consideration of other options are below: we are deploying Microsoft 365 in an environment for which a new tenant (tenant A) has been set up. The environment has on-prem Win 10 devices managed via SCCM and the devices currently don't have Teams or Outlook desktop clients installed. The environment is locked down with access to teams.microsoft.com currently blocked using proxy config to prevent users getting to Teams via the browser (and users don't even have the desktop client, which this would also block). Users currently have access to email on the parent company's tenant (tenant B), using their separate parent company creds signing into outlook for the web in the browser. This is the extent of their use of M365 cloud services - Outlook on the Web to parent company tenant. As part of rolling out Teams, the Teams client is being deployed and the proxy block of teams.microsoft.com is being removed. RestrictTeamsSignInToAccountsFromTenantList registry setting is implemented so users can only sign-in to tenant A from Teams desktop client. sign-in to tenant B Teams or indeed any tenant is possible via the web client however and there is a requirement to block this so the users can't use the Teams web client. We can't use tenant restrictions i.e. Restrict-Access-To-Tenants header in proxy to tenant A (https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/tenant-restrictions) as the users need to be able to get to parent company tenant B for email We can't configure tenant B e.g. Conditional access to block Teams for a group as the global team who manage tenant B don't engage for these type of point solutions - to keep their tenant maintainable. Due to the above constraints we think identifying some specific urls in proxy might be our best route but open to other suggestions on how to to block Teams web client whilst allowing Teams desktop client.Problem with Teams meeting Add-Ins in Outlook 2016
In my organization we have a problem with the complement to generate Microsoft Teams meetings in Outlook. The problem is that when using the plugin to generate a meeting, it displays the following message: "We couldn´t schedule the meeting. Please try again later". In my organization we use a proxy server to navigate, I have noticed that if I deactivate the proxy the add-in works correctly. Anyone had this problem?Proxy rules for login interface
We're rolling out MS Teams behind a corporate proxy which requires users to accept an AUP the first time they access the Internet in a session. This policy is bypassed for all traffic with a User agent string containing "Teams/*", but the login interface seems to use a generic UAS instead, so it failing until the user opens their browser and accepts the AUP to 'unlock' their Internet access. I've also added http*://login.microsoft.com/* and http*://*.msidentity.com/* to bypass this policy, but it still seems to be failing. Do I need to add the A records that these CNAMEs resolve to as well? As these are hosted by a CDN, is there a more granular set of URLs I can add, or do I need to add the whole CDN Domain?
