Azure Private Link – a new feature for Enhanced Security

Azure is getting even more secure through the release of the Azure Private Link.

Azure Private Link provides private connectivity from a virtual network to Azure services, customer-owned or Microsoft partners services.

This means you can for example consume services like storages, databases, etc. within a VNet, without exposing the data to the Internet. All traffic to the service can be routed through the private endpoint, so no gateways, NAT devices, ExpressRoute or VPN connections, or public IP addresses are needed. Private Link keeps traffic on the Microsoft global network.

The configuration is straight forward. In the networking settings of the resource, you select Private endpoint for the connectivity method and create a new endpoint.

Note: at the time of this writing, Azure Private Link is available only in the US region.

Check here the availability for other regions.

Trying to configure Azure Private Link in a region where the feature is not available will generate this message:

Azure DevOps: white list Azure Pipeline IP in Cosmos database firewall. How to add the Azure DevOps Hosted Agent IP address to a Cosmos database firewall.

I am currently doing the Azure backup strategy for one of our customers. While Azure takes regular backups of the Cosmos databases, in case of an application failure that would corrupt the data, they would not help. Because Azure would back up the already corrupted data.

The solution is to store our own backups. We use an Azure Pipeline which takes a daily backup of our databases.

But the problem is that the databases are IP restricted behind a firewall. And the Azure Pipeline fails because the Azure DevOps Hosted Agent cannot pass through the firewall.

The solution found is to add a step in our Azure Pipeline, which adds the Azure DevOps Agent IP address to the database white list and removes it at the end.

PowerShell script:

#Function to add current IP to database account
Function add-ip-databaseaccount ($customIP, $databaseResourceGroup, $databaseAccount){
    Write-Host "  " $customIP "is not allowed. Adding it now.." -ForegroundColor Green
    $databaseAccountIpRangeFilter = (Get-AzResource -Name $databaseAccount -ExpandProperties).Properties.ipRangeFilter
    $databaseAccountIpRangeFilter = $databaseAccountIpRangeFilter + "," + $customIP
    $databaseAccountProperties = @{"databaseAccountOfferType"="Standard"; "ipRangeFilter"=$databaseAccountIpRangeFilter}
    Set-AzResource -ResourceType "Microsoft.DocumentDb/databaseAccounts" -ResourceGroupName $databaseResourceGroup -Name $databaseAccount -Properties $databaseAccountProperties -Force
    Get-AzResource -Name $databaseAccount -ExpandProperties
    #Although the IP is being added to the allowed list, it takes some time until the changes are being used
    Start-Sleep -Seconds 600

#Function to remove current IP to database account
Function remove-ip-databaseaccount ($customIP, $databaseResourceGroup, $databaseAccount){
    $databaseAccountIpRangeFilter = (Get-AzResource -Name $databaseAccount -ExpandProperties).Properties.ipRangeFilter
    $databaseAccountIpRangeFilter = $databaseAccountIpRangeFilter.Split(',')
    Write-Host Checking firewall settings for database $databaseAccount :
    if ($customIP -in $databaseAccountIpRangeFilter) {
        Write-Host "  " $customIP "is allowed. Removing it now.." -ForegroundColor Green
        [System.Collections.ArrayList]$ArrayList = [array]$databaseAccountIpRangeFilter
        $databaseAccountIpRangeFilter = $ArrayList -join ','
        $databaseAccountProperties = @{"databaseAccountOfferType"="Standard"; "ipRangeFilter"=$databaseAccountIpRangeFilter}
        Set-AzResource -ResourceType "Microsoft.DocumentDb/databaseAccounts" -ResourceGroupName $databaseResourceGroup -Name $databaseAccount -Properties $databaseAccountProperties -Force
        Get-AzResource -Name $databaseAccount -ExpandProperties
    else {
        Write-Host "  " $customIP "was already not allowed." -ForegroundColor Green


#Retrieve the current IP
$ipinfo = Invoke-RestMethod
$myip = $ipinfo.ip

#Check if DB has IP filtering active:
$dbAccountIpRangeFilter = (Get-AzResource -Name $dbAccount -ExpandProperties).Properties.ipRangeFilter

#If IP filtering is in place
    Write-Host "IP filtering is active for " $dbAccount
    $dbAccountIpRangeFilter = (Get-AzResource -Name $dbAccount -ExpandProperties).Properties.ipRangeFilter
    $dbAccountIpRangeFilterArray = $dbAccountIpRangeFilter.Split(',')
    Write-Host Checking firewall settings for db $dbAccount :

    if ($myip -in $dbAccountIpRangeFilterArray) {
        Write-Host "  " $myip "is already allowed." -ForegroundColor Green
        backup-db $dbResourceGroup $dbAccount $dbName $dbCollections
        add-ip-dbaccount $myIp $dbResourceGroup $dbAccount
        backup-db $dbResourceGroup $dbAccount $dbName $dbCollections
        remove-ip-dbaccount $myIp $dbResourceGroup $dbAccount    
    Write-Host "IP filtering is not active for " $dbAccount
    backup-db $dbResourceGroup $dbAccount $dbName $dbCollections

I will try to explain the function backup-database in a separate blog post.

O365 News: Security & Compliance Center is getting replaced

Office 365 Security & Compliance Center is getting replaced by 2 new sites:

The administrator experience will change, but this won’t impact your current security and compliance configurations.

The rollout happens February through March 2019.

Office 365 security: 3DES cipher comes to it’s end on February 28, 2019

As part of Microsoft’s plan to move all online services to TLS 1.2, they are retiring 3DES beginning February 28, 2019. As a result, connections using the ciper 3DES will not work.

You can get an overview of your TLS 1.0/1.1 and 3DES usage in Office 365’s Secure Score at

Remember that TLS 1.0 and TLS 1.1 are not supported since October 31, 2018. Fore more details see:

Office 365 will remove support for TLS 1.0 and TLS 1.1 starting October 31, 2018

As of October 31, 2018, Microsoft Office 365 will remove support for TLS 1.0 and 1.1. This means that if you have issues connecting to Office 365 services because of weaker protocols, no support tickets would be generated.

By October 31, 2018, all client-server and browser-server combinations should use TLS version 1.2 (or a later version) to ensure connection without issues to Office 365 services. This may require updates to certain client-server and browser-server combinations.

If you do not update to TLS version 1.2 (or later) by October 31, 2018, you may experience issues when connecting to Office 365. If you experience an issue related to the use of an old TLS version after October 31, 2018, you will be required to update to TLS 1.2 as part of the resolution.

The following are some clients that we know are unable to use TLS 1.2. Please update your clients to ensure uninterrupted access to the service.

•  Android 4.3 and earlier versions
•  Firefox version 5.0 and earlier versions
•  Internet Explorer 8-10 on Windows 7 and earlier versions
•  Internet Explorer 10 on Win Phone 8.0
•  Safari 6.0.4/OS X10.8.4 and earlier versions


This change comes in the context where of all major web browsers, including Google Chrome, Apple Safari, Microsoft Edge, Internet Explorer, and Mozilla Firefox, altogether announced October 15, 2018 to remove support for TLS 1.0 (20-year-old) and TLS 1.1 (12-year-old) communication encryption protocols in the first half of 2020.

See the official articles here: