What is the teams.microsoft.com website doing that works under debian-10 but not under kicksecure-15?

Support
1

In short: all else being equal microsoft teams website let’s me login under debian-10 or windows-7 but not under kicksecure-15. I am curious and want to find out why. Can you give me a strategy how to investigate?

In detail:

  • I have a qubes VM work-web that runs using my debian-10 template with the brave-browser (all works fine here)
  • Next I cloned the debian-10 template to kicksecure-15 and installed kicksecure. Then I switched all my qubes VMs that previously ran under debian-10 to kicksecure-15. All work exactly as before except work-web.
  • I can no longer log into the teams website with Duo authentication if work-web uses the kicksecure-15 template. If I switch back to debian-10 it works. Back to kicksecure-15 it doesn’t.
  • I have not modified the templates in any other way other than the clone & install kicksecure-cli

I suspect kicksecure-15 is doing exactly what it is supposed to do and somehow the teams login process extracts some system detail during the login process. I’d like to find out what that is. Any ideas?

2

Try another browser?

3

Try another browser?

I tested once more to be sure and installed Chromium and Firefox-ESR in
both the debian-10 template and the kicksecure-15 template (the later
one was previously cloned from debian-10 and then kicksecure-cli was
installed).

All of them (brave, chromium & firefox) work when the debian-10 template is used and all of them see the endless login loop when kicksecure-15 is used.

4

Other types of networking (normal browsing) functional?

Try separate debian-10 template VMs.

Try another template VM such as fedora.

VM Fingerprinting related?

5

In the end it turned out to be a time issue. Calling sudo qvm-sync-clock
fixes it. Took me a while to figure it out.

1 Like
6

More to the point:

* once sys-net ran based on a template that uses kicksecure the

systemd-timesyncd wouldn’t run because of the presence of sdwdate

* sdwdate wouldn't run because there was no tor circuit

* clockvm was set to sys-net

–> setting clockvm to sys-whonix makes qvm-sync-clock in dom0 work
correctly again … and the all the qubes get the correct time