Phase out Legacy Authentication - The next 9%
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
Having disabled the majority of users who do not use Legacy Authentication in the last article, it is now time to use the methods outlined in part three to identify the user groups that are still affected.
This data will be used to create an action plan for the deactivation of Legacy Authentication for these user groups. Additionally, the data will be used to transition the Conditional Access Policy “Temporary Policy: Block legacy authentication rollout” to Phase 2.
User groups
Outlook
Outlook supports Modern Authentication starting with Outlook 2013 (Windows) or Outlook 2016 for Mac. All older versions do not support Modern Authentication and must be updated.
Outlook 2010
If Office 2010 is still used in the field, a migration project must be started and carried out. Especially when using macros and addons, this can be a very extensive undertaking. If a deactivation of legacy authentication is necessary before the migration of Office, Outlook on the Web can be used as an alternative.
Identify users
The provided workbooks “Sign-ins using Legacy Auth” and “Conditional Access Insights and Reporting” are of very little help for the planned report. The most important information, the client used (UserAgent), is missing from the report.
Therefore, we use Kusto in order to directly query the underlying data of the workbooks .
In the Azure Portal, select “Azure Active Directory” and in the Monitoring section, select “Logs” and insert and execute the following query. Make sure that the time period of the query is set to “Set in query”.
|
|
The query outputs a list with all persons who still use Outlook 2010 (internal version number 14.0).
If there is a risk that older versions of Outlook are still in use, the version number in the query can be adjusted accordingly.
|
|
Product name | Versionsnumber |
---|---|
Outlook 2010 | 14.0 |
Outlook 2007 | 12.0 |
Outlook 2003 | 11.0 |
Action Plan
- Add affected users to the CAPolicy-Exclude-Block-Legacy-Authentication group.
- Initiate rollout of a current Office version
- Examine alternatives: Outlook on the Web
- Remove migrated users from CAPolicy-Exclude-Block-Legacy-Authentication group
Outlook 2013
In Outlook 2013, Modern Authentication is not the default and must be enabled via registry key.
If possible, a group policy should be created and distributed to the affected users. Since this is not a standard setting in the group policies, the two registry keys must be added manually.
Alternatively, the values can be set to via script.
$RegistryPath = "HKCU:\Software\Microsoft\Office\15.0\Common\Identity"
if ( -not ( Get-Item $RegistryPath -ErrorAction SilentlyContinue) ) {
New-Item $RegistryPath -Force | Out-Null
}
New-ItemProperty $RegistryPath -Name Version -PropertyType DWORD -Value 1 -Force | Out-Null
New-ItemProperty $RegistryPath -Name EnableADAL -PropertyType DWORD -Value 1 -Force | Out-Null
Identify users
|
|
Action Plan
- Add affected users to the CAPolicy-Exclude-Block-Legacy-Authentication group.
- Rollout of the group policy settings
- After one week check if the group policies show the desired success
- Remove migrated users from CAPolicy-Exclude-Block-Legacy-Authentication group
Microsoft 365 Apps for Enterprise, Outlook 2016 und später
Modern Authentication is enabled by default and no further action is required.
Exchange ActiveSync
For Exchange ActiveSync, the best alternative is to switch to Outlook for iOS and Android.
The advantage of switching to the Outlook app, as opposed to other Modern Auth enabled clients, is that other Microsoft 365 features can be used later.
This includes e.g.
More information about this can be found in the FAQ.
Native apps like iOS Mail and GMail must be explicitly approved before use if users do not have the right to approve apps themselves.
There is an alternative way to deactivate this group of users. By using another Conditional Access Policy only Exchange ActiveSync can be explicitly blocked. This way, users who have Outlook 2010 and Exchange ActiveSync will not be prematurely removed from the exception group.
However, this path is optional and not required for deactivation.
Identify users
|
|
After the users have been identified, they must be informed about the change.
When communicating, a two-stage notification by e-mail is recommended.
First email
The first email will be sent one week before the deactivation and will contain the necessary documentation for the migration, e.g. for the installation and setup of the Outlook for iOS and Android app.
To make the switch to Outlook for mobile as easy as possible Microsoft offers cheat sheets for these products. These documents summarize the core functions of Outlook on two pages. If desired, these can also be included in the communication.
Reminder email
The second email serves as a final reminder and will be sent one day before the deactivation.
Also inform your 1st level support so that they can identify the use of an ActiveSync client in case of the error message below and advise the use to install Outlook for iOS and Android.
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.
Action Plan
- Add affected users to the CAPolicy-Exclude-Block-Legacy-Authentication group.
- Optional: Conditional Access Policy “Temporary Policy: Block ActiveSync clients” anlegen
- First communication to users approx. 1 week before deactivation
- The day before deactivation, send the reminder email
- Default: Remove users from the CAPolicy-Exclude-Block-Legacy-Authentication group on the communicated date.
- Optional: Activate the conditional access policy “Temporary Policy: Block ActiveSync clients” on the communicated date.
POP3 and IMAP clients
Users of POP3 and IMAP clients should also be advised of the alternative Outlook for iOS and Android.
However, with these protocols it is not unusual for a service user to access a mailbox in order to further process e-mails. In this case, an customization of the software is necessary. Until this customization has been performed, the user must remain in the CAPolicy-Exclude-Block-Legacy-Authentication group.
Identify users
|
|
In addition to the user name, the protocol used is also included.
Action Plan
- Add affected users to the CAPolicy-Exclude-Block-Legacy-Authentication group.
- First communication to users approx. 1 week before deactivation
- The day before deactivation, send the reminder email
- Remove users from the CAPolicy-Exclude-Block-Legacy-Authentication group on the communicated date.
SMTP Clients
For SMTP clients, an modification of the client or the method is necessary in any case.
Customization of the client app possible
If the client app was developed in-house and is still actively maintained, it is a good idea to switch to SMTP AUTH with OAuth 2.0 support.
Client app cannot be customized
In many cases, it will unfortunately come down to the fact that a customization of the client app is not possible and you can only set the parameters for authentication and the server.
Internal recipients
If only mailboxes in the own tenant have to be reached, the unauthenticated sending via the server tenantdomain.mail.protection.outlook.com
is the simplest alternative.
To prevent the mails from ending up in the spam folder of the users, the sending public IP address must be maintained in the DNS as part of the SPF entry. e.g.
"v=spf1 ip4:12.34.56.78 include:spf.protection.outlook.com -all"
To check the changes you can use e.g. the Google Admin Toolbox.
Mail recipients internal and external
If external recipients also need to be written to, the above implementation is not sufficient. An Exchange Connector must be set up.
However, the adaptation of the SPF is necessary in any case.
Identify users
|
|
Action Plan
- Add affected users to the CAPolicy-Exclude-Block-Legacy-Authentication group.
- Implement Microsofts mail flow best pratices
- Remove migrated users from CAPolicy-Exclude-Block-Legacy-Authentication group
Other client applications
The use cases mentioned above should apply to the majority of the remaining users. For all other users, it is necessary to check together with the user which application is still using legacy authentication in order to replace it.
There is no blueprint for this procedure. However, the UserAgent gives a good indication of the application used.
Examples are e.g.
UserAgent | Application | Migration |
---|---|---|
Mac+OS+X/10.15.7 (19H524) CalendarAgent/930.5.1 |
Apple Calendar | Outlook for Mac |
AppleExchangeWebServices/807 ExchangeSync/121 |
MacOS Mail | Outlook for Mac |
Microsoft WinRM Client |
Outdated PowerShell module | Look here |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
Thunderbird | Outlook on the web |
Identify users
|
|
Action Plan
- Add affected users to the CAPolicy-Exclude-Block-Legacy-Authentication group.
- Check the migration options together with the user
- Remove migrated users from CAPolicy-Exclude-Block-Legacy-Authentication group
Switch to “Explicit Allow”
After all affected user accounts have been identified and are members of the CAPolicy-Exclude-Block-Legacy-Authentication group for the transition period, it is time to start Phase 2.
In this phase, the Conditional Access Policy Temporary Policy: Block legacy authentication rollout
is configured to block any user who is not an explicit member of the group.
This protects new users immediately and makes it easier to gradually remove users from the exception group.
Add to group
The script from part 4 is a good way to add the users to the group.
You only have to change the file path in line 4 and the group name in line 5.
|
|
The required CSV files can be created with the above featured Kusto queries and the export function.
Modify the conditional access policy
In the Azure Active Directory portal select “Security” -> “[Conditional Access](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies" and then the policy “Temporary Policy: Block legacy authentication Rollout”.
Select “Users and groups” -> “Include” -> “All guest and external users” and check that in the “Exclude” tab the break glass account as well as the group “CAPolicy-Exclude-Block-Legacy-Authentication” is selected.
Then save the conditional access policy.
With this change, the majority of users are no longer able to use legacy authentication.
Now start to implement the outlined action plan to remove more and more users from the exception group.
Next steps
Implementing the above actions will almost certainly take some time.
Meticulously maintain the exceptions group to prevent users from still being on the list even though they no longer use legacy authentication.
Periodically check to see if the total number of users using Legacy Authentication is decreasing. To do this, use the “Conditional Access Insights and Reporting” workbook and filter for the report-only policy “Common policy: Block legacy authentication” and the incorrect login attempts.
In the last part of the series, we’ll look at the finishing touches and the final 1%.
Optional step: Block Exchange ActiveSync Conditional Access Policy
If, as described above, the Exchange ActiveSync client is to be blocked regardless of the exception list, the following Conditional Access Policy must be created.
After creation it is in Report Only mode and has no effect yet. Only when it is activated, the users can no longer use Exchange ActiveSync.
- Use the Entra ID (Azure AD) portal -> Security -> Conditional Access to create a new policy with the name “Temporary Policy: Block ActiveSync clients”.
- Select Assignments -> “Users and groups”
- Include: “All users”
- Exclude: Break Glass Account
- Include: “All users”
- Select Assignments -> “Cloud apps or actions” -> “Select apps” -> “Office 365 Exchange Online”
- Now restrict the policy “Conditions” -> “Device platforms” to “Android”, “iOS”, and “Windows Phone”
- For “Conditions” -> “Client apps” chose only the Legacy authentication client “Exchange ActiveSync Clients”
- “Access controls” -> “Grant” must be “Block access”
- Finally, set the policy to “Report-Only” and create it.
Do not exclude the current user from the policy. This is what the Break Glass account is for and the policy is additionally in the state Report Only.