Zoho Banner September 2011

Archive for the ‘Azure’ Category

This post provides a quick introduction to the features available with Azure Active Directory Business to Business (B2B) Collaboration – currently in Public Preview.  I’ll cover how to add someone outside your organisation to your Azure AD instance, as well  as how to assign administrative privilege over the Azure subscription to the external partner through RBAC delegation.

Let’s kick things off by adding the external partner via the new Azure Portal. In this example the external partner is named Badger Lafarge and has an Gmail account.  My Azure tenant is named Fish Eagle.

Once logged into the Azure Portal, select Azure Active Directory from the left hand menu.

B2B

Select Users and Groups from the presented options.

B2B_2

Select All Users

B2B_3

The full list of existing users will appear.  Select the Add option.

B2B_4

Complete all the required information for the users and any additional profile and group in formation. Note that you have the ability to enter the text that will be sent into the body of the invitation email sent to the user.

B2B_6

You will see that in this example I have chosen to add the user to a group named MSDN Subscription Admins. This group has been delegated the Owner role to the Fish Eagle MSDN subscription.  I’ll show where this is configured later in the article.

B2B_5

After completing the setup, select Create.  At this point an invitation will be sent to the user, as shown in the example (Gmail) below.

B2B_7

The user then clicks on Get Started.  At this point Azure will determine whether an account (either in a different Azure AD or a Microsoft Account) already exists for the user based on the email address.  In my example, the user Badger Lafarge does not have any account, so one needs to be setup.  This is the normal Microsoft Account process and as such I don’t need to show it here.

B2B_8

Note that the welcome message indicates the invitation relates to access to myapps.microsoft.com.  While assigning access to apps within an Azure tenant to partners is probably the most common scenario, it is not the use case here and can be ignored.

After completing the account setup, the external partner (Badger Lafarge) is presented with the MyApps portal.  This shows the B2B setup workflow has completed successfully.  You can then see the partner account present in Azure AD.  Note the globe icon that indicates the external status.

B2B_9

Now that Badger Lafarge has been set up correctly, he can log into the Azure Portal using the credentials he configured as part of the Microsoft Account creation.  You can see from the following screenshot that once logged into the Azure Portal the external account (Badger) has access to the resources available in my tenant within my MSDN subscription (Fish Eagle).

B2B_10

With the Owner role assigned to my MSDN subscription, Badger can now do pretty much anything he wants to with my Azure resources.  He can stop and start machines, delete storage accounts, create new resource groups, generally do a lot of damage and spend up large!  This is by way of a warning – with great power comes great responsibility – be careful how you assign permissions and use the principle of ‘least privilege’ as you would normally.

In case you missed it earlier, not all external partners you add are automatically assign Owner rights over your subscription.  That would be madness!  Instead, when I created Badger as an external partner in my Azure AD I chose to add him to the MSDN Subscription Admins group.  This is not a built in group.  Instead it is a group I manually created within my Azure AD with the specific purpose of assigning Owner permissions over my subscription using Azure’s RBAC features.  Of course I could have assigned him the Owner role directly (i.e. not using an Azure AD group), but where is the fun in that?  The screenshot below shows where the Owner role assignment is configured within the Azure Portal.

B2B_11

That’s basically it.  Once you have the external partner in your Azure AD you can do other tasks such as assignment to your Apps (exposed via the MyApps portal) and delegation within our Azure AD instance.

What I really like about the B2B feature is how easy it is to set up within the Portal.  Hopefully that is clear from this blog post.

 

Recently I set up Web Application Proxy (WAP) instances for a customer to support remote access to several on-premises web applications.  I was looking for a cheap and effective means of ensuring the service continued to be available to clients in the event that one of the WAP instances went down.  Someone recommended using Azure Traffic Manager (ATM) for this.  ATM is cheap, especially compared to an external geo-load-balancer and, also being a Microsoft service, allows you to use Powershell to get things up and running as well as for ongoing administration.  I found some useful on-line information on how to integrate ATM with WAP, but not all in one place and some of the information was out of date.  Hopefully this article will help those to want to do the cut out the noise and simply get up and running quickly.

The first step is to create an ATM Profile.  In this example I have used the DNS name wap.fish-eagle.trafficmanager.net. The wap prefix obviously refers to Web Application Proxy, while fish-eagle is my company name.  The trafficmanager.net suffix is fixed and is common for all ATM DNS names.

ATM_CREATE

