AADSTS53003: Blocked by conditional access

[Erik Grant]

I access Office 365/Skype for Business through Linux, and my company has recently put in some policies that interfere with my ability to access those services. The error I get is "AADSTS53003: Blocked by conditional access." I have been using O365 apps like Outlook/Teams etc. through portal.office.com, and initially those were getting blocked by conditional access as well. We were able to find a User Agent override for the web browser that re-enabled them for us though.

To access Skype for Business, we have been using the SIPE plugin and a user agent override to allow us to connect. That method is no longer working for us. I tried just about every user agent string I could find online, and even pulled the user agent string from the Skype logs on my windows machine in an attempt to find whatever the server is looking for (which is UCCAPI/16.0.8431.2299 OC/16.0.8431.2299 (Skype for Business) , if that helps).

Has anybody managed to get around this issue before? The fact that my browser was able to sidestep the problem with a user agent string makes me think Pidgin probably can as well, but I have no idea what else to try for a user agent string override. Is there any way I can find out on my end what user agent string the server might accept, or any other way I can tweak the settings of the SIPE plugin to pretend I'm connecting from a Windows machine?

Any help is appreciated!

[Stefan Becker]

Thanks for the log.

The log shows that you are using SIPE 1.20.1. Can you reproduce the issue with the latest version 1.23.3?

The log shows an authentication attempt against https://login.microsoftonline.com/RST2.srf using a security token provided by the ADFS server https://fedlogin.cat.com:443/idp/sts.wst. That valid(?) token is rejected with AADSTS53003: Blocked by conditional access. Unfortunately that doesn't tell us why the token was rejected.

But I do see one strange thing in the log: the ADFS server simply provides the token without requesting any user authentication. That sounds rather strange and I guess that is the source of the problem, i.e. it does not return a valid token.

I doubt that the user agent string is the issue. SIPE only uses the user agent string for SIP, not HTTP. This has never been an issue before, because only the SIP server applies a filter. If you can compile the SIPE source code yourself you could try if modfying src/core/sipe-http-request.c to an user agent string of your choice helps with your problem:

    header = g_strdup_printf("%s /%s HTTP/1.1\r\n"
                 "Host: %s\r\n"
                 "User-Agent: Sipe/" PACKAGE_VERSION "\r\n"
                 "%s%s%s%s",

Google'ing the error message gives at least these two hits:

• What are conditions in Azure Active Directory conditional access?
• Azure Functions and Conditional Access Policies

If I understand those pages correctly, there is a script running, which probably can check anything but we don't see what it actually rejects. The first link indicates that your system administrators should be able to tell you what conditions they actually have activated for Azure AD. My guess would be that the Device platform condition is the one causing all the trouble.

[Erik Grant]

Thanks a ton for that information. Updating to the newest version of SIPE didn't fix my problem, so I tried several different user agent strings in sipe-http-request.c. I tried many different user agent strings without any change, until I tried:

Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like Gecko) Mobile/14F89 Safari/603.2.4 EdgiOS/41.1.35.1

With that user agent I was able to log in successfully. Thanks for your help figuring out the issue, I definitely would not have gotten there on my own!

[Stefan Becker]

So only "Safari on iOS 10.3" works?

I wonder if the examples e.g. on this page might help. But I guess you would need to ask your system administrators what devices they actually have allowed in the Azure Active Directory conditional access settings...

[Erik Grant]

I'm sure that there are more devices than just iOS 10.3 that would work, that's just the one I happened to find that worked. I can try a few of the others on that page real quick to see if I get any other hits. I could ask the sys admins, but there is some longstanding friction between them and the developers who run Ubuntu (security, access control, etc.) so I'm not sure they would be eager to help me circumvent their controls.

[Stefan Becker]

BTW: is the EdgiOS/41.1.35.1 at the end really necessary? It looks like typo/copy&paste error and I can't find it in any iOS example strings...

[Erik Grant]

Below are the shortest ones I could get to work, in case that gives you any insight. I was surprised that I couldn't get any of the Windows desktop options to work for me, since the vast majority of devices using these services are Windows PC's.

User-Agent: iPhone; CPU iPhone OS 99_9 like Mac OS X
User-Agent: Android

[Stefan Becker]

So I guess with the latest code from git HEAD you should be able to use UCCAPI/16.0.8431.2299 OC/16.0.8431.2299 (Skype for Business) Android

[Stefan Becker]

If I understand the technical reference for Client apps condition / Supported mobile applications and desktop clients correctly, then I'm no longer surprised that it only accepts Android & iPhone as user agents:

Client apps	Target Service	Platform
Skype for Business	Office 365 / Exchange Online	Android, IOS