Bug 424231 - Logging in to a enterprise managed EWS server "needs" MS intune
Summary: Logging in to a enterprise managed EWS server "needs" MS intune
Status: CONFIRMED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: EWS Resource (show other bugs)
Version: unspecified
Platform: Manjaro Linux
: NOR major
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-15 11:52 UTC by Víctor Chico
Modified: 2023-03-09 07:50 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Víctor Chico 2020-07-15 11:52:48 UTC
SUMMARY
The browser used to log in with OAuth2 when creating a MS Exchange Agent is identified as an Android platform, which, if the company needs your device to be managed by them to log in eventually leads to a "Install MS Intune fom Google Play" page

STEPS TO REPRODUCE
1. Try to log in via OAuth2 to a MS Exchange server which needs enterprise managed devices to enforce security.
2. Click the "Enroll now" to allow the company to manage your device (Clicking More Details will show you that your device is identified as Android)
3. The Install MS Intune from Google Play page shows up

OBSERVED RESULT
The EWS Agent can't get a successful connection to the Office 365 EWS server

EXPECTED RESULT
Get a successful connection to the EWS Server

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: KDE Plasma 5.18.5 over 5.6.16-1-MANJARO kernel
(available in About System)
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.70.0
Qt Version: 5.15.0

ADDITIONAL INFORMATION
Comment 1 Martin Steigerwald 2020-07-15 12:05:53 UTC
Thank for your the bug report.

I do not think Akonadi EWS can do anything about it. That is just how Microsoft Intune works¹. Unless your employer is willing to grant to an exception, I'd say you are locked out.

Leaving it open for Krzysztof, the developer of Akonadi EWS, to check on this.

[1] That is not to say that I agree with the approach behind Microsoft Intune. It is fundamentally incompatible with free software as far as I understood. Consequently as far as I know it only supports Windows, Mac OS X and Android as platforms.
Comment 2 Víctor Chico 2020-07-15 12:15:25 UTC
Of course, I agree with you, I don't think having a EWS Server as a company mail server is a good idea either, but the thing is that I do log in when I use a regular web browser (i.e. Firefox) and in evolution (with evolution-ews for that matter) I think is just that, as the embedded browser to log into office 365 identifies from the akonadi console identifies itself as if it were in an Android platform, the EWS Server redirects the request to the MS Intune install page (the android one in this case) instead of finishing the log in, that's the bug I was trying to file (the browser reporting itself as android, don't know if is the EWS server part which automatically ignores GNU/Linux and marks it as Android), forgive me if I wrote a misunderstanding description.
Comment 3 Martin Steigerwald 2020-07-15 15:02:33 UTC
Thank you. That is an important clarification. If your company Intune policy allows the use of Linux clients and the login works with Evolution EWS, then it indeed appears to be an issue with Akonadi EWS.

Did you try different user agent strings (see advanced settings for Akonadi EWS)? Maybe use the same that works in Evolution EWS. For the login thing, Qt WebEngine might be used, though, so it may be related to that, and the user agent setting may not make any difference.
Comment 4 Víctor Chico 2020-07-16 08:40:10 UTC
I think I found the issue, but I can't compile kdepim-runtime (something about dependencies with kf5akonadi, I suppose my version isn't new enough, seems to need 5.14.3 and I have 5.14.1 but I really don't know, it's my first time with c++, qt, cmake and everything)

In /resources/ews/ewsclient/auth/ewsoauth.cpp we have a variable called o365FakeUserAgent which includes the Android part that eventually will cause a redirect to the MS Intune installation from Google Play, a comment around line 316 says that this is because the EWS OAuth2 server actively blocks Linux but I would like to try it, could you point me how to solve my dependency problem or how to get a sane building environment?

Thank you.
Comment 5 Martin Steigerwald 2020-07-16 09:28:56 UTC
Good catch, Victor, read the "Bad bad Microsoft..." comment for a reasoning behind this.

https://invent.kde.org/pim/kdepim-runtime/-/blob/master/resources/ews/ewsclient/auth/ewsoauth.cpp

If you like to dig a little deeper and make it easier for Krzysztof to fix this issue, I suggest you dig up the evolution-ews source code and look there what they use.

