The analysis of firewall logs in Office 365 projects repeatedly raises the question: Is this blocked IP address part of the Office 365 address range?
Thanks to PowerShell and the information published by Microsoft, the answer is only a few lines of code away.
My script “Test-IsO365IpAddress.ps1” simply needs the IP address in question and optionally the TCP/UDP port. It retrieves the current list of address ranges from Microsoft and checks if the IP address is part of one of the IP networks. If this is the case, the script outputs all services that use this network.
If a port was also specified as part of the command the output will be filtered.
In addition to the service name (e.g. “Exchange Online”), the category (Optimize, Allow or Default), the required ports, the subnet and the somewhat obsolete “Required” category are also displayed.
Equipped with this data, the visit to the firewall team should be successful.
Many thanks also to Luben Kirov who allowed my to use his network functions to analysis the IP networks fast and reliable and Siva Padisetty whose function checkSubnet I used as inspiration for my own implementation.
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.