Deprecation Of Basic Authentication In Microsoft 365. What To Do Next?

Authentication In Microsoft 365

Microsoft deprecated (disabled) the Basic Authentication for Microsoft Dynamic 365 for some specific protocols. The planning for this deprecation began in September 2021, and it has been continuing since alerting and warning to move away from this type of authentication system.

The rationale behind this move is the increasing sophistication of cyber attackers in data theft and hacking. This is more pertinent for remote and hybrid workers who dabble between offline and online systems on a daily basis.  

Moreover, Basic Authentication is one of the oldest methods, filled with security flaws. The implementation of the new system got postponed due to the pandemic; the same situation also motivated Microsoft to take quick action.

Starting in October 2022, Microsoft disabled basic authentication, and it will affect a few systems. For those who have not made the switch, let’s see their options after the deprecation.  

Which Protocols and Services are Affected?

The following protocols and services will work with a disabled basic authentication; 

  • MAPI 
  • RPC 
  • Offline Address Book (OAB) 
  • Exchange Web Services (EWS) 
  • POP 
  • IMAP 
  • Exchange ActiveSync (EAS) 
  • Remote PowerShell 

Users working with any of these protocols and services need to make the shift to modern authentication. Microsoft has been working with its partners to disable basic authentication and help them move to modern authentication. The modern authentication is OAuth 2.0 token-based authentication, which provides stronger protection against attacks and threats.  

Introducing Modern Authentication

Modern authentication represents a cluster of different protocols working together to enhance the security of a system or resource. It can be an IMAP protocol enabling emails on Outlook or a cloud-based resource; the modern authentication system is applicable to a wide range of solutions. Examples of modern authentication are; 

  • OAuth 
  • SAML 
  • WS-Federation

The working mechanism of each of these systems is different, but their purpose is the same. That is to shift from a simple ID and password authentication system to a token-based claims system.

Basically, these systems generate a token to identify the identity of the user. Moreover, the tokens generated have more information about the access permissions of the users, and they can also be revoked.  

Consider it like this, once you enter your house, you have access to the rooms, washrooms, balconies, and everything in your house. But when you stay at a hotel, which gives you keycard access, you can only access the areas that your keycard can open. This includes your room, lounge, VIP room, and other common areas.

But you cannot enter other guests’ rooms. Moreover, the hotel management can also disable your keycard restricting your access to any of the areas.  

The token system is akin to the keycard system. You can add bespoke access control systems to the entity and govern their activities.  

Modern authentication improves three aspects; 

  1. Authentication: Users can log in to their accounts and applications to access the system within the account or portal.  
  2. Authorization: This gives managers control over who can access which aspects of the solution. It gives the capability to give specific permissions and access to the users.  
  3. Conditional Access: This type of access authorizes the users to enter only when they meet certain requirements.  

Modern authentication

Difference Between Basic and Modern Authentication

One of the major differences between modern and basic authentication is how the credentials travel from one endpoint to another. In basic authentication, the credentials travel over the internet, that too, in plain text mode. Due to this, Basic Authentication is a less secure mode of password exchange.  

These passwords are stored in a Web header field with base64 encoding. Even though the service providers use SSL encryption to secure the password, they are still susceptible to theft and unauthorized access.  

Modern authentication is a more secure and comprehensive approach to identity management. The two protocols used here are ADAL (Active Directory Authentication Library) and OAuth. The critical point is that a service or system can store the credentials, but they can only authenticate them using tokens.  

These security tokens generated at the time of a user requesting access will be available for a limited time. No user can resume the same token once generated after the expiration. Moreover, the system administrators can also define the scope of each permission, like keycard access. This way they can easily govern which user has access to which part of the system.  

The Procedure to Switch to Modern Authentication

Depending on the protocol, the procedure to migrate to modern authentication differs.  

POP, IMAP, and SMTP Auth

We need to use OAuth authentication to build a connection between POP, IMAP, and SMTP. Doing so will allow Microsoft Dynamics 365 users to access their email data. Azure Active Directory provides OAuth Authentication services. The process has three steps; 

1. Register the application with Azure AD

The registration process is simple enough to understand as you move ahead. However, there are a few prerequisites, including; 

  • The users need to have an Azure account with an active subscription. 
  • The Azure account must have permission to manage applications in Azure AD. The roles that can have these permissions are Application Administrator, Application Developer, and Cloud Application Administrator.  

