Problem with Exchange connection on linux

[gaborenok]

Hello Everyone!

I’m trying to run M365 DSC in a Linux Docker container and, surprisingly, I’ve managed to get most of it working so far. However, I’m running into an issue with the Exchange Online connection.

Does anyone have any suggestions on how to fix or work around this?

I can’t connect using the certificate thumbprint, because it looks for the certificate in the Windows Cert store, which isn’t available on Linux. Everything works fine when using CertificatePath and Password, except for ExchangeOnline — even though according to the documentation, it should be supported through DSC as well.

---

Export-M365DSCConfiguration -Components @("O365OrgSettings") -ApplicationId $ApplicationId
-CertificatePath $CertPath -CertificatePassword $Cred
-ApplicationSecret $ApplicationSecret -TenantId $TenantId
-Path $outputPath

---

This is the error that I am getting:

---

Exporting Microsoft 365 configuration for Components: O365OrgSettings

Authentication methods specified:

• Service Principal with Certificate Path
• Service Principal with Application Secret

Connecting to {ExchangeOnline}...❌
Exception: /ConfigCobraAssessment/Modules/MSCloudLoginAssistant/1.1.52/Workloads/ExchangeOnline.ps1:290
Line |
290 | throw 'No valid authentication type found'
| ~~~~~~~~~

---

I can connect to Exchange manually without any issues using this direct command:

Connect-ExchangeOnline -AppId $ApplicationId -CertificateFilePath $CertPath -CertificatePassword $CertSecurePassword -Organization "example.onmicrosoft.com"

Does anyone have any ideas or suggestions on how to make this work?

Thank you!

[FabienTschanz]

@gaborenok A quick clarifier: Microsoft365DSC is not properly supported on non-Windows platforms, so things might break. Still glad you tried and it seems to work.

Your issue comes from the fact that in the current implementation of MSCloudLoginAssistant, the ExchangeOnline workload does not work with either CertificatePath nor Application Secret. The current implemented ways are the following:

• Certificate Thumbprint
• Credentials
• (Managed) Identity
• Access Token

I'm not sure why Certificate Path as an authentication method wasn't yet implemented, but I guess because no other workload can use it. On the other side, Application Secret is not supported with ExchangeOnline. Hence, since both of these versions are not working, you receive the error No valid authentication type found.

What might work is to continue using the Client Secret, but also use the combination with an AccessToken. However, I have to admit that I did not test this and it might not work. But since Client Secret is supported by Graph and comes earlier than the AccessToken variant, it should be selected first, and since Client Secret is not supported for ExchangeOnline, it should select the AccessToken for it.

Connect-AzAccount # For application, use with --> -ApplicationId <clientId> -CertificatePath <path> -CertificatePassword <password>
$accessToken = (ConvertFrom-SecureString -SecureString (Get-AzAccessToken -ResourceUrl "https://outlook.office365.com/.default").Token -AsPlainText)
Export-M365DSCConfiguration -Components @("O365OrgSettings") -ApplicationId $ApplicationId -ApplicationSecret $ApplicationSecret -TenantId $TenantId -AccessToken $accessToken -Path $outputPath

For further information about what's going on, use -Verbose at the end. Hope that helps! Let us know how it goes, we're very curious. Thanks and good luck 👍

---

Edit: Just tested the thing. Unfortunately it's not that easy as I imagined. The current logic is to not try multiple different authentication mechanisms. If one is discovered (Client Secret is first), then this will be used. No retry mechanism with another mechanism is present. I'll try and implement something for ExchangeOnline, but no promises here. And I'll check if we can make the certificate store lookup independent from the operating system.

[FabienTschanz]

After further testing it's unfortunately (currently) not possible. The issue is as mentioned that Microsoft365DSC does not support providing multiple authentication methods at once and that on Linux, Certificate Thumbprint is not available for the ExchangeOnlineManagement module. This is a limitation of the module itself and not something we can fix.

If possible, try using a Managed Identity. Can be user assigned, doesn't have to be a system assigned Managed Identity. I don't know how you set up your container infrastructure, but it would be required to be set up in Azure and not on e.g. your local computer or on-premises infrastructure. That's another restriction.

It's very unfortunate that support is still lacking from the modules. I'll see if there's a possibility to use CertificatePath and load the certificate into memory for Connect-MgGraph to work. If yes, then the Client Secret is no longer necessary.

[gaborenok]

@FabienTschanz thanks a lot for your comments. Yes, I totally understand that this is not supported on Linux yet.

I tried each way that you mentioned as well today.

Unfortunately, I cannot give good news on the progress; the connection to Exchange Online is still not successful with either of the options.

With managed identity, I am getting the following error message:

---

VERBOSE: Module 'MSCloudLoginAssistant' with version '1.1.52' has been imported.
VERBOSE: All dependencies for module 'MSFT_O365OrgSettings' have been validated.
VERBOSE: Importing function 'Export-TargetResource'.
VERBOSE: Importing function 'Get-TargetResource'.
VERBOSE: Importing function 'Set-TargetResource'.
VERBOSE: Importing function 'Test-TargetResource'.
Connecting to {ExchangeOnline}...❌
OperationStopped: Value cannot be null. (Parameter 'Organization cannot be null for Managed
Identity based connections.')

---

I do not really understand the issue because I cannot give Organization parameter at all. And I understand that this is the error from the Exchange module.

Export-M365DSCConfiguration -Components @("O365OrgSettings") -ManagedIdentity
-TenantId $TenantId `
-Path $outputPath

Any ideas?

[FabienTschanz]

We have a release prepared (1.25.1112.1) which will be available soon. Please try again with this version and the updated dependencies, we fixed a couple of things in the MSCloudLoginAssistant. Maybe it works afterwards. But I'll try and trace where the issue comes from and add that to the list of things to fix that I have already prepared.

[gaborenok]

Thank you! I managed to do it with an access token, and for now, I will use separate DSC exports and then join them. I will let you know how it went.

$Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($CertPath, $CertSecurePassword)
Write-Output "Certificate loaded successfully"

try {
$ExchangeToken = Get-MsalToken -ClientId $ApplicationId
-TenantId $TenantId -ClientCertificate $Cert
-Scopes "https://outlook.office365.com/.default"
} catch {
Write-Warning "Could not get access token: $_"
}
$ExchangeAccessToken = $ExchangeToken.AccessToken

Export-M365DSCConfiguration -Components @("O365OrgSettings") -AccessToken $ExchangeAccessToken
-TenantId $TenantId `
-Path $outputPath

If you have any other suggestions, I am happy to hear them.

[FabienTschanz]

Nicely done, looking forward to it. I'll keep you posted with my experiments.