Category Archives: Azure

Azure Application Proxy services


Azure AD Application Proxy (AAD-AP) is a type of reverse proxy solution that enables access to web-based applications that exist on a corporate LAN, secured behind a corporate firewall.

The benefits of using AAD-AP rather than using a traditional firewall to expose an application to external access are (1) the convenience of listing the application in the user’s Office 365 menu choices (see first screen shot below) or the Azure Access panel and (2) the enhanced security of preauthentication using Azure Active Directory and the option of enhancing security with Azure Multifactor Authentication. These later two security enhancements were previously provided by solutions such as Microsoft ISA or TMG.

The convenience that users benefit from is having one place to access all internal web-based corporate applications, as well as over 2,400 3rd party SaaS applications. In the screen shot below you will see that amongst the Office 365 applications list, I have also configured single sign on for Facebook, Google Docs, ADP, Salesforce, and more. It is very convenient to logon once to Azure Active Directory or Office 365, then launch other applications without having to logon to those applications individually.  This amounts to huge time savings and it is really nice not having to remember 10 separate usernames and passwords! This now puts Azure AD on par with other hosted identity providers such as Okta, Onelogin or PingFederate.

This blog post is a review of AAD-AP, a component of Azure AD Premium and Azure AD Basic.

AAD-AP exposed application ‘My Intranet’ in Office 365

If you don’t have Office 365 you can also use the Microsoft Azure access panel to achieve SSO (as shown below).

image (this redirects you to )

