Conflicts with the AzureRM module which breaks Azure cmdlets

[autonomousit]

Overview

We've identified a problem when using the Loadmaster API cmdlets in conjunction with the AzureRM module.

The connections to Azure will be permanently closed once you call a Loadmaster cmdlet which means all Azure cmdlets called after that will fail with an HTTPRequestException until you create a new session.

Get-AzureRmVm : An error occurred while sending the request.
At C:\Users\MyUser\Documents\myscript.ps1:159 char:7
+ $xxx = Get-AzureRmVm
+        ~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Get-AzureRmVM], HttpRequestException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Compute.GetAzureVMCommand

This appears to be due to a conflict in how the 2 modules try to set certain [System.Net.ServicePointManager] values.

The biggest issue is related to the private helper function CreateLmHttpsRequest setting [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true } . This is required in order to allow our cmdlets to connect to the default self-signed certificate used by the Loadmaster which is un-trusted by the Administrative PC out of the box. As a side effect the Azure connection is closed & doesn't get re-established.

We also have some evidence that a similar problem will occur with AWS cmdlets but haven't confirmed this in detail yet.

A more minor problem is that both set the [System.Net.ServicePointManager]::SecurityProtocol value to different things:
Azure [System.Net.ServicePointManager]::SecurityProtocol = 'Ssl3','Tls'
Loadmaster [System.Net.ServicePointManager]::SecurityProtocol = 'Tls11','Tls12'

Quick & Dirty Workaround

Calling [System.Net.ServicePointManager]::ServerCertificateValidationCallback = $null will allow Azure connections to be re-established however this needs to be toggled EVERY time after a block of Loadmaster cmdlets is used so while it offers an immediate workaround it isn't an actual solution

Possible Solutions

The simplest solution from a code perspective is to just remove these calls from the Loadmaster wrapper completely & require Administrators to first configure their Loadmasters with a Trusted Certificate or to trust the Loadmasters Certificate on their Admin PC however this would prevent automated provisioning as you'd first need to manually provision the Loadmaster then download or swap-out the Administrative Certificate.

We've identified a possible solution that will prevent the Loadmaster module from breaking Azure cmdlets as well as connect to our API using an un-trusted certificate however we'd like feedback, especially from Enterprise Users, as we have concerns on whether this would breach any common security requirements

add-type @"
    using System.Net;
    using System.Security.Cryptography.X509Certificates;
    public class TrustAllCertsPolicy : ICertificatePolicy {
        public bool CheckValidationResult(
            ServicePoint srvPoint, X509Certificate certificate,
            WebRequest request, int certificateProblem) {
            return true;
        }
    }
"@
 
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
[System.Net.ServicePointManager]::SecurityProtocol = 'Tls11','Tls12'

Please provide comments, ideas & advice on how you think we should best handle this in order to co-exist with the AzureRM module but still allow connectivity using an un-trusted certificate during initial provisioning of a new Loadmaster

[eshess]

I think the suggested solution of forcing the validation check to return true is a bit risky. Once this change is made, it persists in the current powershell session. While incredibly unlikely, it could create a situation where validation is skipped unintentionally on unrelated tasks. Perhaps it could be added as a switch parameter similar to how MS operates using Invoke-Command/Enter-PSSession? (-UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)). Providing it as an easy option but forcing the end user to select it would ensure awareness of their actions.

Alternatively, if you redesigned module functions to run jobs when issuing WebRequests and didn't change the ServicePointManager properties anywhere but inside of those job calls, I believe that would isolate your changes from AzureRM's ServicePoint. The asynchronous calls could get messy, but adding job names and piping jobs to Wait-Job could force synchronicity where applicable.

[westforkfab]

Another way to solve this issue is to set the validation check to its default value (null) when leaving the wrapper. Basically when the called cmdlet starts, the backend code will set the System.Net.ServicePointManager]::ServerCertificateValidationCallback to $true allowing the communication between the PS wrapper and the LM.
When the cmdlet will end its job (successfully or not doesn't matter), the backend code will set System.Net.ServicePointManager]::ServerCertificateValidationCallback to $null.
In this way the validation check will be off only for the execution time of the cmdlet.

I tested this fix and it works fine.

Also run the communication task inside a job call, as suggested above by eshess, can improve the security side. To evaluate the effort to implement this solution.