Month: October 2014

Network Security Groups in Azure

Network Security Groups (NSG) is one of the new network features that’s available in Azure. At least as long we are using the data center in North Europe (https://azure.microsoft.com/en-us/updates/new-networking-features-now-available-in-the-north-europe-region/). By leveraging NSGs we are able to control inbound and outbound network traffic all the way down to each separate VM. This is great in those cases where we have to implement high security and hard policies on our services. For example between the public facing endpoints and backend servers in a SharePoint deployment.

Concept drawing of Network Security Groups

To use it, we need version 0.8.10 of the Azure PowerShell module, and the commands are

  • Get-AzureNetworkSecurityGroup
  • Get-AzureNetworkSecurityGroupConfig
  • Get-AzureNetworkSecurityGroupForSubnet
  • New-AzureNetworkSecurityGroup
  • Remove-AzureNetworkSecurityGroup
  • Remove-AzureNetworkSecurityGroupConfig
  • Remove-AzureNetworkSecurityGroupFromSubnet
  • Remove-AzureNetworkSecurityRule
  • Set-AzureNetworkSecurityGroupConfig
  • Set-AzureNetworkSecurityGroupToSubnet
  • Set-AzureNetworkSecurityRule

 

The function is somehow self explained and the link at the bottom of this post explains it even a little bit more. But the best way to get to know them is to use Get-Help, and then just try 🙂

Documentation

Advertisements

Publish applications with Application Proxy

In this example I want to show show incredible easy it is to publish an internal application to the internet, using the Application Proxy feature in Azure Active Directory.

What is the Application Proxy?

Simply put. Azure Active Directory Application Proxy is a small service running on a Windows Server in your LAN, and creates a secure channel back to Microsoft Azure. From there, the service is made publicly available from a url based on the application name you choose, either using HTTP or HTTPS. The result is that you can make any web application available without advanced infrastructure at your side, and the best thing: You don’t need a public, static IP address!

If you don’t have a Azure Subscription today, you could sign up for a free trial at http://azure.microsoft.com/en-us/pricing/free-trial/.

Requirements

  • Windows Server 2012 R2
  • The server must be able to connect to the internet, and a list of outbound ports must be open in your firewall
Port Number Description
20200 – 20204 To enable long poll requests originated from the connector towards the Azure service
10100 – 10104 To enable LOB HTTP responses sent back to the proxy
8080 To enable the connector bootstrap sequence
9090 To enable connector registration

Enable the Application Proxy service in Azure AD

This is a two step process. First we need to click a magic button that enables Application Proxy for your Azure AD tenant. Step two is to install the connector on a Windows Serve running in your network.

Step one: Sign in and activate Application Proxy

Sign in to the Azure Management Portal at https://manage.windowsazure.com. From there, access the configuration tab for the Azure Active Directory you want to use. Around the middle of the page, you have a setting named application proxy. This setting has a button named Enabled. Click it, and then save the configuration.

EnableApplicationProxyButton

That’s all we need to do with the directory at this time. Next step then.

Step two: Install the connector

Sign in to the Windows Server you want to use as a Application Proxy, and download the Application Proxy Connector. When done downloading, click Run.

AzureADApplicationProxyConnectorDownload

On the Welcome page, simply click Next, and that’s all the configuration you need to do before starting the installation. So click Install. It should be over in seconds.

AzureADApplicationProxyConnectorReadyToInstall

Then you need to sign in using a Global Administrator account. Last time I did this, using a MFA enabled account it failed (Just so you’re not troubleshooting this again).

AzureADApplicationProxyConnectorSignIn

A few seconds later, it’s ready. Now, we can publish applications.

AzureADApplicationProxyConnectorCompleted

Publishing the intranet application

OK, it’s time to make the web application available to the internet.

The web application in this case is a password protected WordPress installation, running as an intranet application with the URL http://intranet/. Since I’m no IIS and URL Rewrite master, I’m going the easy way with this one, and just publish the internal application with the same name that we get from the msappproxy.net. This way, everything within the WordPress world works afterwards.

Back in the Azure Management Portal open the Applications tab of your Azure AD. At he bottom of the page, you have a add button. Click it, and in the popup, click Publish an application that will be accessible from outside your network

PublishAnApplication

The first task is to name our application. Name it smart, cause the name is used to generate a URL for your application.

PublishAnApplicationGiveName

The next task is to configure the internal URL, click the confirm button. In this case, I published it using HTTP, since I had some issues with the WordPress Admin page when using HTTPS and URL Rewrite in IIS. If you know how I could solve that one, feel free to leave a comment. In a production environment I would never recommend anyone to publish their intranet using HTTP.

PublishAnApplicationConfigureInternalURL

We are done configuring the proxy application!

PublishAnApplicationDone

The next step is to configure WordPress, and add a record on the application proxy server so the URLs are published correctly.

To solve this you need to do 3 things

  1. Sign in to the server hosting the Application Proxy and add a record in the hosts file, pointing the new external url to the web server running WordPress.
  2. At the WordPress server, change the binding in IIS to accept the new hostname.
  3. In the WordPress Admin Center, go to the Settings -> General page, and change WordPress Address and Site Address to the new external address

Refresh your browser, and would you look at that! It works 🙂

TheIntranetPage

Resources for you to continue on your own?

Recertification Exams Now Available for MCSE

Microsoft has released recertification exams for Server Infrastructure, Private Cloud and Desktop Infrastructure.

If you have a MSCE exam, you will have to do a recertification exam every three years, so now it’s time to start reading on all those things you never touched since last time.

Link to the new exams is available below, and at the original blog post at Born To Learn

 

Microsoft introduced the Azure Automation Runbook Gallery

Yesterday, Microsoft introduced the Azure Automation Runbook Gallery.  This new feature gives you a growing list of runbooks, that’s already polished and ready for use.

In other words, it just got much faster to achieve your automation goal without being a hard core PowerShell guru.

Read a more about it at the Microsoft Azure Blog http://azure.microsoft.com/blog/2014/10/07/introducing-the-azure-automation-runbook-gallery/

Configure Active Directory Federation Services to request Multi-Factor Authentication only from external users

When you enable Azure MFA on a tenant, you get the option to configure IP whitelisting. Another nice feature that you have is to require MFA only when the users do not originate from the intranet. In a multisite environment, with offices located all over the world, or if you do not have a persistent IP from your internet service provider, this is like gold!

If you want this to work, you have to do some configuration on your Active Directory Federation Service (ADFS). Along with the normal claims, you also have to send another one.

http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork

Alongside with enabling this, I’ll also configuring the service so the users can check the Keep me signed in box.

Configuration time

Sign into your ADFS server, and open the ADFS Management Console. If you then browse into Trust Relationships -> Relying Party Trusts. There you find Microsoft Office 365 Identify Platform.

Microsoft Office 365 Identity Platform

Right click and, select Edit Claims Roules…

You are now watching the default claims rules that’s configured for Office 365. We will add two rules here. One for the Inside Corporate Network feature and one for the Keep me signed in feature.

Before addig aditional claims

First the Inside Corporate Network setting. Click Add Rule… and from the dropdown menu select Pass Through or Filter an Incoming Claim.

New Pass trough claim

Then give the rule a good name, and set the Incoming claim type to Inside Corporate Network. That is it.

InsideCorporateNetwork Claim

The next one is for the Keep me signed in. Add a new rule, and from the dropdown menu select Send Claims Using a Custom Rule.

Custom Rule

On the next page, give the rule a good name, and add this custom rule

c:[Type == "http://schemas.microsoft.com/2014/03/psso"]
 => issue(claim = c);

psso claim

That is all. Your MFA enabled users no longer gets a request to verify their authentication when they originate from the intranet.

Final result