Note that if you use the Azure Portal to create the ATM profile (as opposed to using Powershell), the routing method will default to Performance.  This is fine if you have endpoints configured in different geographical regions and you want client requests to be directed to the nearest endpoint (WAP instance).  In my case the WAP instances are both in New Zealand and share the same geographical region (from an Azure global perspective), so I changed the routing method to Weighted with an equal weighting.  This means that neither instance is preferred and ATM will direct 50% of client requests to one instance and 50% to the other under normal circumstances.  ATM monitors the endpoints and will stop directing clients to an endpoint it has detected as being offline.  For a more in-depth discussion of the available routing methods, see this helpful article.

If you don’t already have public DNS A records for each of your WAP instances then this is the time to create them, as you will need them when configuring the ATM endpoints.  In my example, I have created two records:

north.fish-eagle.net A 131.203.247.134

south.fish-eagle.net A 210.48.109.10

dns-before

You will also need to create public DNS CNAME records for each of the web services pubished via the WAP and have these point to the DNS name of the ATM profile you created.  In my example, it looks like this:

mywebapp.fish-eagle.net CNAME wap.fish-eagle.trafficmanager.net.

The ATM will not be able to furnish client requests with a suitable IP address until the endpoints have been configured, which is the next step.

When ATM was first made available it was only possible to configure Azure endpoints, i.e. those that existed in either Azure PaaS or IaaS. Recently, Microsoft has made it possible to also monitor endpoints outside Azure.  These are referred to as external endpoints.  Currently, external endpoints can only be configured using the Azure Powershell module.

After you have downloaded and installed the Powershell module, you need to log in with an account that has permissions to the Azure Resource Group in which the ATM profile has been created.

Login-AzureRmAccount

Login_azure_rm

Choose the Azure subscription to use.

Set-AzureRmContext -SubscriptionId 578039e9-a84e-4e7a-8797-dbbd991cc6b0

Set-Context

Create a one-time registration to use the Microsoft.Network service provider.

Register-AzureRmResourceProvider –ProviderNamespace Microsoft.Network

Register-ResourceProvider

Get a list of your Azure Traffic Manager profiles (in my case there is only one).  Note that currently no Endpoints are configured.

Get-AzureRmTrafficManagerProfile

Get-ATM Profile

Retrieve the existing Traffic Manager profile object, set the MonitorPath and commit the changes.  Note that the default monitoring path “/” has been known to have issues when monitoring WAP endpoints, i.e. ATM incorrectly detects them as Offline at times.  The built-in “/adfs/probe/” path on the WAP servers can be leveraged to correct the aberrant monitoring behaviour.

$profile = Get-AzureRmTrafficManagerProfile –Name wap-fish-eagle -ResourceGroupName fe-production

$profile.MonitorPath = “/adfs/probe/”

Set-AzureRmTrafficManagerProfile –TrafficManagerProfile $profile

Set-MonitorPath

Change the routing method from Performance to Weighted (if you didn’t already do this in the Azure Portal during creation of the ATM profile), and commit the changes.

$profile.TrafficRoutingMethod = “Weighted”

Set-AzureRmTrafficManagerProfile –TrafficManagerProfile $profile

Set-RoutingMethod

Create the external endpoints and commit the changes to the profile.  Note that the value of the Target parameter in each cmdlet corresponds to the DNS A records we established earlier.

Add-AzureRmTrafficManagerEndpointConfig –EndpointName wapnorth `
–TrafficManagerProfile $profile –Type ExternalEndpoints `
-Target north.fish-eagle.net –EndpointStatus Enabled

Add-endpoint

Add-AzureRmTrafficManagerEndpointConfig –EndpointName wapsouth `
–TrafficManagerProfile $profile –Type ExternalEndpoints `
-Target south.fish-eagle.net –EndpointStatus Enabled

Set-AzureRmTrafficManagerProfile –TrafficManagerProfile $profile

Add-endpoint2

Now when you run a DNS query for your web application(s) published through WAP, ATM should provide you with the IP address of one of the available (i.e. Online) endpoints.  Here’s how mine looks.

dns-after

As you can see from the screenshot, ATM has provided the DNS client with the IP address (210.48.109.10), which corresponds to one of my WAP instances (south.fish-eagle.net).

At this point the configuration is complete.  If both WAP instances are up and the monitoring is working successfully, you should see the monitoring status showing as Online in the Azure Portal.

ATM_CREATE

Note that you will need to allow inbound traffic on TCP Port 80 (HTTP) on your external firewall and WAP Windows Firewall configurations for the monitoring to be successful.

The setup of the ATM monitoring component should you take less than an hour.  ATM provides a cheap and effective way to provide a seamless client experience for the web applications published via your WAP infrastructure.

Good luck and be careful out there!