A couple of weeks ago I recognized new registry keys the SCHANNEL settings of the Windows 2016 Azure Marketplace image. Those setting are different from a manually deployed and updated Windows machine!
The newly created registry keys disable the following ciphers and protocols
SSL 2.0 Client
SSL 3.0 Client/Server
First of all: The settings changed are regarding old ciphers and protocols that should be disabled in any secure environment after all! Some of them are even disabled without any registry keys starting Windows 2016 already.
Also it states that SSL 2.0 has been removed completely, and SSL 3.0 client and server is disabled by default. This makes the registry changes obsolete and only configures the defaults in place.Maybe Microsoft did this to help some poorly configured audit tool to show successful results or to better show the default config to the administrator.
In 2013 Microsoft published the “Security Advisory 2868725” which states the mentioned RC4 ciphers should be disabled. So after about 5 – 6 years later Microsoft has implemented this best practice for all newly deployed Azure VMs. Sadly it did not document the change anywhere.
Please be aware that if you deploy a Windows 2016 server from ISO and install the latest updates RC4 will still be active with the exception when using SCH_USE_STRONG_CRYPTO, as you can read here. You should disable
If you are using Azure Automation and use the AzureRM.Network module in one of the versions from 0.9.0 to min. 0.10.0, you may experience problems running Azure Automation Runbooks.
If the runbooks used are more complex overall, this version may result in a high memory load. If more than 400 MB RAM are used, the runbook ends after three attempts in the status “Suspended”.
The runbook job was attempted 3 times, but it failed each time. Common reasons that runbook jobs fail can be found here: https://docs.Microsoft.com/en-us/Azure/automation/automation-troubleshooting-automation-errors
A downgrade to version 6.8.0 is required. The easiest way, of course, is with PowerShell.
Pester tests can be used to ensure a level of quality in PowerShell module development that would otherwise be difficult to achieve manually. There are two important factors to consider. Module and Function Integrity.
Although Microsoft does a great job with their AzureRM Modul module, there are always reasons not to use these Cmdlets. In most cases because they are slower than direct requests against the Azure REST API. In other cases because certain functionality has not yet been implemented.