I have the same issue as above.
- installed teams_1.3.00.5153_amd64.deb onto Ubuntu 20.04 LTS
- I can start up Teams, and sign in with my personal microsoft/skype account usename/password, and everything works
- If instead I log in using my work ID (federated company sign-in), behaviour is exactly as per Anton's video. I get directed to the organisational sign-in page, then on being returned to Teams am stuck in a kind of redirect-loop which stops after a while with the 'can't log you in' message.
If I sign in on my Windows 10 system, the company login works fine and Teams starts up ok.
On Both systems, my main browser is Firefox 77.0.1 (64-bit). I use Firefox Sync, meaning that both the Ubuntu and Windows systems have identical Firefox settings, plugins etc.
Perhaps related to this problem - I can sign in using my company federated login to office.com to access Office365 apps on the Windows 10 system - but not on the Ubuntu Linux system. After login on Ubuntu, using the same version of Firefox as on Windows with the same settings, I am returned to the office.com main page with login link as if I had not logged in at all. The same happens using Chrome on Ubuntu.
However, if I use a browser plugin to change the Ubuntu Firefox (or Chrome) user-agent string to mimic the user-agent string on the Windows 10 computer - ie. in Firefox I change it from
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0
to
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
Then the office365 login from Ubuntu works fine, and I can access and use the office365 apps - onedrive, excel etc - fine. Just by only changing the user-agent header sent by the browser to make it look like I've logged in from a Windows machine.
Could the Linux Teams client federated login be hitting the same issue around user-agent header handling as the office365 login? I notice that when Linux Teams is running, there are teams processes visible with a --user-agent string as an argument to the process (obviously including the detected OS details - X11; Linux x86_64). I haven't yet been able to rig up anything that will change this --user-agent argument to mimic a Windows client when the Teams processes start up, in order to test if that fixes the Teams login as it did the office365 browser login
Grateful for any investigation / feedback / fixes to this - and many thanks for releasing a Linux version - much appreciated!
I have the same issue as above.
- installed teams_1.3.00.5153_amd64.deb onto Ubuntu 20.04 LTS
- I can start up Teams, and sign in with my personal microsoft/skype account usename/password, and everything works
- If instead I log in using my work ID (federated company sign-in), behaviour is exactly as per Anton's video. I get directed to the organisational sign-in page, then on being returned to Teams am stuck in a kind of redirect-loop which stops after a while with the 'can't log you in' message.
If I sign in on my Windows 10 system, the company login works fine and Teams starts up ok.
On Both systems, my main browser is Firefox 77.0.1 (64-bit). I use Firefox Sync, meaning that both the Ubuntu and Windows systems have identical Firefox settings, plugins etc.
Perhaps related to this problem - I can sign in using my company federated login to office.com to access Office365 apps on the Windows 10 system - but not on the Ubuntu Linux system. After login on Ubuntu, using the same version of Firefox as on Windows with the same settings, I am returned to the office.com main page with login link as if I had not logged in at all. The same happens using Chrome on Ubuntu.
However, if I use a browser plugin to change the Ubuntu Firefox (or Chrome) user-agent string to mimic the user-agent string on the Windows 10 computer - ie. in Firefox I change it from
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0
to
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
Then the office365 login from Ubuntu works fine, and I can access and use the office365 apps - onedrive, excel etc - fine. Just by only changing the user-agent header sent by the browser to make it look like I've logged in from a Windows machine.
Could the Linux Teams client federated login be hitting the same issue around user-agent header handling as the office365 login? I notice that when Linux Teams is running, there are teams processes visible with a --user-agent string as an argument to the process (obviously including the detected OS details - X11; Linux x86_64). I haven't yet been able to rig up anything that will change this --user-agent argument to mimic a Windows client when the Teams processes start up, in order to test if that fixes the Teams login as it did the office365 browser login
Grateful for any investigation / feedback / fixes to this - and many thanks for releasing a Linux version - much appreciated!
cheers Iain
--