The Azure account must also be configured to complete the Tenant account. For registration, as you open the Azure account, make sure to select the right tenant on which you need to register. After selecting the tenant, select Azure Active Directory, locate App Registrations in the Manage Menu, and click on New Registration.  

2. Share Application Details

In the New Registration page, you need to enter the required information about the application. This includes its name and who can use the application. You can choose from four types of users; 

  • Accounts in this Organizational Directory 
  • Accounts in any Organizational Directory 
  • Accounts in any Organizational Directory, and personal Microsoft accounts 
  • Personal Microsoft accounts 

In the next step, leave the Redirect URL empty and then move on to selecting Register, which completes the .  

initial application registration

After the registration is complete, make sure to note the Application or Client ID. This unique number will be your application’s unique identifier for the Microsoft Identity Platform.  

3. Avail the Access Token

The easiest way to get an access token is to use MSAL Client Libraries. This access token will be dedicated to your application. Another way is to work with the suitable flow to get an access token. These flows include; 

  • OAuth2 Authorization Code Flow 
  • OAuth2 Device Authorization Grant Flow 
  • OAuth2 Client Credentials Grant Flow 

While asking for access token for your application, it is essential to specify the full scopes, including the protocol and outlook resource URLs. The URLs for each protocol are as follows; 

4. Authenticating Connection Requests

The last leg of the process is authenticating the connection requests for IMAP, POP, and SMTP AUTH.  

IMAP Protocol Exchange:

For IMAP Authentication, the user needs to send an AUTHENTICATE command with text; 

AUTHENTICATE XOAUTH2 <base64 string in XOAUTH2 format> 

After this, the resultant client-server message will read like this; 

[connection begins] 
S: C01 OK Completed 
S: A01 OK AUTHENTICATE completed.

However, if the client-server authentication fails, the following text will show; 

[connection begins] 
S: C01 OK Completed 
POP Protocol Exchange:

For the authentication of the POP server, the client must send in a request with the AUTH command in two lines; 

For the authentication of the POP server, the client must send in a request with the AUTH command in two lines; 

AUTH XOAUTH2 <base64 string in XOAUTH2 format> 

If the connection request is approved, the text that will follow is; 

[connection begins]	 
S: +	 
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlYX	 
S: +OK User successfully authenticated.	 
[connection continues...] 

However, in case the authentication request fails, the text that shows is; 

[connection begins]	 
S: +	 
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlY	 
S: -ERR Authentication failure: unknown user name or bad password.  
SMTP Protocol Exchange:

The authentication command for SMTP server connection also begins with AUTH and the format that follows is; 

AUTH XOAUTH2 <base64 string in XOAUTH2 format> 

In case of connection success, the text you will see is; 

[connection begins] 
C: auth xoauth2 
S: 334 
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlY 
S: 235 2.7.0 Authentication successful 
[connection continues...]

However, if the authentication is a failure, the client will the following text; 

[connection begins] 
C: auth xoauth2 
S: 334 
C: dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlY 
S: 535 5.7.3 Authentication unsuccessful [] 

5. Remote PowerShell

To update the authentication in Remote PowerShell, the users need to work with App-only authentication or Certificate Based Authentication (CBA). The key is to update Remote PowerShell to EXO so that it supports modern authentication. By doing so, the users can access exchange online services with the command interface.  