The 3rd way of accessing internal applications through AAD-AP is a direct hyperlink. This is provided after configuring the application in the Azure management portal.
For example: 
The convention is: (Application Name – Azure Tenant Name – (similar in concept to the O365 tenant name “”)
Custom domain names are coming soon, so you will be able to have the AAD-AP name in front of your own domain name, ex: 



Application Proxy Prerequisites

  • You must have an Microsoft Azure administrator account. If you don’t’ have one, you can get a 30 day trial here.
  • You must have an Azure AD Premium license. For more information, see Getting Started with Azure AD Premium. You can also get a 30 day trial to evaluate this as well.
  • A server running Windows Server 2012 R2 or Windows 8.1 or higher on which you can install the Application Proxy Connector. The server must be able to send HTTPS requests to the Application Proxy services in the cloud, and it must have an HTTPS connection to the applications that you intend to publish.
  • The server running the connector must be able to make outbound connections to this domain and subdomain: on the following TCP/IP port ranges:
    443, 20200-20210, 9352, 10100-10120, 8080, 9090 and 9091. For a description of what these ports are used for, see :
      • There are no inbound ports required, because Azure Application Proxy service (ApplicationProxyConnectorService.exe)  initiates a reverse tunnel from the VM out to Azure.
  • If the web application requires windows integrated authentication, then the machine where the connector is installed must be joined to the domain.
  • For windows integrated authentication, The UPNs in Azure Active Directory must be identical to the UPNs in your on-premises Active Directory in order for preauthentication to work. Make sure your Azure Active Directory is synchronized with your on-premises Active Directory.
  • For accessing applications remotely, the application that you are proxying cannot send the user any 302 redirects otherwise those will most likely contain internal server names that are not accessible internally. See the scenario below that happens when I first tried to publish the Lync control panel. The fix for the Lync scenario was to publish the actual path to the CSCP virtual directory. This is thanks to the new Path Publishing feature that was announced on March 11th, 2015 on the Azure Application Proxy blog here.
  • In my testing, AAD-AP worked with Windows machines running Internet Explorer or Chrome, iOS devices and Mac OSX (Safari and Chrome). The official support statement says that the Access Panel Extension is available for Internet Explorer 8 and later, Chrome, and Firefox browsers.

Microsoft AAD Application Proxy Connector

The connector is a small 4 MB file that can be downloaded from the Azure Management Portal when configuring a new application that relies on Application Proxy.

You should install the connector software on a VM that has HTTP/S access to the application that you want to publish, and outbound access to Azure.

Installing the connector is quick and painless. The only information you are prompted to provide is just the Azure tenant administrator username and password.





It installs two services, the main service runs under network service because it must be able to interact with other servers to perform the reverse proxy, and optionally to perform Kerberos delegation for web based applications that required windows authentication.


Configuring the Connector for Windows Integrated Authentication

Let’s say you want to publish the Lync Control Panel to through the Azure application proxy.

Since the Lync Control Panel requires Windows Integrated Authentication, we need to configure the Active Directory Computer object for delegation. For step by step details, see this Microsoft article, otherwise I will cover the high level steps here.

I did not have a service principal name (SPN) for my Lync simple URL for administration, I had to create it first. Before creating an SPN, it is good practice to check to see if it exists first. You can query to see if an SPN exists with the ‘setspn’ command that you run in a regular command shell on any server (domain admin privs are required).
setspn -Q http/
Note: The SPN format is a little odd because there is a single forward slash, whereas you would normally expect to see a colon followed by two slashes.

To create the SPN, I ran this command:
setspn –S http/ tctfe01  
(Note: The Lync ‘standard edition’ front-end server name was TCTFE01. For Enterprise editions, you will use a service account rather than an individual computer name). You can use the –Q or –L parameters to verify that it registered correctly.

After the SPN has been created, the next step is to configure the Active Directory Computer object for delegation. Find the computer object for the machine where you installed the Connector software in Active Directory Users and Computers. In my case, my connector was installed on a server named “HV1” so I found that object and on the delegation tab, I added the computer name of my Lync standard edition front end server “TCTFE01.” For Enterprise Edition deployments, you would configure delegation on the relevant service account instead.


This allowed me to find the SPN I had created for the SPN record


Now you can add the SPN into the Azure Management portal:


You should now see the Lync Control panel in the Office 365 list of applications.

What I found out next helped me to understand more about the features and limitations of Azure Application Proxy.

When I published the simple URL for the Lync control panel (‘’) I found that it was working internally but it failed to work externally. After some fiddler analysis I discovered that it was working internally because Lync web services sent an HTTP 302 Redirect to the internal DNS host name of the Lync standard edition front-end server, along with the virtual directory of the control panel, ex: (‘’). Since the internal host name is not published in external DNS, nor is there a firewall rule permitting this, it failed externally.
So Azure Application Services is faithfully sending the 302 redirect back to the external user, so there was nothing broken, per se. This shows one requirement to be aware of – check to make sure that the application you want to proxy does not use 302 redirects.

HTTP/1.1 302 Redirect
Content-Length: 168
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/8.0 Microsoft-HTTPAPI/2.0
X-Powered-By: ASP.NET

<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF=””>here</a></body>

The workaround that I found was to use the new path publishing feature (Thanks Microsoft Application Proxy team!!). This enabled me to publish the full path where the 302 redirect was sending the user to (‘’). This can only be setup when the application is first configured, so if you forgot to add /cscp in the beginning, you will need to delete the app and start over.


In my case, I didn’t have /cscp/ from the beginning, so I had to delete my app and start over like this:


There was already an existing SPN record, so I did not have to create another SPN for, but I did have to configure computer delegation on the HV1 computer account for http/ instead of http/

So even though the internal dns name of my Lync server is not published externally, this shows the power and benefit of Azure Application Proxy because I can now access the Lync administrative control panel from anywhere.




1. The connector software is not highly available, so make sure to install it on a virtual machine that benefits from high availability at the hypervisor layer (ex: vmotion or live migration).

2. Since this is such a new service, I am not sure what the scalability and performance of the connector service would be in a production environment. So you would need to perform your own performance testing. Consider using Azure’s Visual Studio Cloud Load Testing

3. In the next blog post in this series, I describe the new conditional access feature using Azure’s multi-factor authentication. See Controlling Access to Application Proxy (Optional)

Azure AD Federated SaaS Apps

Thanks to Aaron Smalser on the Microsoft Azure product team, I was pointed in the direction of this page that allows me to see the list of Azure AD pre-integrated apps that support SAML or WS-Federation. Thanks Aaron!

As of this writing on 3/11/15, there are now 105 applications that support SAML or WS-Federation with Azure AD. That is double what was available on September 2nd 2014 (per Alex Simon’s blog article here). 

So out of the 2,460 total applications available in the gallery, or 2,355 that support “Password Single Sign-On” which is what I would describe as password vaulting, and 105 support federated sign-in. The latter is the most optimal experience in my opinion.

So in the 191 days between 9/2/2014 and 3/11/2015, Microsoft has added 55 new applications that support SAML or WS-Federation. That is about 1 new application every 3.5 days. That is impressive!

1    15Five
2    Abintegro
3    Adaptive Suite
4    Adobe EchoSign
5    AnswerHub
6    AppDynamics
7    ArcGIS
8    Ariett Purchase & Expense
9    Ariett Touch
10    AvePoint Meetings
11    BambooHR
12    Bime
13    BlueJeans
14    Bonusly
15    Boomi
16    Box
17    Canvas
18    Central Desktop
19    Cisco Webex
20    Citrix GoToMeeting
21    Citrix ShareFile
22    Clarizen
23    ClickTime
24    CloudBees
25    Colibri
26    Concur
27    Cornerstone OnDemand, Inc.
28    Coupa
29    Docusign
30    Dream Broker Studio
31    Dropbox for Business
32    e-Builder
33    Egnyte
34    Envoy
35    EventBuilder
36    FreshDesk
37    Freshservice
38    Gigya
39    Google Apps
40    Greenhouse
41    Huddle
42    IdeaScale
43    Infolinx
44    Innotas
45    InsideView
46    Intacct
47    ITRP
48    Jitbit Helpdesk
49    Jive
50    Kintone
51    Kontiki
52    Kudos
53    LogicMonitor
55    Mimecast Admin Console
56    Mimecast Personal Portal
57    Mindflash
58    Mozy Enterprise
59    MyDay
60    NetDocuments
61    New Relic
62    OfficeSpace Software
63    PagerDuty
64    Panopto
65    Panorama9
66    Picturepark
67    Projectplace
68    Rally Software
69    Replicon
70    RunMyProcess
71    Salesforce
72    Salesforce Sandbox
73    Samanage
74    Sciforma
75    ScreenSteps
76    ServiceNow
77    ShiftPlanning
78    SmarterU
79    Smartsheet
80    SpringCM
81    SuccessFactors
82    SumoLogic
83    SumTotalCentral
84    Syncplicity
85    TalentLMS
86    Team Org Chart
87    TeamSeer
88    ThirdLight
89    Thoughtworks Mingle
90    ThousandEyes
91    Timestamp
92    UserVoice
93    Wikispaces
95    Workday
97    xMatters OnDemand
98    Zendesk
99    Zoho Mail
100    Zoom
101    Zscaler
102    Zscaler Beta
103    Zscaler One
104    Zscaler Two
105    Zscaler ZSCloud

Windows Azure Automation

Windows Azure Automation allows you to automate the creation, monitoring, deployment, and maintenance of resources in your Windows Azure environment. For example, by default Azure Automation comes with a default Azure runbook containing over 350 Azure powershell commands that you can schedule for automation. You will also be able to import other runbooks to automate non-Azure assets, or create your own.

“Azure Automation provides an orchestration feature set for public cloud resources that is similar to what the Service Management Automation (SMA) engine provides for on-premises private cloud resources via the Windows Azure Pack and System Center 2012 R2 Orchestrator.” – Keith Mayer (from his excellent blog on Automation here).

I looked into this service because I wanted a solution to shut down my demo VM’s running in Azure on a nightly basis.

The first step is to logon to the Azure Account Portal and sign in with your subscription information:

Then click Preview Features and click the “Try it now” button


A pop-up will appear informing you that the feature will be added to your subscription soon.


Now logon to the Azure Management Portal. If you were previously signed in, you must sign out and back in before you’ll see the Automation option appear in the menu.


Click ‘Create an automation account’

At the time of preview, it is only available in East US.


To get started with your first “Hello World” runbook, follow the guidance online (here).

There are currently 20 powershell commands for managing Azure Automation available (here).

There are 30 runbooks in the Technet script gallery that have been written by the community for use in Azure Automation available (here).

I found a runbook on the Technet script gallery (here) written by Peter Selch Dahl for stopping all VMs.

However, after reading the rest of Keith Mayer’s blog, I decided to just follow his article.

Microsoft Azure (IaaS) Cost Estimator Tool

Microsoft just released a tool that can connect to your on-premises environment and estimate the cost of running it in Azure Infrastructure as a Service (IaaS).

You can target an individual physical machine, a Hyper-V or vCenter/ESX host, or a System Center Virtual Machine Manager (VMM) environment.

The tool takes seconds to install and is extremely easy to use. I installed it on my Windows 8.1 domain-joined laptop and pointed it at my lab environment running Hyper-V.

1. Download the beta (here). Note: The beta will expire on 9-1-2014.

2. Follow the installation (next –> next –> done!)

3. Launch the tool and click on Hyper-V


4. Enter the details of your Hyper-V server


Note: I selected ‘Run Once’ to get an immediate cost but I like how the tool allows you to run it over a configurable duration of time so that it can include other factors such as disk and network I/O.

Click Begin Profiling to run the scan.


In my experience, the scan averaged about 120 Kbit/s between my workstation and the server.


5. Click on the virtual machines that you are interested in getting a quote on


6. Click ‘get cost’ in the bottom-right.




Introduction to Windows Azure Active Directory “Premium”

Windows Azure Active Directory (WAAD) “Premium” is a paid offering that unlocks additional features of WAAD. It is currently in preview and can be unlocked in the Azure Preview Portal.

[Update: WAAD reached General Availability on April 8, 2013 whereas WAAD Premium was available in Preview in December 2013, and GA sometime later [please post a comment if you have the GA release date of Premium]

WAAD Premium adds these features:

  • User self-service password reset –Give your end-users the ability to reset their password using the same sign in experience they have for Office 365.
    For more information, see Enable self-service password reset for users.
  • Group-based application access – Use groups to assign user access in bulk to SaaS applications. These groups can either be created solely in the cloud or you can leverage existing groups that have been synced in from your on-premises Active Directory.
    For more information, see Group management.
  • Company branding – Add your company logo and color schemes to your organization’s Sign In and Access Panel pages (including localized versions of the logo for different languages).
    For more information, see Add company branding to your Sign In and Access Panel pages.

    Additional security reports – View detailed security reports showing anomalies and inconsistent access patterns.

    Once you unlock this feature in the Preview Portal, then you sign into your Azure tenant and browse to the directory that you want to enable for Premium.



    This gives you the ability to customize branding. The branding is shown when users access webmail via or For more information on branding see Alex Simon post here:


    Note: During the previous period, users will need to Opt-In by clicking on this link to view customized branding 

    The Advanced Reports seem like they would be relevant for most security administrators to review periodically.I predict what feature request is coming next: Alerting or scheduled emails of these reports =)




    And it also unlocks the password reset feature. Right now this is an all or nothing toggle, however, the technet page for this feature says that the ability to enable this for specific users is coming soon.


    To perform a self-service password reset

    1. Go to a page that uses an organizational account. For example, go to and click Can’t access your account link.

    2. On the Reset your password page, enter the user ID and captcha

    3. If the account is on-premise only (ADFS) then the following message will appear:

    4. Otherwise, for cloud accounts then the user will receive notification.


  • How to Manage Azure with On-Premise Active Directory

    When you sign up with a Windows Azure account, by default it creates an instance of Active Directory that resides in Windows Azure only called Windows Azure Active Directory (WAAD).  This is the same exact infrastructure that underlies Office 365. This blog post describes how to change Azure to leverage your existing Office 365 WAAD Instance.  You can then take advantage of your existing DirSync and ADFS servers to sign into the Azure Management Portal rather than using a Microsoft Account (Formerly Windows Live ID).

    This is ideal for large enterprise customers who desire to have all authentication performed from Active Directory, so that if administrators leave the organization, they have one place to disable the account rather than multiple places.

    For a quick 10 minute video overview of how this works, I recommend watching ”What is Windows Azure Active Directory”

    The first step is to sign into the Windows Azure Management Portal:

    Then click on Active Directory from the left navigation menu,  and then click Add.


    You then choose ‘Use existing directory’


    Then check the box ‘I am ready to be signed out now’


    You will then be directed to a login page to sign in with your Office 365 organization ID (which should authenticate you with ADFS if you have that enabled).

    If you are managing your Windows Azure Subscription with a Microsoft Account (Formerly Windows Live ID) rather than an Organizational ID, then you will be prompted for confirmation that you are okay granting your Microsoft Account (Formerly Windows Live ID) with Organizational Admin rights over your Office 365 directory.

    The next step is to click on the Settings icon on the left navigation pane in the Azure Management Portal.


    Then click on the subscription you want to change the directory to the new o365 WAAD directory.


    You can then change the directory


    Note: The behavior of this screen is a little different than what you may expect. For example, in the drop-down box I was expecting to see a list of all my directories and then I could select the one I wanted. Instead, it assumes you don’t want to select your existing directory and so that option won’t be listed.

    Adding an Administrator

    Adding an administrator is the same as before but now you have the option of selecting the Organizational ID as an option.


    That’s it – you can now sign in using ADFS to manage Azure.

    Configuring Windows Azure Active Directory for 3rd Party Single Sign-On

    You can add 3rd party applications like Yammer, Twitter, Skype, etc to be enabled for Single Sign-On using WAAD integrated through your on-premises Active Directory. Users can access these applications through the new Azure Access Panel.

    Windows Azure AD supports two different modes for signing onto 3rd party applications:

    • Federation using standard protocols
    • Password-based single sign-on

    Federation-based single sign-on

    Configuring Federation-based single sign-on enables the users in your organization to be automatically signed in to a third-party SaaS application by Windows Azure AD using the user account information from Windows Azure AD. In this scenario, when you have already been logged into Windows Azure AD, and you want to access resources that are controlled by a third-party SaaS application, federation eliminates the need for a user to be re-authenticated. Federated SSO is available for end user browsers which support JavaScript and CSS.

    In this release of WAAD, the following applications support Federation-based SSO:


    Citrix GoToMeeting

    Google Apps



    Office 365 Exchange Online and SharePoint Online

    Password-based single sign-on

    Configuring password-based single sign-on enables the users in your organization to be automatically signed in to a third-party SaaS application by Windows Azure AD using the user account information from the third-party SaaS application. When you enable this feature, Windows Azure AD collects and securely stores the user account information and the related password.

    Password-based SSO relies on a browser extension to securely retrieve the application and user specific information from Windows Azure AD and apply it to the service. Most third-party SaaS applications that are supported by Windows Azure AD support this feature.

    For password-based SSO, the end user’s browsers can be:

    • IE 8, IE9 and IE10 on Windows 7 or later
    • Chrome on Windows 7 or later or MacOS X or later


    Testing out Yammer with Password-based single sign-on

    To try it out, I am going to add Yammer to the Active Directory applications. In this release of WAAD, Yammer only supports ‘Password-based single sign-on’ and not Federation-based SSO.

    Note: If you already have ADFS on-premise, that is the recommended SSO integration for Yammer, as that is a better end-user experience than Password-based SSO. For information on configuring Yammer with your on-premise ADFS, see the Yammer SSO Implementation guide here: 


    The first step is to add Yammer to my Applications. So within Azure, click on the Active Directory icon from the left navigation pane

    Then click on the Directory that you just added.

    Then click on the Applications tab

    Then click Add

    Select ‘Add an application for my organization to use’

    Click on the Social Category and select Yammer

    After adding Yammer, the next step is to assign which users will be assigned this application for SSO on their Access Panel.

    As of this writing I am not aware of any powershell cmdlets for automating the assignment of users to applications. I checked the WAAD Powershell reference, which is where I would have expected to find those commands. Please email me at Joe.Stocker AT if you are aware of cmdlets to manage this and I will update this post. thanks! 


    After highlighting a user(s) click the Assign button at the bottom of the screen

    You will be prompted with an option of entering their Yammer credentials on their behalf. Otherwise the user will have the option of entering their password themselves later.

    Note: The Access Panel is a web-based portal that allows an end user with an organizational account in Windows Azure Active Directory to view and launch cloud-based applications to which they have been granted access by the Windows Azure AD administrator. For more information about the Access Panel see

    During the preview period for Access Panel, the following URL must be distributed to all users who will be signing into applications integrated with Windows Azure AD.

    For example, for my user account, I have access to Exchange Online, SharePoint Online and Yammer. Therefore I see all three applications on my Access Panel.

    I can then click on the settings icon in the bottom-right of Yammer to configure my current Yammer username and password.

    When clicking Update Credentials I am then prompted to install some software.

    This will prompt the user to download ‘Access Panel Extension.msi’ (1.53MB)

    You are then brought to a Post Installation screen to insure you enable the add-on when prompted.

    In my case, running Internet Explorer 11 on Windows 8.1, I had to manually enable the Add-on.

    Now when I go back to step 1 to store my Yammer credentials, it allows me to do so.

    Now when I click on the Yammer Icon, I am brought right into Yammer with no prompts.


    Note: If a user’s credentials change in a Password-based single sign-on application like Yammer, the user must update their credentials in the lower-right of the application tile, and select “update credentials” to re-enter the username and password for that application.

    Linux runs faster on Windows Azure than Amazon or Rackspace Openstack!

    I recently reviewed a detailed comparison of the top 5 IaaS cloud providers and it listed Windows Azure as having the best overall value (both in cost and performance).

    The interesting thing about the comparison is they used a benchmarking tool called Unixbench running on Ubuntu linux.

    The irony of a Linux distribution running better on a Windows cloud platform than Rackspace Openstack which itself uses linux is just too awesome not to highlight and draw attention to!!

    The full article is here and I highly recommend it.