Category Archives: Office365

Microsoft Teams without an Office 365 license

Now with all this Working from Home going on you might want to use Teams, even if you don’t have a valid Office 365 license that contains the Teams software. For this Microsoft has introduced the Microsoft Teams Exploratory license. This Exploratory license replaces the previous Microsoft Commercial Cloud Trial.

When a user without a (Teams) license logs on for the first time to Teams via https://teams.microsoft.com he must login (of course) and the standard logon screen is shown:

login to teams

When logged on for a couple of seconds a license error is shown, and a minute later the user is successfully logged on to Teams, “without” a license:

Teams first time

I have written “without” in quotes, when you navigate to the license portal you will see that the Microsoft Exploratory License is added and one license is (automatically) assigned:

Teams Exploratory License

This one user is the user that was logged in to Teams in the previous step.

The Microsoft Teams Exploratory License is for users to self-assign a license the first time they logon to the service. Typically, this self-assign option is enabled in your tenant, but that might not always be the case. Check the Office 365 admin portal and select Settings | Org settings | User owned apps and services:

User owned apps and services

Open this and check if the Let users access the Office Store and Let users install trial apps and services are checked. Of course, if you do not want your users to do this, uncheck the options.

But besides the Microsoft Teams license, there’s a lot more in the Exploratory license, like an Exchange Online P1, Forms, Planner, Stream etc. available in this license:

Teams Exploratory License Apps

The Microsoft Teams Exploratory license is available at no cost until your renewal on or after January 2021. So, at the time of writing this is at least 7 months away.

Of course you can also integrate the Teams license with an on-premises Exchange 2016 environment, for this please check my previous blogpost Microsoft Teams and Exchange 2016.

More information

New Exchange Online PowerShell v2

When using PowerShell with Exchange Online you can use the ‘good old traditional’ way to connect to Exchange Online:

$ExCred = Get-Credential 
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $ExCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

This is not a recommended way to connect to Exchange Online using your tenant admin account, it uses basic authentication (will be decommissioned in 2021) and MFA (number one prerequisite for tenant admin security!) is not possible.

The second option is the Exchange Online Remote PowerShell Module which you can download from the Exchange Online Admin Center (use Internet Explorer for this download!) as shown in the following screenshot:

Exchange Online PowerShell Module

This is a separate PowerShell module you can start and use the Connect-EXOPSSession command to connect to Exchange Online. This PowerShell module users Modern Authentication and supports Multi-Factor Authentication.

The latest (and newest) option is the Exchange Online PowerShell V2 module. This module works far more efficient with large datasets than the previous PowerShell modules for Exchange Online. It also supports Modern Authentication and Multi-Factor Authentication.

To install the Exchange Online PowerShell V2 module you first have to install the PowerShellGet module using the Install-Module PowershellGet command:

Install-Module PowershellGet

Followed by the Install-Module -Name ExchangeOnlineManagement command:

Install-Module ExchangeOnlineManagement

When installed you can use the Connect-ExchangeOnline command to connect to Exchange Online. When MFA for your admin account is configured it will automatically use it:

Connect-ExchangeOnline

The differences between V1 and V2 are clearly visible in the commands. All V2 commands contain EXO, like:

  • Get-Mailbox vs Get-EXOMailbox
  • Get-Recipient vs Get-EXORecipient
  • Get-MailboxStatistics vs Get-EXOMailboxStatistics
  • Get-CASMailbox vs Get-EXOCASMailbox

This means that all scripts you have written for use with Exchange Online need to be changed to reflect the V2 commands.

For a complete overview you can use the Get-Command *EXO* to retrieve all PowerShell commands that contain EXO (still very limited 🙂 ):

Get-Command EXO

The Exchange Online PowerShell V2 module is still in preview, the current version is 0.3582.0 which you can check using the Get-Module ExchangeOnlineManagement command:

Get-Module ExchangeOnlineManagement

The Exchange Online PowerShell v2 module is a work in progress, but it the future of PowerShell in Exchange Online, so you should keep an eye on this development.

More Information

Use the Exchange Online PowerShell V2 module – https://docs.microsoft.com/en-us/powershell/exchange/exchange-online/exchange-online-powershell-v2/exchange-online-powershell-v2?view=exchange-ps

Microsoft Teams and Exchange 2016

Microsoft Teams works best when your mailbox is in Exchange Online, and you have a license for SharePoint Online, and you have OneDrive for Business enabled.