The Exchange Online module works together with Active Directory Authentication Library to secure an app-only token. For this purpose, we need to set up app-only authentication, which begins with registering the application in Azure AD (which we have discussed in the previous section.  

The next step is to assign API permissions to the application. Without setting it up, an application has the default permission User. Read. However, to set up the application object and have it access resources, it needs to have Application permission, and Exchange.ManageAsApp. Once this is done, initiate the following process; 

Generate a Self-Signed Certificate

1. Certificate Request Access:

To enable app-only authentication, the users need to use a certificate to request access. Users with the certificate and private key can use the application or solution. The user can also access all the permissions granted to the application.  

2. Create X.509 Certificate:

The user needs to create and configure a X.509 certificate that they can use to authenticate the application against Azure AD. This authentication process begins when the user requests an app-only access token.  

# Create certificate 
$mycert = New-SelfSignedCertificate -DnsName "" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange 
# Export certificate to .pfx file 
$mycert | Export-PfxCertificate -FilePath mycert.pfx -Password (Get-Credential).password 
# Export certificate to .cer file 
$mycert | Export-Certificate -FilePath mycert.cer

To generate a SHA1 certificate, the user needs to follow this link and access the code script for the same.  

3. Attaching the Certificate to Azure AD Application:

Open the Owned application pages from the Apps Registration Page and select the application. From here, navigate to Manage and select Certificates and Secrets. On this page, select Upload Certificate.  

A dialog box will open, and in this, upload the X.509 Self-Signed certificate created earlier. After uploading, click on Add. After this, the certificate will show in the Certificates section.  

Note that, for a multi-tenant application, the users need to grant admin consent.  

4. Assigning Azure AD Roles to the Application:

In this step, the users have two options; 

  • They can assign Azure AD roles to the applications, and this method is supported in Exchange Online PowerShell.  
  • They can also assign custom exchange online role groups to the required application.  

Exchange Online PowerShell

Exchange Online Powershell has different versions, and except one, all the versions support modern authentication. So, the task here is to upgrade the version from the earlier one to the latest version.  

Those who are using Exchange v1 need to switch immediately, as it has already stopped working. The Exchange v1 with MFA also does not support modern authentication. Users working with both these versions need to upgrade to Exchange v3 Module, which is the latest version.  

Before the Exchange v3 Module, Microsoft launched the Exchange v2 Module, which supports modern authentication. Plus, it is also compatible with 9 cmdlets.  

Exchange Web Services (EWS)

In addition to Microsoft Dynamics 365, several other applications use EWS to access email inboxes and send emails. Any application that uses EWS can easily switch to the modern authentication system because EWS supports modern authentication.  

However, in 2018, Microsoft announced that EWS users need to switch to Microsoft Graph. After that, EWS has not received any updates, but the good thing is that it supports modern authentication.  

To authenticate an application using EWS, the users need to use OAuth. To do so, the users need to follow a process, which is as follows; 

1. Register the Application:

Start by registering the application on Azure AD (check out the process for the same before).  

2. Add Code to Authentication Token:

The next step requires adding code to utilize Microsoft Authentication Library. This will allow users to secure authentication tokens for delegated application permissions and application permissions.  

The code for the same is;

Add Code

Next, you need to get a token with app-only Authentication; 

app-only Authentication.

3. Adding Authentication Token to EWS Requests:

Once the AuthenticationResult is here, we can then use the AccessToken property to initiate the token service for token issuance. 

Outlook, MAPI, RPC, and Offline Address Book (OAB)

Microsoft Outlook and Office versions before 2016 rarely support modern authentication. Hence, it is advisable for the users to switch to new versions if they want to leverage the benefits that come with modern authentication. All versions of Microsoft Outlook are enabled with modern authentication.  

Moreover, Microsoft Outlook for Windows uses MAPI replacing HTTP, EWS, and OAB to access emails.  


Among other updates and upgrades, Microsoft Dynamic 365 is also getting updated with time. One of the biggest updates is the deprecation of Basic Authentication and replacing it with Modern Authentication. This update warrants that users currently using basic authentication switch to modern authentication. Moreover, this type of authentication is essential because the number of email phishing attacks is growing.  

In enterprise business applications, higher security is even more necessary. In this guide, we discussed the services affected due to the deprecation of basic authentication and shared the process to make a switch to modern authentication.  


1. How to know whether I am still using basic authentication?

You can use one of the three methods to check the type of authentication applicable on your system.  

  • Open the admin center Microsoft 365 and go to organization settings to find out which services are using basic authentication.  
  • Another method is to check Self-service diagnostic after logging in to the Microsoft 365 admin center. From here, click on Help and Support.  

On the Help and Support window, type “Diag: Enable Basic Auth in EXO” and select Run Tests.  

  • The third method is to check it through Azure AD. In this, the System Admin can review the sign-in report. This report will show the services which are using basic authentication.  
  • Lastly, the sign-in windows for services using basic authentication and modern authentication are different. The basic authentication window is: 

Connecting to

Plus, the modern authentication window is; 


2. Is there a way to re-enable basic authentication? 

Services and applications in Microsoft Dynamic 365 can be re-enabled with basic authentication. However, there are risks to the same, and it can be done until December 2022. From the first week of January 2023, Microsoft has decided to disable basic authentication permanently.