Basic Auth and Exchange Online – February 2020 Update

greg Taylor Re: Remote PowerShell. I was also referring to non-interactive scripts. We’re using the V2 EXO module in all our non-interactive PowerShell automation scripts. We were advised by our Microsoft contact “Certificate Based Authentication is only applicable for scenarios where tenant has enforced MFA on all the accounts or if they have not invested in a secure password manager solution and would like to go for a solution where credential store is not required. Since your org has already invested in [removed] password manager, you can use Modern Auth to run automation scripts using Service Account with V2 EXO module.” Based on the sign-in logs, it appears that our Service Account that runs all of our automation PowerShell scripts is now using Modern Auth for all connections to EXO as the client app is showing as “Mobile Apps and Desktop clients” in the report. So am still confused as to why the above blog post states we need to wait another few months for the cert-based auth solution for automation/non-interactive requirements. Can you clarify? Re: Office for Windows and Mac. My comments were based on a previous manual report our Microsoft TAM provided, not on the Azure AD sign-in logs. In those logs we simply see the client app as “MAPI OVER HTTP” and the user string shows as “Microsoft office 15/Outlook 15.0.5172” as an example. Another example from Mac is client app as “autodiscover” and user string as “MacOutlook/16.32.0.191208”. We’re also seeing the same in the reports for Mac Outlook but with client app as “REST”. We have not yet had the chance to check the actual workstations of the impacted users. But we have 100s of users in these categories. We have the EnableADAL reg key set on all workstations using GPOs. If you can clarify the pref setting required on MacOS, I can ask our Mac team to check. Couple of other issues we’ve observed from a first look at the sign-in logs. The date column isn’t included in the downloadable reports which is very annoying because you can’t correlate the activity with a specific date/time. The only date provided is the date the report was created/downloaded, not the date of the sign-in activity itself. And the 250,000 record download limit is way too low for our tenant. If we want to download a report for all Basic Auth use across all protocols for one month, we immediately exceed the record limit. Even for 7 days we exceed the limit. Which means manually exporting smaller logs either on a per protocol basis or weekly or even daily, which is a lot of manual work!