Phase out Legacy Authentication - The first 90%
Blog series
This is part three of the six-part series on “Phase out Legacy Authentication”.
- Preface
- Enable Modern Authentication
- Create prerequisites
- Gain insights
- The first 90%
- The next 9%
- Endgame
Recap
The first three parts of the series set the stage (1/2) for the deactivation and used Entra ID (Azure AD) workbooks and Kusto queries to identify the first usergroup.
Add AAD group members
To go straight ahead, the Entra ID (Azure AD) group CAPolicy-Include-Block-Legacy-Authentication
must be populated with the users from the last query. /
This prevents these users from beginning to use legacy authentication protocols in the next few weeks.
If you want to be extra careful, you can increase the time period in the query to, for example, 30 days.
|
|
The result of the query can be exported as a CSV file.
If the number of users without legacy authentication exceeds 90%, phase 2 can be started immediately.
This article is expected to be published on 06.03.2021.
Until it is published, it is a good idea to simply continue to follow along.
The following script inserts all users from the downloaded CSV file query_data.csv
into the Entra ID (Azure AD) group CAPolicy-Include-Block-Legacy-Authentication
.
|
|
After this action, all these users can no longer log in using legacy authentication. The Conditional Access Policy Temporary Policy: Block legacy authentication Rollout
blocks these connections. Since these users had not used legacy authentication in the last 7 days, there is no negative impact on the end user.
If the group has been created in on-prem AD and is maintained there, it must be taken into account that changes will only take effect after the next successful AAD Connect Sync.
The sync process can be started directly with the following cmdlet in an elevated PowerShell.
Start-ADSyncSyncCycle -PolicyType Delta
Role play - What happens to the user?
In fact, the work for this step would be done with this. A large percentage of users are now better protected against attacks like password spraying or credential stuffing. MFA is already enabled, isn’t it?
But to better understand the impact of the change, let’s take a look at the other side.
- How will the block affect users?
- What kind of impact should one expect?
- Where can you prepare or change things now?
Exchange ActiveSync
As mentioned in part 3, the Exchange ActiveSync service is handling the deactivation in a very particular way.
Instead of rejecting the connection immediately and sending the user an undefined error message from the mail client, Microsoft has decided to allow the login. As long as the user used the correct password.
In the corresponding SignIn logs this is displayed as follows:
What looks like a successful login at first glance is not. The column Conditional access
correctly shows “Failure”.
In the tab “Conditional Access” it becomes clear that the Temporary Policy: Block legacy authentication Rollout
has blocked the login.
A look at the user’s smartphone reveals the reason for this somewhat strange situation.
Instead of having all emails displayed, the user is shown only one email. This is titled “Your email access has been blocked”.
The content of the message contains a slightly more detailed, though not always helpful, message to the user.
You are receiving this message because your IT department has blocked your email access. This could be due to temporary conditions, like your network location.
Contact your IT department with any questions or concerns about this mail. This email was automatically generated by Microsoft Exchange.
POP3, IMAP and SMTP clients
Access via POP3 or IMAP is answered with a corresponding error. Thunderbird, for example, does not leave the user completely out in the cold and indicates that the selected configuration may have been disabled by the administrator.
Depending on the email client used, the results will of course look very different.
For SMTP clients, the deactivation is even more problematic. Especially in established IT environments, MFP devices and appliances send SMTP emails to their internal users or external partners. If it is not a Hybrid Exchange setup, where the local Exchange server still takes on the role of a SMTP relay, the deactivation of Legacy Authentication is the end of emails from those clients.
Microsoft is working on a solution: OAuth 2.0 support for IMAP and SMTP AUTH. But realistically this solution will not be implemented in the old printer firmware or the UPS software in the basement.
An alternative is therefore to send the messages unauthenticated directly to the company MX endpoint (bader-cloud.mail.protection.outlook.com) and to set up the SPF record for the originating IP address.
Or, if external mail delivery must also be possible, the additional setup of an Exchange Connectors.
Microsoft has listed an overview of the advantages and disadvantages of these solutions here.
Teams Rooms
Teams Rooms systems supported Modern Authentication since version 4.4.25.0 (31/03/2020).
In a smaller environment, this can be changed manually on each device. For larger environments, a SkypeSettings.xml
file can be copied to the C:\Users\Skype\AppData\Local\Packages\Microsoft.SkypeRoomSystem_8wekyb3d8bbwe\LocalState
folder on the devices via a endpoint management tool or script.
<SkypeSettings>
<UserAccount>
<ModernAuthEnabled>true</ModernAuthEnabled>
</UserAccount>
</SkypeSettings>
This XML file changes the default value from False
to True
and prevents fallback to Legacy Authentication.
PowerShell modules
If old PowerShell modules are still being used to manage the Microsoft 365 environment, it is time to inform the respective administrators about the newer alternatives.
- Azure Active Directory PowerShell for Graph
- Microsoft Azure Active Directory Module for Windows PowerShell
- Skype for Business Online Abgelöst durch das Microsoft Teams PowerShell Module
- Exchange Online & Security & Compliance Center
- Microsoft Teams
The error message that the user will get here is simply an AccessDenied
.
Other clients
Almost all other clients will also only display an Access Denied to the user and will not be able to provide any further information about the cause.
Therefore, it is essential to inform the technical support so that they can react accordingly and not look for a deactivated user or a wrong password as the cause. It is also a good idea to give support staff access to the Entra ID (Azure AD) SignIn logs for analysis. This can be done via the membership in the role Reports reader
.
Next steps
The next part of the series will identify the remaining affected users and inform them in a targeted manner based on what we have learned today.