The end of basic authentication in Exchange Online…

Fall is now upon us and as we enter the month of October things are changing in Exchange Online. I hope that most of my administrative peers are aware that basic authentication in Exchange Online will be disabled October 1^st, 2022.

The preparations for this have been years in the making. I’m personally excited about the enhanced security this will bring to our customers. One of the preparation items was to prepare and release a version of the Exchange Online Management Module that no longer requires the use of basic authentication. Many administrators did not realize but even prior versions of the module that “supported modern authentication” were still leveraging basic authentication under the hood as part of the connection to Exchange Online.

Exchange Online Management Module version 3.0.0 is now published to the PowerShell gallery. With the introduction of this module administrators now have a fully modern authentication-based method of performing Exchange Online management through PowerShell. In addition, this module moves away from the legacy PowerShell infrastructure to new REST based commands. These new commands have the same look and feel without the issues that the legacy remote PowerShell infrastructure had.

Distribution List Migration module version 2.7 is now hard coded to require a minimum version of 3.0.0 to perform distribution list migrations. Administrators may upgrade to this version using the update-module ExchangeOnlineManagement command or install the module for the first-time using install-module ExchangeOnlineManagement.

Happy migrating!

Preparing for the deprecation and disablement of Basic Authentication.

October 2022 is fast approaching and the topic of disabling basic authentication in Exchange Online is a hot topic. If you were not aware, starting in October, Microsoft will begin proactively disabling Basic Authentication across the Exchange Online platforms. This is a good thing and is long overdue.

 

In addition to Exchange Online disabling basic authentication many customers are also starting to disable basic authentication in the WinRM client within windows. This effectively blocks any use of basic authentication for remote PowerShell connections even if basic authentication is still enabled in Office 365. (Note: Group policies for disabling WinRM client basic authentication does not disable basic authentication in Exchange Online).

 

When customers disable basic auth in the WinRM client connections to Exchange Online and the Exchange On-Premises PowerShell using basic authentication will subsequently fail. For example, when using the Exchange Online Management PowerShell version 2.0.5 you will observe the following error:

 

New-ExoPSSession : Create Powershell Session is failed using OAuth

At C:\Program

Files\WindowsPowerShell\Modules\ExchangeOnlineManagement\2.0.5\netFramework\ExchangeOnlineManagement.psm1:475 char:30

+ … PSSession = New-ExoPSSession -ExchangeEnvironmentName $ExchangeEnviro …

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [New-ExoPSSession], Exception

+ FullyQualifiedErrorId : System.Exception,Microsoft.Exchange.Management.ExoPowershellSnapin.NewExoPSSession

 

You might be asking yourself why does this happen if version 2.0.5 supports modern authentication? Even though this version of the PowerShell management module supports modern authentication, it does so by obtaining a token on behalf of the administrator and then encapsulating the token into the basic auth session that pulls the commandlets from remote PowerShell. It acted as a middle ground to help bring better authentication to PowerShell while still using the legacy remote PowerShell interfaces.

 

If an administrator attempts to open a basic authentication through new-pssession to Exchange On-Premises, the following error is noted in absence of basic authentication in the WinRM client.

 

New-PSSession : [server.domain.com] Connecting to remote server server.domain.com failed with the

following error message : The WinRM client cannot process the request. Basic authentication is currently disabled in

the client configuration. Change the client configuration and try the request again. For more information, see the

about_Remote_Troubleshooting Help topic.

At line:1 char:12

+ $session = New-PSSession -ConfigurationName microsoft.exchange -Conne …

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin

gTransportException

+ FullyQualifiedErrorId : -2144108321,PSSessionOpenFailed

 

As an administrator you can validate the WinRM authentication configuration using the following command:

 

C:\>winrm get winrm/config/client/auth

Auth

Basic = false
[Source=”GPO”]

Digest = true

Kerberos = true

Negotiate = true

Certificate = true

CredSSP = false

 

When originally released the DLConversionV2 module leveraged basic authentication for both Exchange Online and Exchange On-Premises commands. With the disablement of basic authentication pending the script has been updated and validated to move beyond basic authentication.

 

For Exchange Online to move beyond basic authentication administrators must install the Exchange Online Management Module preview version 2.0.6. This module supports modern authentication, removes the requirement for basic authentication, and takes full advantage of the new REST based commandlets for better performance. To begin the update process:

 

First ensure that powershell get is updated so that you may take advantage of the allow pre-release function:

 

Update-Module PowerShellGet -force <or> Install-Module PowerShellGet -force if the module was not installed by repository

 

