For you Exchange Online / ADFS Administrators who have to support your older IMAP clients, you may have had to wrangle with your ADFS deployment, specific the Client Access Policy (CAP) settings, which limit which users/devices can use the ADFS Services.
Many times ADFS is deployed internally, so users MUST be on the corporate network in order to access the server. The default ADFS Token Issuance rule states that any authenticated user can use the server/ADFS service, however there is the ability to define Client Access Policies (CAP) which have a more granular approach, on who/what/where these users must be or conform before they are allowed access.
There are many sites and articles on how the use the ADFS CAP rules, one of particular note is the Client Access Policy Builder, created by a Microsoft person, which is a graphical UI that helps in defining these conditions and requirements for accessing ADFS. If you are looking to create and use an ADFS CAP setting, you should definitely review all available material BEFORE turning on this feature, as I found, it can be tricky:
ADFS Client Access Policy Builder
Sample ADFS CAP Entry
Rule to allow Autodiscover, ActiveSync and POPIMAP Access when coming through ADFS-Proxy, which covers Exchange Online.
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D)
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/services/trust/2005/usernamemixed”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.ActiveSync”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.Autodiscover”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.POPIMAP”])
&& exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “”<NEED any Internal and EXO and O365 IP Addresses HERE>”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);
When defining the CAP you will find that you can define different applications, connections, etc. I found that while allowing Microsoft.Exchange.Autodiscover and Microsoft.Exchange.ActiveSync, I did NOT define Microsoft.Exchange.POPIMAP, which stopped my Thunderbird IMAP clients from obtaining authorization and authentication. As a result Thunderbird seemingly connects into an Exchange Online MBX, however their LIST request for the different folders errors with Bad or Invalid Data. As a result the issue appears to be a Protocol/EXO services issue, when in fact ADFS is failing to allow the user to authenticate.
SO if you are going to use ADFS CAP AND you are defining entries for Microsoft.Exchange.ActiveSync and other items and you will be using POPIMAP, then you must also enter the Microsoft.Exchange.POPIMAP entry as well, otherwise the IMAP client will fail during connectivity but show that is has authenticated without issue….very strange.