Forum Discussion
Risks when enabling ADAL for Exchange Online and Skype
You are simply enabling another auth provider, it is not directly tied to MFA. As long as the client supports ADAL/Modern auth, it will follow the new auth process (with or without MFA), and if it does not support it, it will use the legacy method. Apart from some of the PowerShell modules and sme 3rd party apps, all apps should have proper support for Modern auth now.
NunoAriasSilva Thanks, but at the moment I'm really just referring to a standard unattended connection via PowerShell. Will the normal sign-in still work once modern auth is enabled assuming MFA is not enabled for the admin user that will be used in the script? The FAQ linked above seems to indicate that the traditional methods of connecting to Exchange Online will not work with Modern Auth in general, not just MFA.
Hi Matt, I could not be a problem to that because the method used in Powershell is different, I have connections using powershell without any problems.
Note: The faq is older than the previous link.
- I have checked :) and its not enabled, not for Exchange Online or Skype 4 Business
- You can check the setting in Skype for Business Online PowerShell to see if it has changed in your tenant. There is not often communication that a rollout has finished. And then if you are not using ADFS, just enable ADAL for Skype and then again for Exchange. If you have ADFS then you need to change any claims rules you have for Skype and Exchange. If you don't have claims rules then enable ADAL and consider moving to AzureAD SSO instead of ADFS
Brian Reid But it still hasn't - and there isn't communication on whether it is 'done' or will 'be done'.
- And Modern Auth is now being rolled out to all tenants apart from those using ADFS. See https://blogs.technet.microsoft.com/exchange/2019/04/01/exchange-online-modern-authentication-and-conditional-access-updates/ for this and the changes to expect.
- LOL - like the bleep above. I'd mistakenly added a t before "it". Let's hope Microsoft never introduce a product called after a little bird :-)
- Yes backwards compatibility is both positive and negative at the same time. Whilst it might sound like one is taking a pop, but I do understand how fiendishly hard it is to move forward when you have a huge incredibly complicated infrastructure where lots of things have to change at the same time for it to be totally successful. Authentication is obviously one of these areas. Just look at how long it's taking to improve email security/combat spam. It's obviously a lot harder when there are 3rd party components in the chain.
But the specific case I mention about Outlook v1803 does annoy somewhat - when Microsoft is in control of *all* the components (Windows, Edge, Office, Skype, SharePoint, Exchange, Azure AD etc), it does surprise me how often one comes across showstopper problems - and how long it takes to fix it.
Edge issues are another area where I'm loosing the plot. I've *tried* to encourage my customers to use Edge (because **bleep** should work better because it's all Microsoft) but increasingly I have to accept it's used to install Chrome :-( I even had a support case with Microsoft this week where they suggested I used Chrome for debugging. Rolls eyes! - An interesting observation. The other take on this is that Microsoft cannot just change everything on a whim to suit the latest changes in their products because their customers expect backward compatibility at nearly any cost. So much so that when impacting changes come out the implementation that you need to put in is completely dependent upon the client and the mix of client or server technologies in use and that is the role the deployment consultant brings to the table. Even if you do the work yourself, experience is necessary.
- >If we had checked for this in advance, we would not be in this mess.
I feel your pain! My client only has 50 users but I'd shudder to think what a mess you could get into with hundreds of thousands of users.
My take on Office 365 right now is that it's still a mixed up bunch of only just compatible technologies. Getting all the various factions to work together so that all features work with all components at the same time just seems too difficult.
And the MFA disaster on Monday this week makes me glad I didn't push my main client to enable MFA... - Joining this topic very late but after hitting an immediate problem with modern authentication in Office 2016 semi-annual (v1803), I wouldn't agree that turning on modern authentication is safe! I've just done a trial this evening after getting permission from the account and the test users immediately his the fault discussed here:
https://techcommunity.microsoft.com/t5/Azure-Active-Directory/Azure-AD-W10-and-Outlook/td-p/96119
This fault/issue is fixed in the current targeted semi-annual release (v1808) but occurs in the current semi-annual release (v1803 - which most Office 365 users are on). This version was released in July this year so the issue has only been recently fixed. It'll be fixed in the next semi-annual release in January so not that long to wait. Brian,
Thanks for the help and advice.
Again, I wish that the Microsoft articles were clear on this issue. If I knew this six months ago, we would not be in this current bad situation.
- Any articles that discuss app passwords are old and out of date by at least a few years. App passwords matter only when on Outlook 2010 (generally speaking) and older PowerShell modules.
Instead turn on SSO and Modern Authentication and then the user will automatically sign in (if domain joined on the Lan). Brian,
Thanks for confirming. I really wish that Microsoft did a better job of communicating this significant piece of information about MFA App Passwords not working with Modern Authentication. I still have not found any Microsoft article or document that explains this. All articles that I read tell you to use App Passwords with non-browser based clients like Outlook and ActiveSync clients. If we had checked for this in advance, we would not be in this mess.
I do not think that I can turn Modern Authentication on at this point and disrupt all of our users. If App Passwords would continue to work after enabling Modern Authentication, we could gradually transition our users.
- Modern Auth is only enabled by default on new tenants since Aug 2017. Tenants created before then need to enable it, and the sooner the better, as then you can do seemless MFA (i.e. no app passwords).
If you have already rolled out app passwords for users and on Office 2016 or later then turning on Modern Auth will impact the users, as they will stop needing to use their app passwords and use their proper password. That's an impact to the user.
That said, without app passwords already in use (so no MFA already), if you enable Modern Auth and have SSO enabled (and the correct registry settings and URL in place) then the user will not see the new login box (this will also help if app passwords are used, as the SSO will kick in). Without SSO enabled then the user will see something Daniel,
Sorry, I did not specifically address your comment:
Modern Authentication should be enabled by default so unless you've disabled it via policy, it should be fine.
For whatever reason, Modern Authentication was disabled in our tenant. I do not know why. This is the reason I posted this question and why I am concerned.
This is a tenant wide change and it seems the behavior of all the clients will change.
I opened a case with Microsoft Support, and they told me that MFA App Passwords will no longer function after I enable Modern Authentication on the tenant. They said that all the users will be immediately prompted to re-enter then passwords and then use their OTP to authentication.
So I am very concerned about this and I do not think that I can enable Modern Authentication now.
Thanks again for your help.
Thanks for the quick response.
Yes, we want to implement and we know that we need to implement.
But my main concern is the potential disruption of having to re-enter passwords and push registry changes to 500 devices, which is substantial.
Since this is a global change for the entire tenant, I do not know of a way to test on a limited basis for different types of clients to understand the impact.
Hi Jon,
I would expect Outlook 2016 to be OK - Modern Authentication should be enabled by default so unless you've disabled it via policy, it should be fine.
I believe the native iOS client also supports Modern Authentication, but only starting from iOS11. You may have some issues with older iPhones. I'm afraid I don't have any information surrounding the Android and Mac clients, however I would suggest implementing Outlook for iOS, Android, and Mac across the board as this will give you the best experience as well as additional safety (such as ATP).
Thanks
Daniel
I know that this is an old thread, and I am hoping someone here is monitoring and will reply. We have an Office 365 tenant with about 200 users. Each user has two or more devices, so we have about 500 devices in total. The clients are mostly Outlook 2016 and the iOS Native Mail Client using ActiveSync EAS. We have a few other clients including Outlook for Mac, Outlook for iOS, Outlook for Android and the native Android mail client. We have already implemented MFA for all users and devices.
In addition to Exchange we also use Skype for Business, Onedrive and SharePoint to a limited extent.
Unfortunately, I just found out that Modern Authentication is disabled for our entire tenant. We had assumed that it was enabled since most articles say that it is enabled by default, so we never verified. In order to make all these clients work with MFA we set them all up with App Passwords.
Recent guidance from Microsoft said that we should disable legacy authentication and only use modern authentication, so we checked the status of the tenant.
If I now turn on Modern Authentication now for our tenant, is this going to force all the users to re-enter their passwords on every device? Do you think that we will also need to push out these registry changes to the Outlook 2016 clients?
Any thoughts or advice would be appreciated.
Thanks
Hi Ryan,
Just wanted to say: THANK YOU SOOO MUCH! I've spent over 6 hours trying to figure out why Outlook wouldn't accept my password after enabling MFA. Then, 4 hours on the phone with Microsoft with no resolution. Your list of tips helped me get everything all squared away. The ticket for me was the "EnableADAL"=dword:00000001 registry entry. Many many thanks! My next step would have been to rebuild my workstation! Even after turning off MFA for my account, I was completely locked out of Outlook and couldn't reactivate any O365 Office applications. You sir, are a HERO! :)
Regards,
Bertie Pittman
I would always recommend advising your users of the change. It's cover for the unpredictable that happens with new implementation. If no one notices, just tell them that you we're on top of it and it was only a precaution :)
- My testing is showing the same, thanks!
sorry for the delay.
My experience has been only users that have MFA enabled are affected.
Very helpful info Ryan, thank you. Question for you.
# iOS 11.01 native mail app does support ADAL but S7 Samsung does not
For the S7 scenario, does this apply to all users, or only users with MFA enabled? We have BYOD users with mobile devices that are all over the place version-wise, and I'm curious to know if we flip the switch on this, will these users lose access even if they aren't using MFA?
Thanks
Hi Eugine,
I am working on Enabling MFA for my org which is about 1500 users. I can pass on a few tips that might save you some grief.
# Enabling ADAL is something you do globally for Exchange Online and for Skype for Business. Enabling the feature will not break legacy connections (Basic).
# Office 2016 and the lastest SFB client support modern Auth natively. Office 2013 can support it also you must ensure you have it up to date and you must manually add the registry keys below. Office 2010 and Sharepoint 2013 designer (if you use it) do NOT support ADAL and therefor can not be used without an App Password
# iOS 11.01 native mail app does support ADAL but S7 Samsung does not
#Both Exchange Online and Skype for Business Powershell now support Modern Auth however this will cause an issue for scripts you may have previuously created. (I used an cloud only automation account to get around this)
# Enabling MFA (enforcing 2 factor) caused some issues in our pilot and it was very apparent that Windows must also be up to date.
# the GUI Bulk add for MFA does not support more than 20 users per upload. (so silly)
--------Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Exchange]
"AlwaysUseMSOAuthForAutodiscover"=dword:00000001[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Identity]
"Version"=dword:00000001
"EnableADAL"=dword:00000001-------------------------------
I hope this gives you some value. having known this ahead of time would have saved me hours of work.
Best of luck
As a precautionary measure we notified all users that they may have to re-credential then went ahead and enabled it modern authentication.
Not sure what the difference in environment was, but we didn't get a single call to help desk, which we normally would have. (We do quite a bit of hand holding here)
We run a hybrid environment if that makes any difference.
-G
My experience was that most users seemed to have to re-sign into outlook. I am Azure AD connected and my experience was a bit different. Outlook came up with the username and password prompt but the username listed AzureAD\cstack@jesuits.org. It would not accept the username until I deleted out the AzureAD.