When you have your mailbox in Exchange on-premises your options are limited, you have basic Teams functionality like audio/video and files, but that’s basically it. Not a trace of the calendar or the option to manage meetings in Teams. This is what ‘cloud partners’ have been telling me for a long time: “no, you must migrate your mailbox to Exchange Online” (and we can help you with that I was they were thinking…)

Teams with Exchange on-premises

But, if you have Exchange 2016 CU3 or higher things get better (I’m sorry if you are still running Exchange 2010). To enable the integration of Teams with on-premises Exchange 2016 you need to configure OAuth in your on-premises environment as outlined in my previous blog, and assuming you have Exchange hybrid configured of course.

When you have OAuth configured, Teams can access the on-premises mailbox on behalf of the user that’s logged on in Teams, making it possible to retrieve the user’s calendar. After configuring OAuth and without any additional configuration in Teams the user’s on-premises calendar (here in Exchange 2019) automagically appears:

Teams with Exchange on-premises OAuth

In the Teams client this is a view of your calendar, and using the new meeting option you can create new Teams meetings, invite people, set recurrence, select a channel etc. Invites are sent to other recipients using the regular Exchange process, and when accepted a response is sent (or not) back to your inbox. I never knew this was possible, but this is cool stuff.

Teams with Exchange on-premises new meeting

Integrating the calendar into Teams is a nice addition and it can help users with their daily productivity task. From a compliance perspective things are a bit different. Chats for example are not stored in the user’s mailbox, this is only possible for mailboxes in Exchange Online. The process responsible for copying Teams chat data from the Azure storage (outside of Office 365) simply cannot access the folder in the user’s mailbox.

But, for on-premises calendar integration in your Teams environment this is very nice.

More information

How Exchange and Microsoft Teams interact – https://docs.microsoft.com/en-us/microsoftteams/exchange-teams-interact

Configure OAuth authentication between Exchange and Exchange Online organizations – https://docs.microsoft.com/en-us/exchange/configure-oauth-authentication-between-exchange-and-exchange-online-organizations-exchange-2013-help

 

Basic Authentication in Office 365 Part II

Update. Microsoft has changed their plans due to the Covid-19 crisis going on at the moment. Support for Basic Authentication in Exchange Online has been postponed to the second half of 2021 according to their blogpost on Basic Authentication and Exchange Online – April 2020 Update.

There are a few things to be aware of. For new tenants, Basic Authentication is already turned off, for older tenants it is still turned on. However, if Basic Authentication has not been used in a tenant it will be turned off as well. This will start upcoming October.

In my previous blogpost I explained more about basic and modern authentication, how they work and how to identify which method your outlook client is using. In this blogpost I will explain more about monitoring basic authentication to find out which clients are currently still using basic authentication in your Office 365 environment. I will continue with how to disable basic authentication and how to test what might happen.

Monitoring Basic Authentication

In my previous blogpost I explained a bit more about basic authentication and how to identify it, and the working of modern authentication.

The next step is to identify how many users and application are actually using basic authentication in your Office 365 environment. After all, these are the users that are impacted when Microsoft stops basic authentication.

