Azure Configure vNet peering

To allow communication between vNet’s in Azure we can set up peering connections. This is useful if there is a need to have different vNet’s for things like web app’s and backend database zones.

To configure peering we will require two different vNets both must be in the same Azure region.

Currently when I try to ping a VM that is running in a different vNet there is no communication. vNet01

Logon to Azure

Go to All services > Virtual networks vNet04

Once in Virtual networks select the network that will be configure for peering vNet02

Once the network blade is open go to peering > Add vNet03

Enter a Name, select the Subscription that the other vNet is in. Then Select the Virtual Network. Under configuration select Enabled and the last step tick Allow forwarded traffic vNet05

Below are some details on three options:

Allow forwarded traffic: This setting allows the peer’s forwarded traffic (traffic not originating from inside the peer virtual network) into your virtual network.
Allow gateway transit: Allows the peer virtual network to use your virtual network gateway. The peer virtual network cannot already have a gateway configured, and must select ‘use remote gateway’ in its peering settings.
Use remote gateway: You will need to Select this option if you wish to use your peer’s virtual network gateway. The peer virtual network must have a gateway configured, as well as ‘allow gateway transit’ enabled. Only one peering in this virtual network can have this enabled. You cannot use this setting if you already have a gateway configured in your virtual network.

Once all settings are confirmed click ok to create the peering vNet06 vNet07

Two allow communication both ways, there will need to peering setup on the App network aswell.

Once both are enabled we can now see response to ping requests vNet08

To lock down communication between the networks we can add NSG’s to restricted what inbound and outbound traffic is allowed from the subnet’s.

Configure MFA For Azure Application Proxy

On the last post we setup Azure Application Proxy to allow internal application’s to be made available externally using AAD integration.

To add additional security to the setup we can enable MFA for the group or users that will be allowed access.

To enable MFA we need to create a conditional access policy and enable on the application proxy.

First step Login to Azure

Go to Azure Active Directory (AAD) AZ1

Go to Enterprise applications

AZ3

Select the Application proxy that will require MFA to be enabled MFA6

Once in the Application proxy go to Conditional Access and select New policy MFA1

Give the policy a meaningful name as it will appear in the overall Conditional Access policy’s aswell as on the Application. This will make it easier to manage if there are multiple policy’s.

Then select Users and groups and select the required users or group MFA2

Next select the cloud apps that will require MFA in this case it is the Exchange ECP application that was configured previously MFA3

We will not setup conditions but if this is required it can be set to only allow access from certain devices types, location & sign-in risk level.

Next go to Access controls and then Grant tab. Select Grant access, tick Require multi-factor authentication and Requires one of the selected controls MFA4

Last step is to Enable the policy

MFA7

Click create at the bottom of the policy

The policy should now show and have tick under Enabled MFA5

Now when we try to access the ECP Application proxy URL,

we should be prompted for MFA MFA8

and asked to register and verify a device to be use for MFA MFA9

It is a good idea to enable MFA for application as it gives an additional layer of security.

Configure Azure Application Proxy To Access Internal Application

To access internal applications we can use Azure Application proxy to integrate with Azure AD and allow remote access to internal resources.

To use Azure Application Proxy requires Azure AD basic, Premium P1 or Premium P2 subscription.

An Account with Global administrator rights

The Azure application proxy connector requires Windows Server 2012 R2 or later

Below are pre-req ports and URL’s

See link below to Microsoft documentation

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy

Port number	How it’s used
80	Downloading certificate revocation lists (CRLs) while validating the SSL certificate
443	All outbound communication with the Application Proxy service

URL	How it’s used
.msappproxy.net .servicebus.windows.net	Communication between the connector and the Application Proxy cloud service
mscrl.microsoft.com:80 crl.microsoft.com:80 ocsp.msocsp.com:80 http://www.microsoft.com:80	Azure uses these URLs to verify certificates
login.windows.net login.microsoftonline.com	The connector uses these URLs during the registration process.

The following diagram shows how Azure AD and Application Proxy work together to provide single sign-on to on-premises applications. azureappproxxy

To start we need to download and configure the proxy connector

Go to Azure Active Directory (AAD) AZ1

Once in AAD go to Application proxy

AZ2

Click Download connector service APinstall0

Once downloaded run the MSI on the server that will be used as the application proxy connector (I used a server in a DMZ zone). It will prompt for an Azure account with Global admins rights.

Once configured the server should now show in the application proxy tab APinstall4

Once connected and active next step is to configure application

Go to AAD and Enterprise applications

AZ3

Once in Enterprise applications click on New application APinstall7

Click on On-premises application APinstall8

Below is a description for each field and option available in the application proxy

Name:
The name of the application that will appear on the access panel and in the Azure portal.

Internal URL:
The URL for accessing the application from inside your private network. You can provide a specific path on the backend server to publish, while the rest of the server is unpublished. In this way, you can publish different sites on the same server as different apps, and give each one its own name and access rules.
If you publish a path, make sure that it includes all the necessary images, scripts, and style sheets for your application. For example, if your app is at https://yourapp/app and uses images located at https://yourapp/media, then you should publish https://yourapp/ as the path. This internal URL doesn’t have to be the landing page your users see. For more information, see Set a custom home page for published apps.

External URL:

The address for users to access the app from outside your network. If you don’t want to use the default Application Proxy domain, read about custom domains in Azure AD Application Proxy.

Pre Authentication:
How Application Proxy verifies users before giving them access to your application.

Azure Active Directory – Application Proxy redirects users to sign in with Azure AD, which authenticates their permissions for the directory and application. Microsoft recommend keeping this option as the default, so that you can take advantage of Azure AD security features like conditional access and Multi-Factor Authentication. Azure Active Directory is required for monitoring the application with Microsoft Cloud Application Security.

Passthrough – Users don’t have to authenticate against Azure Active Directory to access the application. You can still set up authentication requirements on the backend.

Connector Group:
Connectors process the remote access to your application, and connector groups help you organize connectors and apps by region, network, or purpose. If you don’t have any connector groups created yet, your app is assigned to Default.
If your application uses WebSockets to connect, all connectors in the group must be version 1.5.612.0 or later.

Fill out the details required. I am using passthrough for pre authentication for the web site but this can be changed to AAD which then requires authentication before the site can be accessed.

(I created a basic IIS page on an internal web server to test with) APinstall9

Next step copy the external URL and try to access the site. There should be no prompt and the site should load

(Yay my lovely test site is available 🙂 ) APinstall13

I decided to also allow access to my internal Exchange server and to also test the AAD pre-authentication.

First create a second application proxy and set the Pre Authentication to Azure Active Directory APinstall14

I wanted to use a custom domain name for the second application proxy so I changed the external URL to the custom domain name in Azure.

Once a custom domain is selected we can add a certificate to match the URL.

There will be a warning that a CNAME entry will be required to point from the custom URL to the msappproxy.net address APinstall18

(This will require a CNAME record to be created on public DNS server that will map the application proxy to msappproxy.net) CNAME

Once configured we need to add a user or group to allow access.

Go to the application proxy, select the required application proxy and click on Users and groups, Add user and select either the user or group that will be allowed access APinstall16 APinstall15

Copy the link for the application proxy.

Unless a valid cert was also uploaded you will receive a cert error click continue to site.

It should now prompt for AAD authentication. Use an account that has access right to the proxy APinstall11

Once logged in the ECP page should now show. APinstall10