Exit and reopen Windows Powershell to ensure the new modules are loaded.

 

Second install the Exchange Online Management preview module:

 

Install-Module ExchangeOnlineManagement -allowPreRelease <or> Update-Module ExchangeOnlineManagement -allowPreRelease

 

You may validate the success of the installation by running the following command and validating the version 2.0.6.

 

PS C:\> Get-Command -Module ExchangeOnlineManagement

 

CommandType Name Version Source

———– —- ——- ——

Function Connect-ExchangeOnline 2.0.6
ExchangeOnlineManagement

 

When using the DLConversionV2 migration module with any of the pre-collection commands for on-premises, the enable-hybridMailFlowPostMigration command, or performing a distribution list migration with enablehybridMailFlow=$TRUE the administrator must specify a different authentication method besides authentication. The -exchangeAuthentication method allows the administrator to specify the use of Kerberos authentication. In addition to utilizing an Exchange authentication method the Exchange Server specified is typically a named server and not a name associated with a load balanced group of Exchange servers. Here is an example of a sample command:

 

Start-DistributionListMigration -groupSMTPAddress test@contoso.com -globalCatalog dc.contoso.com -activeDirectoryCredential $cred -exchangeServer mail-server-a.contoso.com -exchangeCredential $cred -exchangeAuthenticationMethod:Kerberos -exchangeOnlineCredential $cred -azureADCredential $cred -enableHybridMailflow:$TRUE -dnNoSyncOU: “OU”

 

In addition to the DLConversionV2 modules 2.6.0 or newer supporting the preview PowerShell module and Kerberos it also supports certificate authentication for both Exchange Online and Azure Active Directory. This may also serve as an alternative to specifying credentials as a part of the migration process.

 

These changes and tested scenarios should allow you to transition away from basic authentication while allowing your migrations to be successful.

Adding a new method of verifying the distribution list is directory synchronized.

When a distribution list is migrated to Office 365 there are several health check pre-requisites that are performed to ensure the migration will be successful. One of the checks that is performed is to ensure that the list being migrated is directory synchronized to Office 365.

 

The check is performed by capturing the distribution list configuration from Exchange Online and reviewing the flag isDirSynced. If the flag has a value of TRUE, this signifies that the group is directory synchronized and is eligible for migration. If the value is FALSE this would typically mean the group is not directory synchronized.

 

PS C:\> Get-DistributionGroup atestgroup200 | fl isDirSynced

IsDirSynced : True

 

In Exchange Online there is a forward synchronization process that is responsible for replicating attributes and changes from Azure Active Directory to the corresponding objects in Exchange Online. It was recently discovered that in some circumstances during the forward synchronization process a distribution list that is directory synchronized would be shown as not directory synchronized.

 

PS C:\> Get-DistributionGroup TestDirSync2 | fl isDirSynced

IsDirSynced : False

 

When a distribution list migration is performed under these circumstances the migration process fails. This is by design; the migration process should fail anytime a group migration is attempted and the group is not directory synchronized. The obvious problem is that the group IS directory synchronized.

 

This situation highlights that there could be additional factors that cause migrations to fail when they should not. The real source of authority for group information is Azure Active Directory. In version 2.6.0 of the DLConversionV2 migration module an additional requirement is now present to connect to Azure Active Directory and validate group information. In the function where directory synchronization is verified if the flag in Exchange Online is set to false for any reason the information from Azure Active Directory is validated. If the information demonstrates the group is directory synchronized the migration is allowed to proceed. If the information verifies that the group is not directory synchronized the migration fails. Here is a sample of the same group above from Azure Active Directory.

 

PS C:\> Get-AzureADGroup -SearchString TestDirSync2 | fl DirSyncEnabled

DirSyncEnabled : True

 

With version 2.6.0 there are additional installation requirements. The powershell module for Azure Active Directory must now be used.

 

Install-Module AzureAD

 

When invoking a distribution list migration, you must now either specify credentials to connect to Azure Active Directory or you must specify the certificate authentication information necessary to complete the connection.

 

To specify credentials use -AzureADCredential $cred -azureEnvironemnt <Name> (Optional: Used when connecting to a non-commercial azure environment)

 

To specify certificate authentication use -azureTenantID “TenantID” -azureApplicationID “AppID” -azureCertifcateThumbprint “Thumbprint” -azureEnvironment <name> (Optional: Used when connecting to a non-commercial azure environment)

 

In most cases that same credential utilized for Exchange Online should have sufficient permissions for this operation. If there is a split delegation model the account specified for Azure AD would have to have permissions to read group information and execute the get-AzureADGroup commandlet.