Exciting News: Network Updates from Microsoft Azure and Cisco

Recomiendo revisar este post sobre las novedades entre VPNs de Azure y Cisco ASA.
Les comentare mis avances según implementaciones que esté realizando.
Fuente: http://www.stratum-tech.com/2017/06/23/azure-vpn-updates/

We’ve been building a lot of cloud infrastructure in Azure recently.  This includes everything from Azure Virtual Networks and Azure VPN Gateways to ExpressRoute and Network Security Groups.  There have been some big updates recently that may not have been the top of many tech blogs.  Here’s a quick update on one we at Stratum think is critical.

The Problem:  Azure / Policy-Based VPN Interconnectivity

Multi-Site, Multi-Location Example Networks

If you’ve been working with Azure Networking as much as we have lately, you know the feeling.  That feeling when a customer or network security team comes in to a meeting and declares “we’re going with Cisco ASAs for our Firewall and VPN Hardware”?  Yep, we know.  If you don’t know that feeling you’re lucky.  It’s that feeling that says the connectivity between your on-premise network and Microsoft Azure, specifically using an Azure VPN, is going to be limited.  Lost?  The picture on the right is a good reference for what happens when multiple sites with Policy-Based VPN Devices have to connect to multiple virtual networks using Azure VPN Gateways.  In the case of this scenario, we end up routing traffic between the Azure Networks across the customer’s infrastructure.  This can result in some higher latency, more moving parts, and routing issues.

The key problem has always been that Policy-Based VPN Devices and Policy-Based Azure VPN Gateway (aka Virtual Network Gateway or VNG) in Azure have always had a 1:1 relationship.  One connection can exist on each Azure VPN Gateway.  That’s it.  One.  There are lot of variations to this drawing:  multiple connections from the on-premise device to multiple VNGs (resulting in all traffic through the on-premise location), multiple sites needing access to a single site (resulting in all traffic again routing through the on-premise location), et. al.

It’s difficult to promote cloud flexibility when connectivity to your cloud resources is a 1:1 relationship!

Azure VPN Gateway Updates

Multi-Site Connectivity to Azure vNets

First of all, Microsoft has enabled (rather silently, I might add) connectivity between Route-based VNGs and Policy-Based VPN Appliances (See List Here).  Without getting into the technical details, the limitation restricted customers’ flexibility to address interconnected infrastructure.  It seems that Microsoft has heard enough from customers and partners, they’ve released some new capabilities to the Azure Network provider.  In other words, those updates allow connectivity from MORE THAN ONE Policy-Based VPN Device.  The details on how to configure this (and more background on what it gets you) are available in the Microsoft Azure Documentation.  Their documentation is great at the reason behind it and how to configure it.  (Full Disclaimer:  PowerShell is the only method to configure this today.)

The only remaining issue we see is that there currently is still no ability to transit beyond the single vNet.  In other words, the on-premise device cannot transit through Azure to anywhere else.  Therefore, (in our drawing) connectivity is between each site and the Azure vNets.  This does restrict access to any isolated vNet that may be required.

Cisco Updates

Second, Cisco ASA Devices are by far the most common Firewall Appliance Stratum encounters.  This usually results in our network builds using two or three workarounds to ensure connectivity for organizations with more than one site or Azure vNet.  The environments we encounter often have Cisco ASA 55xx Series devices and force our hand when designing environments.

Cisco has released IOS 9.8.1 for ASA devices, which now supports dynamic routing and IKEv2.  If you are evaluating devices such as ASAs, we *highly* recommend that they be compatible with this firmware. (This includes FirePOWER devices from what we can tell) With this firmware upgrade, your Azure Network can support full mesh capabilities.

The Outcome

Route-Based Connectivity with Gateway Transit

As a result of the updates, Cisco and Microsoft further improved the overall Azure experience.  Stratum is seeing more and more organizations that require isolation of resources inside of Azure.  These environments include Financial, PCI, and even PHI that must only be accessed through “corporate approved methods”.

Overall, with Cisco‘s release of IOS 9.8.1 for ASA devices, Cisco is facilitating a better-connected infrastructure for the numerous Azure customers that also leverage ASA devices. In conjunction with Microsoft’s extension of the Azure Networking provider, connectivity is easier for the small and mid-sized business.

SHARE THIS:

Internet Explorer’s Explicit Security Zone Mappings

