Can not connect to Office 365 / Exchange Online with PowerShell #5561
Description
I can not connect to Office 365 / Exchange Online with PowerShell.
Apparently others can with the latest version of push, but it is not working for me on either macOS 10.12 or 10.13 with pwsh 6.0.0-rc
I get an error creating the New-PSSession. Depending on the exact syntax of the command I'm using, it either says New-PSSession : This parameter set requires WSMan, and no support WSMan client library was found, or PowerShell quits with an unhandled exception and abort trap 6.
Steps to reproduce
Install PowerShell 6.0.0-rc on macOS 10.12 or 10.13.
Use Get-Credential to get an Office 365 administrator credential and then use New-PSSession to create a new session.
[kai@blackmac ~]$ pwsh
PowerShell v6.0.0-rc
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/pscore6-docs
Type 'help' to get help.
PS /Users/kai> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-rc
PSEdition Core
GitCommitId v6.0.0-rc
OS Darwin 16.7.0 Darwin Kernel Version 16.7.0: T...
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
PS /Users/kai> $UserCredential = Get-Credential
PowerShell credential request
Enter your credentials.
User: admin@example.com
Password for user admin@example.com: ***********
PS /usr/local/microsoft> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
New-PSSession : This parameter set requires WSMan, and no supported WSMan client library was found. WSMan is either not installed or unavailable for this system.
At line:1 char:12
+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange -Conne ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (:) [New-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : System.Management.Automation.Remoting.PSRemotingDataStructureException,Microsoft.PowerShell.Commands.NewPSSessionCommand
PS /Users/kai> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid -Credential $UserCredential -Authentication Basic -AllowRedirection
An error has occurred that was not properly handled. Additional information is shown below. The PowerShell process will exit.
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at System.Management.Automation.Remoting.PrioritySendDataCollection.Clear()
at System.Management.Automation.Remoting.Client.BaseClientTransportManager.CloseAsync()
at System.Management.Automation.Remoting.Client.WSManClientSessionTransportManager.CloseAsync()
at System.Management.Automation.Remoting.Client.BaseClientTransportManager.Finalize()
Abort trap: 6
[kai@blackmac ~]$ You will note from the prompt in the last line above that it's dropped me back into the bash shell.
Expected behavior
It is expected that New-PSSession will work on macOS
Actual behavior
Depending on the precise syntax of the command, New-PSSession either returns an error message:
New-PSSession : This parameter set requires WSMan, and no supported WSMan client library was found
Or, New-PSSession has an unhandled exception and PowerShell quits with abort trap 6.
The differences in the syntax are with the ConnectionUri - whether or not there is a trailing slash on the uri seems to make the difference. With a trailing slash, I get the error about WSMan missing. Without the trailing slash, the PowerShell session aborts.
With trailing slash:
PS /Users/kai> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
New-PSSession : This parameter set requires WSMan, and no supported WSMan client library was found. WSMan is either not installed or unavailable for this system.
At line:1 char:12
+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange -Conne ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (:) [New-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : System.Management.Automation.Remoting.PSRemotingDataStructureException,Microsoft.PowerShell.Commands.NewPSSessionCommandWithout trailing slash:
PS /Users/kai> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid -Credential $UserCredential -Authentication Basic -AllowRedirection
An error has occurred that was not properly handled. Additional information is shown below. The PowerShell process will exit.
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at System.Management.Automation.Remoting.PrioritySendDataCollection.Clear()
at System.Management.Automation.Remoting.Client.BaseClientTransportManager.CloseAsync()
at System.Management.Automation.Remoting.Client.WSManClientSessionTransportManager.CloseAsync()
at System.Management.Automation.Remoting.Client.BaseClientTransportManager.Finalize()
Abort trap: 6Environment data
PS /Users/kai> $PSVersionTable Name Value
---- -----
PSVersion 6.0.0-rc
PSEdition Core
GitCommitId v6.0.0-rc
OS Darwin 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT ...
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0 Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Participants
Activity
SteveL-MSFT commentedon Nov 29, 2017
This is working for me on 10.13.1. Can you confirm that in $PSHome you have
libpsrpclient.dylib?kai-h commentedon Nov 29, 2017
SteveL-MSFT commentedon Nov 29, 2017
@kai-h you have the right library with the right file size and permissions. Is DYLD_LIBRARY_PATH defined? What is the output of
$env:DYLD_LIBRARY_PATH?kai-h commentedon Nov 29, 2017
It's undefined.
SteveL-MSFT commentedon Nov 29, 2017
What does
[System.Environment]::Is64BitProcessreturn?kai-h commentedon Nov 29, 2017
SteveL-MSFT commentedon Nov 29, 2017
@kai-h try (in the terminal before starting pwsh):
kai-h commentedon Nov 29, 2017
Thank you for your persistence with this. I'm still getting the same error though.
kai-h commentedon Nov 29, 2017
I'd like to confirm that I can successfully connect to Office 365 from PowerShell hosted on an Azure Ubuntu virtual machine, using the exact same details as I'm trying on the Mac.
kai-h commentedon Nov 29, 2017
What I'm going to do in order to remove any possible issues with me having tweaked something on my Mac that is conflicting with this is set up a clean install of macOS 10.12 and then a fresh install of PowerShell 6.0.0-rc and test if it works tonight.
iSazonov commentedon Nov 29, 2017
It is dup #3606
kai-h commentedon Nov 29, 2017
Issue #3606 is kind-of a dup, but they also saw the error which I haven't seen occur in my testing.
kai-h commentedon Nov 29, 2017
I have been able to reproduce this on a clean install of macOS 10.12.6 and a clean install of PowerShell 6.0.0-rc. Everything is with default settings, new admin account created on first boot and no settings changed for the Terminal app.
kai-h commentedon Nov 29, 2017
Here are the results on a clean 10.12.6 install
77 remaining items
luckman212 commentedon Dec 17, 2020
Just to be sure I'm not missing something, I heard it was possible to run a Docker instance on macOS and spin up a PowerShell 7 core using mcr.microsoft.com/powershell — but when I tried that I hit the same roadblock. I believe this would only work for the Windows-based images, correct? So we're still stuck in the same boat ⛵
kai-h commentedon Dec 17, 2020
I've written up some instructions that work around these issues and are confirmed working with the latest version of PowerShell (I've tested with 7.1.0 Release) and any recent version of macOS (I've tested on macOS 11 Big Sur).
https://automatica.com.au/2020/12/installing-powershell-on-macos-for-remote-administration-of-microsoft-365/
Basically, install PowerShell via the pkg installer on GitHub. Then install MacPorts and with MacPorts install OpenSSL 1.0
sudo port install openssl10. Finally, symlink /opt/local/lib/openssl-1.0 to /usr/local/opt/openssl/lib
I am yet to test, but I believe this will NOT work on any of the new M1 arm64 architecture Macs as the PowerShell binaries are x86_64 yet the OpenSSL libraries installed by MacPorts will be arm64. I'm sure there is a way to specify that MacPorts installs the x86_64 version of a library on an arm64 machine, but I don't know how to.
Despite the fact that this works, it shouldn't need to be done.
PowerShell needs to work with up-to-date versions of OpenSSL. It should also NOT have hardcoded paths for support libraries. It should not require old, and known insecure, versions of third-party libraries.
All this is going to be a moot point in due course as the Mac version of PowerShell will not authenticate to MS365 with modern authentication, it only supports legacy authentication. I have been unable to get an answer about, or even find out who is responsible for, modern authentication in PowerShell on non-Windows platforms.
luckman212 commentedon Dec 17, 2020
@kai-h That's a nice writeup and it's a noble effort, but honestly - if anyone has tenants left on 365 that DON'T use MFA then they're being foolish at best and negligent at worst. I strictly require it across the tenants I engage with. So not being able to connect with modern auth is a non-starter unfortunately.
I hope MS stops finger pointing and just finds a way to fix this. Is it really that much of an edge case to want to manage 365 from a Mac these days?
kai-h commentedon Dec 17, 2020
I hear you. I strongly advise my clients to use MFA for all of their user accounts, even if it is not turned on tenancy-wide.
It is frustrating that Microsoft have invested so much effort into making PowerShell work on non-Windows platforms, yet what is likely the most common use case, administering Office 365, Exchange Online and Azure, simply doesn't work out of the box, and can not work with Modern Authentication. So near, yet so far.
I'm sure there may be some other edge cases for using PowerShell on other platforms, and it's an excellent exercise in good coding practice to ensure that a big project like this works on other platforms, but in terms of actually using it, I can't see anyone administering a fleet of Macs, or Linux boxes, with PowerShell. It's here so we can talk to Office 365 and Azure.
jborean93 commentedon Dec 17, 2020
@kai-h you shouldn't need to install the older OpenSSL if you use my fork. It's compiled against the newer OpenSSL version (1.1.x) distributed by Homebrew and I've been meaning to see if it will be possible to use the LibreSSL version that comes stock standard. I haven't actually tested it against Big Sur (or M1) but I would assume it would just need to be recompiled and that's it.
kai-h commentedon Dec 17, 2020
Thank you @jborean93, I'll have to give that a go. Why Microsoft can't do this is beyond me.
Do you know if it still searches for the OpenSSL library at a fixed path /usr/local/opt/openssl/lib, or does it use LD_LIBRARY_PATH to find the correct library?
jborean93 commentedon Dec 17, 2020
I honestly can't blame them even if I wished the situation was better. The mi library was maintained by a separate team and is based on C so requires a completely different skill set to maintain and support. From experience the code there is quite complex and not something easy to maintain. Once that team dropped support for macOS or PowerShell then the PowerShell team had little choice. What would be nice is if the WSMan code could be implemented in pure .NET and maintained by them as a lot of the fundamental work is already in place in .NET but this is also not a trivial task to achieve. So in the end I decided to just fork the library and fix up the stuff I could. Things that I fixed with this fork
kinit, no need to use-Credentialon your connections if you already have a token-Authentication Negotiateto act like WindowsPeople are free to use it but it isn't affiliated with the PowerShell team in any way.
Before I continue, all this is relevant only to macOS, for Linux this info does not apply.
It's still hardcoded to
/usr/local/opt/openssl@1.1/lib/lib*.dylibbut it is at least for OpenSSL 1.1 and not 1.0. The main reason why it is hardcoded is becauselibsslandlibcryptoare not in any of the default library paths for macOS/usr/lib,/usr/local/lib, or~/.lib. When you have a dynamically linked lib with@rpath/lib.dylibon macOS it will search in those default paths or ones specified byLD_LIBRARY_PATH(strong caveats with this env var on macOS). So a user who uses this library and has OpenSSL 1.1.x installed from Homebrew will still fail to load the library leading to a poor user experience. By hardcoding the path to the version installed by Homebrew we can at least have a works out of the box situation as long as the dependencies have been met.In saying all that, if you really want to rely on the environment or use a different path for your specific setup you can change them yourself. To do this you need to run
install_name_tool -change <original path> <new path> <lib.dylib path>. For example here are the paths that my fork is set to by defaultIf I wanted to change the libssl and libcrypto library to scan from rpath I would run
install_name_tool -change \ /usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib \ @rpath/libssl.1.1.dylib \ /usr/local/microsoft/powershell/7/libmi.dylib install_name_tool -change \ /usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib \ @rpath/libcrypto.1.1.dylib \ /usr/local/microsoft/powershell/7/libmi.dylibYou would need to run this as sudo and I highly recommend you make a backup of the libraries before you change them in case something breaks. You also want to make sure that the library you are linking to is actually compatible. You won't be able to use
install_name_toolto change thelibssl.1.0.dylibto uselibssl.1.1.dylibas they are not API and ABI compatible.I've been meaning to look into linking against the builtin LibreSSL libs that macOS ships with but I would be concerned it will start to lag behind just like the shipped OpenSSL version that Apple had before they swapped to LibreSSL. For now relying on a newer version from homebrew gives us a new library that continues to be updated by homebrew which follows what other Linux distributions offer.
iSazonov commentedon Dec 18, 2020
This is an obsessive situation for the past few years, but this is a fact, possibly the result of internal political wars. :-)
It seems MSFT PowerShell team has decided to convert Remoting to a subsystem, which will open up the possibility of creating alternative Remoting implementations. If this happens, perhaps we will have time in next milestone to get a new implementation based on .Net WebSockets (?) that will work on all platforms without external dependencies.
BichengWang commentedon Dec 24, 2020
Same issue.
suoko commentedon Feb 3, 2021
So in the end, it's not possible to connect to exchange online via linux powershell if MFA is enable yet, right ?
kai-h commentedon Feb 3, 2021
As far as I know, no - not on a non-Windows platform.
jborean93 commentedon Feb 3, 2021
With the one provided with PowerShell there's a good chance it won't work but it really depends on the distribution, i.e. macOS is very likely not to work. With my forked version you definitely can. It's one of the integration scenarios I test out when creating a new release https://github.com/jborean93/omi/blob/67fb46865b76ecd5d89a990fdedeb32cd219143f/libmi.tests.ps1#L470-L518.
suoko commentedon Feb 8, 2021
@jborean93
So you think this script can be tweaked to connect via lin ?
https://o365reports.com/2019/10/05/connect-all-office-365-services-powershell/