Office 365 – Distribution List Migration Version 2.0 – Part 21

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.