Often when speaking with customers, there is a large discussion about what reverse proxy is used for Skype for Business deployments, cost of them and network dependencies. Experience has taught me that reverse proxies often take up far too much time on the discussion table because customers usually do not understand their need. They view these as nothing more than pass-thru devices and fail to understand or “buy in to” the edge network protection they provide when deployed properly. But Skype for Business requires one, so in the end its a choice, external meetings and mobility, or not?
Customers then ask for the cheapest solution and until now we are limited to WAP and KEMP as official qualified devices. Both have disadvantages. WAP has a dependency on ADFS which is a big turn off to customers who do not have a requirement for ADFS beyond simple reverse proxy. KEMP can be quite an expensive solution depending on throughput and high availability requirements.
So I have been looking for an alternative, cheaper, easier solution and as a result have been playing around with Azure AD Application Proxy. I admit this is not a qualified solution, but neither is Netscaler, IIS ARR and TMG, but we still use them… I would always advise to use qualified solutions for full end to end support.
There is a big difference between “it works” and “it works properly”
That said, I wanted to find out if Azure AD Application Proxy “works”.
What is Azure AD Application Proxy?
It is a service available in Azure AD Premium that allows us to publish internal web applications to the internet securely without having to provision external access to a particular server using NAT, Firewall rules and our own hardware. This got my attention for a few reasons.
- Azure AD Premium is part of the EMS bundle in Office 365 which many customers are taking advantage of in other workstreams and therefore I can continue to maximise their investment in that subscription
- The benefit of not having a requirement to provision a public IP, involve the network security team to configure NAT and firewall rules and less on-premises hardware to provision means deployment speed can be increased
- As the customer is not opening access to their network / device directly, the network is protected from attacks and this risk is offloaded to Azure
- Azure is by design highly available, so no need to purchase multiple hardware or potential software licences for HA
In order to use Azure AD Application Proxy, you need one user licenced for Azure AD Premium. Application Proxy is available on the free or basic version of Azure AD, but the type of proxy we need for this solution is only available in the Premium version. The cost of Azure AD Premium is about £5.50 per user per month, and we only need one licence. Therefore, at £60 per year this makes this the cheapest reverse proxy solution you can buy.
As I mentioned before, the Azure AD Application Proxy requires no on-premises networking configuration or hardware. However, it does require port 443 outbound to the internet from the Skype for Business Front End Servers. There is an Azure AD Application Gateway, or connector to install on the front end servers. This is a light weight installation that requires the Azure AD Premium licenced and Global Administrator credentials to login and connect to the Azure AD service. As this is an outbound only connection, the application uses Azure Service BUS messaging system to keep the outbound connection open to avoid connection sleeping.
You also need to ensure you have your UCC SAN certificate exported with the private key to a password protected PFX file to upload to Azure AD in the same manner as if you would for an on-premises server.
As this service is connector driven, we cannot use on-premises hardware load balancer VIP as the connection source point from the on-premises systems to the Azure AD Application Proxy. The application connector must be installed on each front end server and rely on the Azure AD Application Proxy health indicator and round robin effect for HA to your on-premises front end pool. You could spin up an IIS ARR or WAP server in a DMZ and configure that as a reverse proxy to install the connector on. However, the benefit of Azure AD Application Proxy reduces to protecting your network from DDoS attacks etc that could hit your perimeter edge firewall and bring down multiple services. For some, this may be a selling point, but I would imagine for many, this would be an over engineered solution that adds unneccessary complication. For the rest of this blog, I will assume that the connector will be deployed to a front end server.
Visualising the Solution
Configuring Azure AD Application Proxy
Firstly, you must have an Azure AD Premium licence. If you do not have one, then you can apply for a free trial via the subscriptions shopping cart within Office 365. Once acquired, assign this to your global administrator user. Once assigned, you must sign out of Office 365 and sign back in for the licence to take effect. Please also note that it can take 15 minutes or more for your Azure AD to be upgraded to Premium.
- Login to https://manage.windowsazure.com and sign in with your global administrator account
- Click on Active Directory, then your AD name, then click the configure tab
- Scroll down to application proxy and click enabled, then press SAVE at the bottom of the screen
Creating Connector Groups
- From the same page that you are on from the previous steps click on Manage Connector Groups
- Give your group a name e.g. Skype. This will be used to group the connectors to particular application proxy applications later. Press the tick to confirm
Creating Application Proxy
- From the AD tab menu click Applications
- From the bottom of the page click Add
- Choose Publish an Application that will be accessible from outside your network (this is Azure AD Premium only option – the other two are available in Free and Basic)
- Give the application a name, this is for vanity only. In the internal URL enter https://lyncdiscover.mydomain.com:4443 and set the authentication mode to pass-through and press the tick
- Once created, click on the configure tab on the application page
- Scroll down to external URL and change the domain name from the msappproxy.net to your domain.com
- When changed you will notice an informational box providing you with your custom domain information. You will need this later for configuring your DNS so make a note
- Next, upload your UCC SAN certificate. This needs to be in a password protected PFX file that contains all intermediates and private key along with the certificate that has the Lyncdiscover, web service and Simple URLs as subject alternative names
- Next, assign the application to the connector group we made earlier. This will tell the Azure AD Application Proxy which back end server to send the request to.
- On the Translate URL headers option make sure that you tick NO. We want the application proxy to send the original headers to the front end servers in tact.
- Save your changes and then click the big back arrow to return to the application homepage. You now need to repeat the process for the simple URLs and web service URLs
Setting your Public DNS
- Using the custom domain settings provided to you in each application proxy e.g. lyncdiscover.mydomain.msappproxy.net enter these as CNAMES to your external DNS zone like so
Installing the Connector
- Now Azure AD Application Proxy is configured, we now need to download and install the connector to the front end server. From the application dashboard from one of the application rules you have created e.g. lyncdiscover click download connector (note: this button will be green if a connector has not been downloaded before).
- Accept the terms and download the application
- Launch the application installer on the front end server (you only need one connector installed, this will do all lyncdiscover, simple urls and web service applications).
- When prompted sign in with your Azure AD Premium Global Administrator account
- The setup will now complete.
- Once installed, go back to manage.windowsazure.com and to your Azure AD. Click on the configure tab
- Scroll down to application proxy settings and click Manage connectors
- Assign the connector to the Skype connector group we created and assigned to the lyncdiscover, web services and simple URLs and press the tick button
- This now completes the setup of the Azure Application Proxy service as a reverse proxy for Skype for Business.
Testing the Solution
- Test you are able to connect to Lyncdiscovery service by typing in your browser https://lyncdiscover.mydomain.com/autodiscover/autodiscover.svc and you should receive and XML redirect
- Now lets try the dialin simple URL https://join.mydomain.com/dialin
- Now the meeting URL https://join.mydomain.com/meet
- Let’s check mobility access
- One last test using https://testconnectivity.microsoft.com
Warning is about the certificate root CA of my certificate not being deployed as part of Windows update. This is normal in many cases if you are not using a tier 1 SSL provider, but shouldn’t cause any problem
- Let’s try a meeting join in Skype between my lab account and my work account using internet federation
- Let’s try signing in from an external source using autodiscovery
Summary and Thoughts
As I have demonstrated here, it is possible to use Azure AD Application Proxy as a reverse proxy solution for Skype for Business server. The first thing you may be thinking is this is not supported, and you are right! The reason why I chose to post this blog and guide is purely an experiment and in a proper deployment all efforts should be made to use a qualified solution. However, there are many customers that chose to ignore advice, or seek their own workarounds due to budget or technical limitations of their network at the time, so in some circumstances this may be an option for them to consider if supportability is a low priority.
Evaluating this in a lab environment will always give less than real world results, and I have to say that initial testing in my lab with limited resources initial connection establishment is about 1 to 2 seconds slower than having your own on-premises reverse proxy solution (benchmarked against a KEMP VLM). However, once the connector is fully operational there is no performance loss against an on premises solution that is noticable anyway. The backend Azure service egress point for my testing in Azure even though my tenant is located in North Europe in Ireland, it looks at though the Azure AD Application Proxy endpoint for me is actually located in West Europe (Holland) according to the public IP assigned to the Azure Service. This may introduce some latency (negligable) over https traffic (not voice!).
I can see this solution working for Standard Edition deployments more than enterprise edition if I am honest. The deployment process is suited to a single server solution rather than multiple, load balanced solutions. I have not test enterprise edition against this and have some unknowns on how Azure AD Application Proxy handles load balancing multiple connectors.
Failover scenarios is much the same as a normal reverse proxy solution, but is actually quicker using this method than the traditional on-premises solution. In a failure scenario you would just assign the standby front end pool connector to the production live connector group and deallocate the failed front end server connector to a standby (unused group) and the change over will be instantanious rather than messing around with DNS records and reverse proxy rules etc.
This solution cannot be used for your Edge servers, so this does not negate the need for them or a DMZ network, this service is purely a http proxy solution.
For the money it costs to use this service it is an absolute bargain and would be very attractive to SMB. Would I deploy it to a customer site? At the moment not for production due to lack of support but for a small scale proof of concept then this is a great little way of improving rapid deployment timescales. It will be interesting for sure to watch this product develop to see if Microsoft actually bring this solution under support for Skype for Business. For now the solution “works”, but I am hesitant to say it “works properly” at this moment.