To identify this, logon to the Azure Active Directory Portal (https://aad.portal.azure.com) and select sign-ins (under Monitoring). There you will see an overview of all sign-ins in Azure AD, successful and failed, for all clients, all services and all locations. An example is shown in the following screenshot (click to enlarge):

This shows all logins in Azure AD, for all aplications and services, failed and successful. You can use the Add Filters button to narrow down the information, in this blogpost to show only information regarding Basic Authentication.

To do this, click Add Filter | Select Client App | Click Apply

Click on “Client App: None Selected” and select all options except Browser and Mobile Apps and Desktop Clients as shown in the following screenshot (click to enlarge):

Modern Authentication Clients

Note. Updated the screenshot on April 6, 2020. Microsoft made a nice GUI enhancement here to easily identify different clients (modern vs legacy).

Now an overview will be shown of all basic authentication attempts in your environment. When you select one entry it will show additional details, including the client application, the username and the the user agent (which identifies the client app) as shown in the following screenshot (click to enlarge):

Another interesting thing is that you can identify where all failed basic authentication attempts are coming from. Add a filter Status | Failure and you will see only failed attempts. Some are legitimate (typo when entering password) but most of them are just brute force attacks. The following screenshot shows attempts coming from Russia, Thailand and New Caledonia, located where we don’t have offices. You can also see that the attempt is coming from a script (User agent CBAInPROD) and that it’s using IMAP4 (which is disabled for all mailboxes). This is one reason why you want to disable basic authentication in your tenant. Click to enlarge:

This is an easy way to identify mobile clients that use ActiveSync as a protocol and thus are using basic authentication. Apple iOS native mail client support OAuth2 since iOS11, so all recent iPhones are using modern authentication. For the Android native mail client things are different. The native Gmail client support OAuth2 but cannot be used of course with Office 365. Most other mail clients do not support OAuth2 yet, so these are using basic authentication and will run into issues when Microsoft stops basic authentication. In other words, these clients will stop working. Change the Client App filter to Exchange ActiveSync only and remove the Status | Failure filter. It will show a list of mobile users that use basic authentication as shown in the following screenshot (username is removed for privacy reasons) (click to enlarge):

Note. Outlook for iOS and Outlook for Android are using OAth2 so these will continue to work.

So, using the filtering options on the sign-in page in the Azure AD portal you can identify which clients are still using basic authentication when accessing Office 365 services (and thus which clients are impacted when basic authentication is stopped).

Disabling basic authentication

It is possible to disable basic authentication in your Office 365 by creating an Authentication Policy and apply this policy to users. Once applied they can no longer use basic authentication to logon to any Office 365 service. To create a new Authentication Policy use the following command in Exchange Online PowerShell:

[PS] C:\> New-AuthenticationPolicy -Name “Block Basic Authentication”

To add a user to the policy and effectively block basic authentication for this user you can use the following command in Exchange Online PowerShell:

[PS] C:\> Set-User -Identity j.wesselius@exchangelabs.nl -AuthenticationPolicy “Block Basic Authentication”

It will take up to 24 hours before this policy is effective. To take the policy effect (almost immediately, or at least within 30 minutes) you can use the following command:

[PS] C:\> Set-User -Identity j.wesselius@exchangelabs.nl -AuthenticationPolicy “Block Basic Authentication” -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

To remove a user from an authentication policy you can use $Null for the authentication policy:

[PS] C:\> Set-User -Identity j.wesselius@exchangelabs.nl -AuthenticationPolicy $Null

When you have a number of users added to this authentication policy you can start testing with various clients and create a table with clients and scenarios, like the table below:

Client Results
Office 2010 Stops working (keeps asking for password)
Office 2013/2016 Continues to work (was already using Modern Authentication)
Outlook 2010 on-premises mailbox, cross-premises free/busy Continues to work, but need further investigation (note 1)
Outlook 2013/2016 on-premises mailbox, cross-premises free/busy Continues to work
iPhone 8, iOS13, native mailclient Continues to work
iPhone 8, iOS13, Outlook for iOS Continues to work
Samsung A10, Android 9, native Email client 6.1.11.6 Stops working
Samsung A10, Android 9, AquaMail (by MobiSystems, supports OAuth) Continues to work (note 2)
Samsung A10, Android 9, Outlook for Android Continues to work
Exchange Online PowerShell New-PSSession Stops working (note 3)
Exchange Online PowerShell module Continues to work
Exchange PowerShell V2 Continues to work
POP3 Clients TBD
IMAP4 Clients TBD

Note 1. In this scenario an Outlook client is using an on-premises mailbox but tries to retrieve free/busy information from a mailbox that’s in Exchange Online. Both accounts have basic authentication disabled in Azure AD.

Note 2. The native mailclient in Android 9 (on my Samsung A10) only supports basic authentication. This is not a device limitation but an application limitation. AquaMail (from MobiSystems) for example does support OAuth and keeps working when basic authentication is disabled. AquaMail however is not a free application but a subscription based application.

Note 3. It is possible to connect to Exchange Online as shown in line 9 of the table using the following method:

$ExCred = Get-Credential TenantAdminAccount
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $ExCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

This is using basic authentication and will stop working. However, you should not use this way of working anyway because it does not support MFA, which is a recommended best practice for admin accounts! For more information please check Multi Factor Authentication MFA in Office 365 for admin accounts.

Summary

In the previous two blogposts I tried to explain a bit more about basic and modern authentication, and what might happen when Microsoft ends support for basic authentication in Exchange Online next October.

For sure, things will break when connecting to Exchange Online. The most obvious is Outlook 2010 which won’t connect anymore. Native mobile clients that do not support oAuth2 (common in Android mail apps, but also older iPhones) stop working too. If you don’t act now you will be in a lot of trouble when Microsoft makes the change.

For now, start testing using the options I explained in this second blogpost. Create your own list of apps and services that use basic authentication and start testing with an authentication policy that blocks basic authentication. That’s the only way to prepare for this major (mega major) upcoming change. But in the end, we will all benefit from a security point of view.

More information

Basic Authentication in Office 365 Part I

 

Update. Microsoft has changed their plans due to the Covid-19 crisis going on at the moment. Support for Basic Authentication in Exchange Online has been postponed to the second half of 2021 according to their blogpost on Basic Authentication and Exchange Online – April 2020 Update.

There are a few things to be aware of. For new tenants, Basic Authentication is already turned off, for older tenants it is still turned on. However, if Basic Authentication has not been used in a tenant it will be turned off as well. This will start upcoming October.

Microsoft will stop support for basic authentication in October 2020 as outlined in the following blogpost: Basic Auth and Exchange Online – February 2020 Update. By doing this Microsoft increases security in (especially) Exchange Online, since basic authentication is a perfect attack vector for malicious users.

But what does it mean? Clients that use Exchange Web Services (EWS), ActiveSync, PowerShell, POP3 and IMAP4 and authenticate using basic authentication will stop working. Which clients are we talking about? Basic authentication only stops for Exchange Online and not for Exchange on-premises, but what happens when you are using a hybrid scenario? Of using Outlook for iOS in combination with an on-premises mailbox.

In this blogpost I’ll try to dive a bit deeper into authentication and explain what is going to happen.

Basic Authentication

Basic Authentication is one of the oldest ways of authenticating in any web application. You access an application, a dialog box is presented, you enter your credentials and the credentials are sent (in clear text) across the wire. To improve security typically an SSL connection is used, so the connection between the client and the server is encrypted.

For Exchange Online this means the (Outlook) client sends it credentials in clear text to Exchange Online, and Exchange Online authenticates against Azure AD as shown in the following screenshot:

When using ADFS, basic authentication is not very different. The client authenticates and sends the credentials in clear text to Exchange Online, and Exchange Online takes care of the remaining communication using ADFS and the on-premises Domain Controllers (step 2 and 3 in the following screenshot):

Important to note is that the client here still use basic authentication.

So what clients are using basic authentication? Outlook 2010 is the most common, but also lots of ActiveSync clients, POP3 and IMAP4 clients, PowerShell and Exchange Web Services (scripts and tools!) are still using basic authentication.

I leave it up to your imagination what will happen when Microsoft stops support for basic authentication (step 1 in the screenshots above) this October!

Modern Authentication

Modern authentication is a token-based authentication mechanism and as such it has similarities with federation services. On IT Dev Connections 2017 in San Francisco I did a presentation on this subject. The following screenshot is an animated slide from the presentation showing the authentication flow between a client, Exchange Online, Azure AD and the on-premises Domain Controller:

Modern Authentication is based on the OAuth2 framework. When using OAuth2, you grant permissions to an application (‘consent’) to contact the server on your behalf. The client contacts the server the first time and you enter your credentials in a web frame, this is a server-based web frame and when the credentials are entered two tokens are generated:

  • Access token, which is used to access various services.
  • Refresh token, which is used to renew the access token when it is about to expire.

This is shown in the following image:

Source: Authorize access to Azure Active Directory web applications using the OAuth 2.0 code grant flow.

The access token is constantly renewed (and thus no need to re-authenticate manually) until it cannot be renewed, for example when the password expires, the account is blocked (the access token is revoked) or when a Conditional Access policy can no longer be applied. In all these scenarios access to the service is denied.

Outlook 2013 and higher support Modern Authentication. In Outlook 2013 you had to set some registry keys, but in Outlook 2016 and higher it is enabled by default.

The way to identify if you are using modern authentication is the HTML based login screen which look like this:

While the basic authentication (in Exchange 2016, but similar in Outlook 2010) looks like:

Another way to identify Modern Authentication is to use the connection status in Outlook:

When you see ‘Bearer’ (coming from OAuth bearer token) Outlook is using Modern Authentication, if you see ‘Clear’ then basic authentication is used by Outlook.

Summary

In this first part I have tried to explain the difference between basic authentication and modern authentication, how modern authentication works and how to identify which authentication method your Outlook client is using.

In my next blog (Part II) I will explain more about how to monitor basic authentication and how to start testing what happens when disabling basic authentication.