Back to blog

Connecting to Office 365 using PowerShell and Modern Authentication

Oct 18, 2017 by Vasil Michev

A fairly recent improvement is the option to connect to a PowerShell session via multi-factor authentication (MFA). In other words, the relevant PowerShell modules now support modern authentication (sometimes referenced also as ADAL, based on the name of the libraries used). In this post, we will explore how this process works.

Connecting PowerShell to Office 365 via Modern Authentication

Once a version that supports modern authentication is installed, all you need to do is issue the relevant cmdlet, either Connect-MsolService or Connect-AzureAD. You should then be presented with this dialog:

Enter your username, password and – if prompted – perform any additional verification methods configured. This verification includes the Azure MFA phone-based authentication, or any other form of MFA that might be configured in federated scenarios (certificate, token, PIN, etc.).

It’s important to note that you should be careful when passing parameters to the Connect-* cmdlets. Doing so might bypass the modern authentication process, and log you in via the legacy auth method. This is not necessarily bad, but you will not be able to benefit from the added security, and in some cases the login attempt might fail.

Connecting PowerShell to Exchange Online via Modern Authentication

When it comes to Exchange Online remote PowerShell, things are a bit more complicated. In order to take advantage of modern authentication, you will need to download and install a new, ADAL-enabled ExO PowerShell module. This can be done by logging into the Exchange Admin Center in Office 365, navigating to the Hybrid tab and pressing the Configure button as shown below:

Alternatively, you can download the module from here. In both cases, make sure you use a browser that supports running/installing ClickOnce applications, and you have at least version 4.5 of the .NET framework installed. For additional troubleshooting steps, you can refer to this support article.

Once the module has been successfully installed, you will find the Microsoft Exchange Online Powershell Module shortcut on your desktop. Clicking it will launch a new PowerShell window with the required module loaded:

Then, simply follow the instructions. To connect to Exchange Online PowerShell, you can use the Connect-EXOPSSession cmdlet, with or without the –UserPrincipalName parameter. You will be greeted by the familiar login dialog:

Once you provide credentials and perform any additional strong authentication challenges, behind the scenes the module will create a new remote session to Exchange Online, and fetch the cmdlets you have been granted permission to. The session behaves just like any “legacy” session (including the occasional session breaking because of timeouts or other connectivity issues).

Speaking of endpoints, if you are using one of the sovereign clouds (China or Germany), you will have to provide some additional parameters. Details can be found in the official documentation here.

Connecting PowerShell to the Security and Compliance Center via Modern Authentication

As you might have noticed in the above screenshots, the ADAL-enabled Exchange Online PowerShell module can also be used to connect to the Security and Compliance Center. The process is very similar to connecting to Exchange Online – all you need to do is invoke the Connect-IPPSSession cmdlet and enter credentials. The module will create the session and import the relevant cmdlets.

Unfortunately, if you want to connect to both Exchange Online and the Security and Compliance Center, you will have to enter credentials and perform MFA challenges twice, as there is no token sharing between the two.
As with the previous scenario, if you are using Office 365 in one of the sovereign clouds, you will need to specify additional parameters when invoking the Connect-IPPSSession cmdlet. Please refer to the official documentation here.

Lastly, some people prefer to use their custom “login” scripts. If you want to incorporate the ADAL-enabled bits in your script, a simple method is to load and reuse them. To do so, you will first need to find the install location, which might prove tricky with the ClickOnce model, as such apps are pushed under the local profile. The following PowerShell snippet will help you with that:

$targetdir = (dir $env:LOCALAPPDATA”\Apps\2.0\” -Include CreateExoPSSession.ps1,Microsoft.Exchange.Management.ExoPowershellModule.dll -Recurse | Group Directory | ? {$_.Count -eq 2}).Values | sort LastWriteTime -Descending | select -First 1 | select -ExpandProperty FullName

The code looks under your user profile, namely the “AppData\Local\Apps\2.0” directory, and locates any folders in which both the CreateExoPSSession.ps1 and Microsoft.Exchange.Management.ExoPowershellModule.dll files are found. As you can have multiple such folders (one of the perks of the ClickOnce model is that you have several versions installed at the same time), the results are then sorted based on the last modified date and the most recent folder is returned.

You are now ready to import the module:

Import-Module $targetdir\CreateExoPSSession.ps1

Once this is done, you can use the Connect-EXOPSSession cmdlet within your own scripts.