https://gitlab.gnome.org/GNOME/evolution-ews

Krzysztof, maybe it would be good to allow users to override this user agent string, too? In case Microsoft has a new idea on locking out users in the future?

As for the compilation dependencies, if you use kdesrc-build, I think you can tell it to compile everything else that is needed in a newer version as well. But maybe you also just have to install the -dev / -devel package for the library in question, in case you did not already do so.
Comment 6 Martin Steigerwald 2020-07-16 09:29:35 UTC
I think it is fair enough to set this report to confirmed, after you dug out the source code location.
Comment 7 Krzysztof Nowicki 2020-07-28 07:38:30 UTC
(In reply to Martin Steigerwald from comment #5)
> Krzysztof, maybe it would be good to allow users to override this user agent
> string, too? In case Microsoft has a new idea on locking out users in the
> future?

The user agent setting is overrideable, but only for regular EWS requests. The OAuth2 requests were a bit different due to reasons stated in the comment.

My employer does not mandate InTune for access from Android, so I cannot test it, but what I can do is to add a possibility to override the OAuth2 user agent in the configuration file.
Comment 8 Krzysztof Nowicki 2020-07-28 12:26:02 UTC
One thing to add - it may be that changing the user agent string will not help you in case your administrator has mandated use of device registration (which InTune does) for all clients in which case - no matter what you invent in the user agent string - it will give you nothing except different error messages applicable to the OS that is reported.

In such case you have two options:
 - register your device with the Azure AD using the MDM protocol (I have promised myself to write a script to do this one day, as I have some dumps from a Win10 doing this),
 - steal the device certificate & key from a Windows system you own - in my company native Linux users use Windows virtual machines, which of course are registered and are a good place to look for the keys.

In any case setting up this key in Akonadi EWS configuration (Private Key (PKey) Authentication section) will cause it to appear as if it has registered with InTune and will let you work normally.
Comment 9 Sergei Gureev 2021-01-21 11:00:54 UTC
I ran into this issue, but instead of intune it asks to install Community Portal, which is the same thing under a new name, I presume.

"Troubleshooting details" from the page that is displayed after the auth form:

App name: Akonadi EWS
App id: 452b289a-7894-41d7-9cd4-d5275739fa27
Device identifier: Not available
Device platform: Android
Device state: Unregistered

> steal the device certificate & key from a Windows system

Krzysztof, can you please provide more detailed instructions on how to do that? Where they are stored and what "Key password" should be used?
Comment 11 Link P 2021-05-12 23:49:22 UTC
The choice of 'Android 7.0' as the OS in the o365FakeUserAgent string causes additional problems for anyone using Conditional Access via Duo Authenticator with Policies that block End Of Life operating systems. (Android versions <= 7.1.2 are EOL)

The browser version is hard-coded at 'Chrome/59.0.3071.125' which, at 30 releases behind current is problematic for Duo policies that require up to date browsers. (Chrome is currently at Chrome/90.0.4430.212)

I don't know if this OAuth2 call could be sourced out to the user's regular desktop web browser, but if it could, it seems like it would clear up a wide variety of problems, including the hard-coded obsolete version strings that don't have their own reported issue yet.
Comment 12 Arsimael Inshan 2022-03-17 14:20:50 UTC
Hi,
Sorry to dig up an ols bug, but there are some new Informations from an 'enterprise enabled' admin:

On the company I work for, "Conditional Access" is enables for Android and Windows Systems while Clinets coming from the company network with a "Linux" User Agent are currently excepted. Akonadi gets blocked from Access, 'cause it's authenticating as "Android 7.0".

If this variable is changeable (or even better, tied to the actual installed (default) Browser, which is most likely eigher Firefox or Google Chrome, since they have management interfaces for companies) would indeed help solving this problem.
Comment 13 Amand Tihon 2023-02-13 13:49:28 UTC
I'm experiencing the same issue here, on the Ubuntu 22.04 approved by the company.

Our IS department have contacted their Microsoft representative about it, but as far as I understand it, Microsoft has no intention to change it on their side (considering the user-agent string that is used by akonadi-ews, I also understand their position).
To me, it confirms that the fix, whatever form it should take, has to come from akonadi.