Este articulo fue aplicado para asignar los sitios de confianza en un entorno windows server de 64bits con internet explorer 8, como se indica la aplicación de los "trusted sites" depende bastante de varios factores que pueden causar problemas y no ser asignados en la sesión del usuario.


Fuente:
https://blogs.technet.microsoft.com/fdcc/2011/09/22/internet-explorers-explicit-security-zone-mappings/


[Updated 15 May 2012 to correct a bug involving precedence of Computer policies over User policies.]
I recently worked with some customers who wanted to enumerate which web sites had been assigned to which Internet Explorer security zones.  I.e., they wanted to know which web sites had been assigned to the Intranet zone, which to Trusted Sites, etc.  In the course of this work I uncovered some surprising complexities about site-to-zone assignment rules that had not yet been documented.  This blog post describes those discoveries.  Later today I will post an updated version of IEZoneAnalyzer that lists the sites that have been configured and whether those settings are in effect or ignored. [Update: it’s been posted.]
[I’m not happy with the way the blog software has reformatted this document; rather than spend the day fighting it I’m attaching the original Word doc to this post.]

Overview

Internet Explorer applies a set of rules to associate web sites (URLs) with security zones, based on criteria such as whether the server has a dot in its name.  In addition, group policies, computer settings and user preferences can be used to map specific URLs to specific zones.  For example, you could explicitly add “https://www.contoso.com” to the Trusted Sites zone.  Such site-to-zone mappings are defined under one or more ZoneMap key hierarchies in the registry.  There are five different locations where ZoneMap key hierarchies can be defined, but only one or two of them will be in effect at any particular point in time.  Exactly which settings under which ZoneMap keys are effective depends on a number of circumstances:

·         Whether Site-To-Zone-Assignment lists are configured in Computer Configuration and/or User Configuration group policies;

·         Whether the “Security Zones: Use only machine settings” group policy is configured (a.k.a., Security_HKLM_only);

·         Whether Internet Explorer’s Enhanced Security Configuration (ESC) is enabled (Server only);

and, quite surprisingly:

·         Whether or not the program is a 32-bit process on 64-bit Windows; a.k.a., “Windows On Windows 64” or WOW64.

Yes, that’s right – in some circumstances, a 32-bit process and a 64-bit process on the same computer can see the same site mapped to different security zones.

Also, my testing indicates that there is a bug that results in all URLs being treated as “Internet” zone when both ESC and a Computer or User Site-To-Zone-Assignment list are enabled.

Explicit Site To Zone Rules

The rules for selecting ZoneMap keys are listed below.  Each table shows some combination of the four circumstances described in the overview; following each table is the key or keys that are in effect in those circumstances.  There are separate settings under each ZoneMap key for “ESC on” and “ESC off”.  If ESC is on, only those settings under the EscDomains and EscRanges subkeys are used; if ESC is off, only the settings under the Domains and Ranges subkeys are used.

Note that in the tables below, WOW64 set to “Yes” means a 32-bit process on a 64-bit version of Windows.  WOW64 set to “No” means either a 32-bit process on a 32-bit version of Windows or a 64-bit process on a 64-bit version of Windows.

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Yes	Cleared	Absent	Absent

Combines results from

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User preferences (in HKCU) take precedence over computer preferences

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
No	Cleared	Absent	Absent

Combines results from

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User preferences (in HKCU) take precedence over computer preferences

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Yes	Set	Absent	Either

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User site-to-zone assignments are ignored if present

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
No	Set	Absent	Either

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User site-to-zone assignments are ignored if present

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Either	Either	Present	Absent

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Either	Cleared	Present	Present

Combines results from

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

Computer policies (in HKLM) take precedence over User policies

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Either	Set	Present	Either

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User site-to-zone assignments are ignored if present

WOW64	Security_HKLM_only	Computer Site-To-Zone	User Site-To-Zone
Either	Cleared	Absent	Present

HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

What About “ZoneMapKey”?

IT administrators trying to apply site-to-zone settings by directly manipulating registry values often discover two “ZoneMapKey” registry keys that appear to be more interesting than they actually are: specifically, HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey and HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey.  Values under these keys look like the site-to-zone assignments applied through group policy, and in fact they are.  However, these keys are not used directly by Internet Explorer, and if you directly set values there, they will have no effect.  The ZoneMapKey entries are just a temporary writing place for the Group Policy engine, which writes entries there as specified by Group Policy, and then parses them into corresponding ZoneMap subkey settings that are used by Internet Explorer.