Just a short blog on a topic that we have heard a lot of requests for and that we’ve been working on, in conjunction with the Lync Product Group, over the last months.

We’re pleased to be able to announce that Web Application Proxy in Server 2012 R2 has successfully passed the Microsoft UCOIP (Unified Communication Open Interoperability Program) Reverse Proxy Qualification for Lync Server 2013.

The listings of Infrastructure qualified for Microsoft Lync can be found at the following link with Web Application Proxy listed in the Reverse Proxy section - http://technet.microsoft.com/en-us/office/dn788945

The detailed Web Application Proxy configuration guide for Lync Server 2013 can be accessed here - http://www.microsoft.com/en-us/download/details.aspx?id=44940

This is great news and will hopefully be of assistance with your deployments. As always, please let us know if you have any questions or feedback.

Ian Parramore, Senior Escalation Engineer, Web Application Proxy support team

A big thanks also to the following for helping drive the validation testing from the Lync Product Group side of things:-

Dave Howe, Senior Product Manager, Skype Business Services - Customer Engineering

Today we are announcing General Availability (GA) of Azure Active Directory Application Proxy! This is a big step for the service and we have done many fixes and improvements under the hood to take it to a level of reliability, performance, security, and scale that is suitable for your business use. General Availability also means that we back this up with Service Level Agreement (SLA).

We have seen amazing interest in the service during the preview months. Several thousands of tenants activated the preview and published applications. They generated more than a million HTTP transactions. We want to thank all of them. It allowed us to tune it and to get it to where we are today.

And not only are we announcing the General Availability of the service, but we are also adding new capabilities that will enable you to publish almost any on-prem application, will also improve your admin experience, and will increase the value of the service. Below we name some of these capabilities.

Single sign-on to backend applications using Kerberos Constrained Delegation (KCD)

Application Proxy can already preauthenticate users before they are granted access to the on-prem application. With the new capability it will also be able to authenticate users to the backend application, so no additional sign-ins are required from them. This allows a smooth and seamless access experience to on prem Integrated Windows Authentication (IWA) applications – users only need to enter their credentials on the cloud and they will be able to access all these on-prem applications without having to sign-on again to each one of them.

Admins can now add their on-prem SharePoint, Outlook Web Access, or any other Web application that supports Integrated Windows Authentication, to Azure Active Directory without changing them. There is no need to install anything on the applications servers. Just enable Kerberos Constrained Delegation (KCD) on the connector machine and you’re done.

Behind the scenes, the connector is using the Kerberos delegation capabilities to impersonate as the end-user toward the application. From the application point of view, this is just a regular user. The complexity is invisible for the applications and for the end-users that can use whatever device they want and still have single sign-on to these applications.

In the current release, the proxy assumes that the same user identity (UPN) exist both on-prem and on Azure Active Directory. In future releases we are going to address more complicated configurations.

Connectors are auto-update from the cloud

The first step to enable the application proxy is to install its connectors on machines that are connected to the corporate network. We view these connector not as a traditional box product but as an extensions of the cloud service that operates like a cloud service. The connectors are already stateless and pulling all their configuration and settings from the cloud service. We want to take this one step further by removing the need to update these connectors manually. The new Application Proxy connectors will constantly check to see if there is a new version and will apply the update gracefully with minimal down-time. If you are running more than one connector, the service will not be interrupted. In the future, the service will give you more control on the update policy and more visibility on the status of your connectors.

This is just the first step in a long journey we are taking to get to a zero on-prem maintenance for the connectors. Our long term goal is that once installed, you would never have to log into these machines. We will give you all the tools to control them from the cloud.

As a result of this change, we ask our existing customers to uninstall their existing connectors and to install the new connector version. The preview connectors (versions before 1.2) will stop working soon. This would be the last time you manually have to do this, from now on, we will update it automatically.

Enable Application Proxy for Azure Active Directory Basic users

Right now the Application Proxy service is available only for Azure Active Directory Premium users and administrators. Starting in the coming weeks we will gradually enable the service also for Azure Active Directory Basic users. We are doing this to enable companies to provide access to their on-prem applications to more and more users removing the need to have additional reverse proxy solution.

We don’t stop here! Our team works full steam ahead on improving the service and adding more capabilities to make sure you can move your remote access to Azure Active Directory. We are going to carefully examine the service usage patterns to understand what you are trying to do and what is blocking you. We are already working on bunch of new capabilities that would be delivered in the near future. Here are some of them:

1. Custom domains: publish applications with your own domain and SSL certificate so you can have external address like app1.contoso.com and not only app1-contoso.msappproxy.net.

2. Path filtering: publish only part of the server using path. For example, allow access to sp.contoso.com/site1 and not to any other paths on the server.

3. Office clients integration: Improved experience when triggering Word, PowerPoint and Excel from a Web page or a link.

4. Connector management and monitoring from the cloud to put the admins in control.

We are going to have additional posts on these new features soon. As usual, we are always happy to hear your feedback. Send us an email to aadapfeedback@microsoft.com.

Meir Mendelovich and the application proxies team

We’ve come across some specific behaviours of AD FS Home Realm Discovery and Non-Claims Aware Relying Party Trusts we wanted to share as it’s something you might come up against in your deployments.

What are the Symptoms of the Issue?

If you create a Non-Claims Aware Relying Party Trust using PowerShell you will find that end users are not offered Home Realm Discovery. If you do want to federate authentication this will cause you an issue.

If you create a Non-Claims Aware Relying Party Trust using the AD FS Management Console, full Home Realm Discovery is offered to the end user. If your users are authenticating against local Active Directory this might cause some confusion and add an additional step to the authentication flow.

Let’s first cover off a couple of key concepts around this and then look in more detail about what is going on and why.

What is Home Realm Discovery?

By default, an AD FS server will have one Claims Provider Trust for the local Active Directory but, if you have federation partners or a central broker service, you will have added additional Claims Provider Trusts in AD FS. These are then available as alternate identity providers for user authentication.

Home Realm Discovery (HRD) is an AD FS feature where the end user gets to choose which Authentication Provider they want to authenticate against from the available Claims Provider Trusts e.g. users from a partner organization would choose their companies authentication server from the list. The user would then be directed to the relevant Identity Provider to authenticate.

A users Home Realm Discovery choice is then cached via a cookie so that they don’t have to go through the HRD selection each time they come to AD FS to authenticate.

What is a Non-Claims Aware Relying Party Trust?

A Non-Claims Aware relying party trust is a specific type of AD FS Relying Party used by Web Application Proxy to publish a web application that uses Windows Integrated Authentication.

After the user has authenticated with AD FS and obtained their Web Application Proxy authentication token, Web Application Proxy then carries out authentication delegation to the published server using Kerberos Constrained Delegation.

Please see the following article for more details on setting on and configuring a Non-Claims Aware relying party trust and the associated Kerberos Constrained Delegation requirements - http://technet.microsoft.com/en-us/library/dn280943.aspx

Selective Home Realm Discovery

For a standard Relying Party Trust AD FS provides a way to limit the Claims Provider Trusts that are used for that specific relying party. This can be very useful where you have multiple Claims Provider Trusts but have applications that will only be used and accessed by specific partners.

This can be set using PowerShell using the ClaimsProviderName property of a Relying Party Trust. Please see the ‘Configure an identity provider list per relying party’ section of the following article for details on how to configure this - http://technet.microsoft.com/en-us/library/dn280950.aspx

So, what’s the problem?

It’s not so much that there is a problem more that there are some specific design behaviours you need to be aware to give you the Home Realm Discovery behaviour that meets your needs.

- It is not possible to control the Claims Trust Providers for a Non-Claims Aware relying party trust

The first part of the issue to be aware of is that a Non-Claims Aware relying party trust does not provide the ability to control the Claims Provider Trusts used for the relying party as you can for a standard claims based Relying Party Trust. This is intentional and by design in AD FS Server 2012 R2.

- If you create a Non-Claims Aware relying party trust through PowerShell is will be restricted to the Active Directory Claims Provider Trust

For a Non-Claims aware application, as Web Application Proxy will be carrying out Kerberos Constrained Delegation (KCD) to the published server, this requires the user account to be available as a user identity in the local Active Directory. As such, the expectation was that the users would be authenticating against the local Active Directory.

This leads us on to the second part of the problem which is that if you create a Non-Claims Aware relying party trust via PowerShell then the relying party will get automatically restricted to the local Active Directory claims trust provider.

This means that Home Realm Discovery (HRD) will not be offered to users.

As there is only one Claims Provider Trust configured on the relying party, HRD will be skipped and the user taken to authenticate against the local Active Directory.

There are scenarios where you may be federating authentication from ADFS to a Centralised Authentication Broker or where you are federating out to a partner organization and using Shadow Accounts for the Kerberos Constrained Delegation. In these case you would want to authenticate against other Claims Provider Trusts and have these available as part of Home Realm Discovery.

- If you create a Non-Claims Aware relying party trust through the AD FS Management Console it will not be restricted by Claims Provider Trust

Conversely, if you create a Non-Claims Aware relying party through the AD FS Management console it will not have any Claims Provider Trust restrictions placed on it.

This means Home Realm Discovery will be offered to users with all available Claims Provider Trusts offered in the HRD list.

This is good if you do want to federate authentication but perhaps not so good if you are just authenticating users against local Active Directory and would like to eliminate the Home Realm Discovery steps for your Non-Claims Aware applications.

Note – it is not possible to have a subset of Claims Trust Providers displayed in the Home Realm Discovery for a Non-Claims Aware application

The good thing is that you have choices here and you can use either PowerShell or the AD FS Management Console to create a Non-Claims Aware relying party trust based on your needs.

This is something we’ve discussed with the AD FS Product Group and this is an area they will look at as part of their Server vNext development work.

Summary

If you are publishing Non-Claims Aware applications through Web Application Proxy you may find that the Home Realm Discovery behaviour of AD FS doesn’t meet your requirements.

There are some specific behaviours around the Claims Provider Trust restrictions and Home Realm Discovery to be aware of to ensure you get the behaviour you are looking for.

Use PowerShell to create the relying party if:-

- Your users will all authenticate against the local Active Directory

- You want to skip Home Realm Discovery for the relying party

Use the ADFS Management Console to create the relying party if:-

- You are federating authentication to other Identity Providers

- You want users to have Home Realm Discovery

Hopefully this will help save you some time and confusion around Claims Provider Trust restrictions and Home Realm Discovery behavior for Non-Claims Aware relying party trusts to help with your deployments.

Ian Parramore, Senior Escalation Engineer, Web Application Proxy support team

Since the service became generally available in December we got an overwhelming feedback from customers and partners. We are very happy to see real traffic from the first customers and are working on improving the service and implementing some of your suggestions.

In the last few days several changes have been rolled out:

Improved SharePoint & Office experience with MSO-FBA

Microsoft Office Form Based Authentication (MSO-FBA) is an authentication protocol that allows Office clients such as Word, PowerPoint and Excel to authenticate to SharePoint servers. We have made several changes in Application Proxy to support MSO-FBA to improve the experience.

The relevant scenarios include opening  a document using Office client applications from within SharePoint Web pages and opening documents stored in SharePoint directly from Office clients, without Web interaction, e.g. opening documents from the “most recently used” list.

Allow to disable host translation

We have added a new application configuration option to disable host translation in request and response HTTP headers:

By default, Application Proxy connectors are replacing the hostname in the request headers that are sent by the client device to the hostname of the backend server:

When this translation is disabled, the original hostname will be sent to the backend applications instead of the one that correspond to the backend application hostname:

Similar process also happens in the HTTP response headers.

In some scenarios, it is useful to have the original host header to differentiate between an internal traffic and traffic coming from Application Proxy. This is the case with some SharePoint Alternate Access Mapping (AAM) configurations.

We found out that many customers were replacing their Forefront UAG and Forefront TMG with Azure AD Application Proxy. These products had this option turned on by default and therefore, many backend applications in such organizations accepted this type of requests. By adding this control to Azure AD Application Proxy we allow these organization to upgrade without making any change to backend applications. We are happy to provide smoother installation and UAG/TMG migration enablement options and looking for more cases like that.

License adjustments

As we promised, we have enabled Application Proxy also for users that have the Azure Active Directory Basic license.

Application Proxy license requirements for end users are enforced in two places:

1. In the Access Panel - only users with appropriate license will see tiles for proxy applications

2. When Application Proxy is pre-authenticating a user for a proxy application, it is verifying that she has appropriate license.

This is validation is on top of the regular authorization rules such as users assignment to application or access rules.

As part of this process we made our licensing enforcement more robust and revised some of the error messages so they would be more meaningful and provide accurate information for the end users and IT admin.

Under the hood

All of the above changes have a clear impact on the end-user and admin experiences. At the same time, we are also making lots of changes under the hood to assure the service is working properly, at scale, and adhere to the topmost security standards. We constantly measure the service performance and try to find ways to improve it.

One such change is starting to use Azure Service Bus Relay to establish connectivity between the connectors and the Service. This slightly change the networking patter since the connector now uses for outbound traffic also port 9352 to the Azure data center. Ports 20200-20210 that are currently used will be deprecated over time. Customers doesn't need to update their connectors as the connectors automatically update themselves.

As usual, we would be happy to hear your feedback and suggestions. Our inboxes are full with emails coming from this blog – and we LOVE that.

We have several big and highly desired features that we are currently working on and will be made public over the coming weeks. We will keep you posted via this blog and the AD team blog.

We have a very busy week with lots of announcements!

Today we are announcing that Azure AD Application Proxy now support publishing Windows Server Network Device Enrollment Service (NDES). This is useful for Intune and System Center Configuration Management (SCCM) deployments. Customers that purchase the Enterprise Mobility Suite (EMS) that includes both Intune and Azure AD Premium can deploy Intune now with no DMZ requirements. You can read more about it here: http://blogs.technet.com/b/ems/archive/2015/02/25/part-4-protecting-ndes-with-azure-ad-application-proxy.aspx

NDES protocol have unique networking patterns as it utilizes very long URL parameters. We had to change the service to accommodate this kind of traffic.

There are more news coming in the next weeks - stay (In)tune.

Microsoft is the only vendor that offers both on-premises and cloud solutions for remote application access. Not only do we offer both, we also work hard to keep these solutions current and continue improving them all the time. We have recently released many enhancements to Azure AD Application Proxy and we announced our Windows Server Web Application Proxy vNext with many new capabilities. It will be available next year as part of Windows Server vNext release. At the same time, we do not forget our current Web Application Proxy customers that are using Windows Server 2012 R2.

In this blog post, we document recommended hotfixes and update rollups you may not be aware of that are currently available for Windows Server 2012 R2 based Web Application Proxy and AD FS deployments.

The update rollup packages are cumulative so all rollups will include changes and features from previously released rollups. Hotfixes available will be included in later rollup packages that include updates for this role service (Web Application Proxy or AD FS). We recommended that you apply the Windows Server 2012 R2 update rollup packages as they become available in order to obtain all cumulative released hotfixes.

Please be aware that this is not a comprehensive list of all issues resolved in these Windows Server update rollups but only includes the changes directly related to the Web Application Proxy feature; please review the individual update rollup KB articles for a list of all included fixes.

Recommended hotfixes and update rollups that are currently available for Windows Server 2012 R2 based Web Application Proxy and AD FS deployments

Current hotfixes available since the last update rollup release:

Web Application Proxy hotfixes

• 3020813 You are prompted for authentication when you run a web application in Windows Server 2012 R2 AD FS
• 3025080 Operation fails when you try to save an Office file through Web Application Proxy in Windows Server 2012 R2

AD-DS related hotfixes

• 3018886 You are prompted for a username and password two times when you access Windows Server 2012 R2 AD FS server from intranet
• 3025078 You are not prompted for username again when you use an incorrect username to log on to Windows Server 2012 R2
• 3020773 Time-out failures after initial deployment of Device Registration service in Windows Server 2012 R2

There were no update rollups available for January or February 2015.

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update rollup: December 2014 http://support.microsoft.com/kb/3013769

Included in update rollup or later update release

• 3011137 SSO error occurs upon your first visit to (SAML) 2.0 websites through ADFS 3.0 that is enabled in Windows Server 2012 R2
• 3011135 Large URI request in Web Application Proxy fails in Windows Server 2012 R2
• 3009351 AD FS Proxy could not be configured error in WAP post-installation configuration wizard in Windows Server 2012 R2
• 3008990 Update to let you log off successfully from AD FS 3.0 server in Windows Server 2012 R2

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update rollup: November 2014 http://support.microsoft.com/kb/3000850

Previous hotfixes included in this update rollup release

• 2982037 Update to enable or disable the HttpOnly feature for a WAP or an application in Windows Server
• 2998082 gMSA-based services can't log on after a password change in a Windows Server 2012 R2 domain

There were no Web Application Proxy or AD FS changes in the Windows Server 2012 R2 update rollups for September or October 2014

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update rollup: August 2014 http://support.microsoft.com/kb/2975719

Included in update rollup or later update release

• 2976996 Expired certificates cannot be removed when automatic certificate rollover is disabled in Windows Server 2012 R2
• 2975066 You cannot sign in to a web application when you use certificate authentication method in Windows Server 2012 R2
• 2971171 ADFS authentication issue for Active Directory users when extranet lockout is enabled 
• 2978096 ExtendedProtectionTokenCheck setting keeps being disabled in AD FS 3.0 in Windows Server 2012 R2 
• 2975719 You are prompted to re-enter credentials frequently when using Work Folders by using ADFS authentication in Windows 8.1
• 2980756 You cannot log on to an AD FS server when you use an alternative UPN suffix account in Windows Server 2012 R2
• 2975070 AD FS cannot start on a non-English language-based server in Windows Server 2012 R2 or Windows Server 2008 R2
• 2975067 Update to support the SAML sender-vouches token in STS on a Windows Server 2012 R2-based AD FS server
• 2958298 Single Sign-On is available for Office 365 users to access SharePoint Online sites in Windows 2012 R2

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update rollup: July 2014 http://support.microsoft.com/kb/2967917

Included in update rollup or later update release

• 2970746"Profile Installation Failed" error when iOS device is workplace-joined by using DRS on a Windows Server 2012 R2-based server

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update rollup: June 2014 http://support.microsoft.com/kb/2962409

Included in update rollup or later update release

• 2964732 STS passive sign-in fails when a sign-in request is sent to a Windows Server 2012 R2-based STS server through STS proxy
• 2964733 AD FS device authentication is slow or fails in Windows Server 2012 R2
• 2964735 Authentication failures and event 422 when AD FS STS servers and AD FS proxy servers are in Windows Server 2012 R2

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update rollup: May 2014 http://support.microsoft.com/kb/2955164

Included in update rollup or later update release

• 2935613 Authentication fails when a device is Workplace Joined by using Azure DRS
• 2935608 Web Application Proxy cannot detect the updated certificate after it automatically updates on Windows Server 2012 R2
• 2948086 Update that improves AD FS proxy and STS reliability in Windows Server 2012 R2 when multiple clients sign in

Required servicing update for Windows Server 2012 R2

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 Update: April 2014 http://support.microsoft.com/kb/2919355

This update is a cumulative update that includes the security updates and the non-security updates for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 that were released before March 2014.

• Important : All future security and nonsecurity updates for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 require this update to be installed.

We’re happy to have another post from guest blogger Mark Grimes with Microsoft Consultancy Services. Mark has some more great tips for documenting and saving your Web Application Proxy deployment settings for future reference and backup…

Backup your Web Application Proxy Settings – Mark Grimes

Whenever I install Web Application Proxy at a customers’ location, I like to leave some breadcrumbs behind so that they know what was done, how it was configured, and how to reuse that information when possible. By doing the installation, configuration and application publishing with PowerShell, your backup and preservation of settings is done for you. While it is very easy to do installation and configuration through Server Manager and then publishing through the Remote Access Management tool, you don’t get the documentation of what you did in the same way as PowerShell will do for you by virtue of just saving the scripts. Get in the habit of doing all of your installation and configuration with PowerShell and your settings will be saved automatically.

There are three parts to this blog.

1. First we will provide summarized PowerShell cmdlets to install, configure and publish with Web Application Proxy.

2. Outline the primary PowerShell cmdlets to gather information about the Web Application Proxy’s Settings.

3. Wrap it all up with a few combined tips and tricks to create a webpage for the Web Application Proxy configuration.

Documenting the Installation and Configuration of Web Application Proxy

Whenever you install and configure Web Application Proxy, if you do this all with PowerShell, you not only have a nice succinct backup of the process, but also a simple to reuse operations guide for your Web Application Proxy Deployment. In the PowerShell cmdlets below, I highlighted in yellow the parts you will need to change.

Key Assumptions before the core installation and configuration scripts are run below

1. A Windows Server 2012 R2 AD FS Environment is in place

   See Deploying a Federation Server Farm for “how to

2. Web Application Proxy Infrastructure is all in place e.g. Active Directory, DNS, addresses, etc. 

3. Configuration of CAs and certificates has been completed i.e. AD FS Federation Certificate with the private key exists in the Certificate Local Machine store certlm.msc

   See Install and Configure the Web Application Proxy Server

   Likewise, for any applications to publish, it will be assumed that their certificates are also installed with the private keys in certlm.msc as well

4. To understand more about the differences between publishing applications below with Preauthentication or pass-through se

   Publish Applications using Client Certificate Preauthentication

   Publish Applications using Pass-through Preauthentication

Core Installation and configuration

While all of these bits and pieces are well documented throughout TechNet, this section will just collect, collate and summarize only the PowerShell portions for the purpose of documenting and backing up all of the installation and configuration. You can then reuse these for multiple pre-production and production deployments.

NOTE: Even the titles below are #commented out so you can just copy and paste everything between the dotted lines into the PowerShell ISE Script pane to save, modify and reuse. All you need to modify are the highlights.

#1 Declare Environment Specific Installation Variables

$fscred =get-credential #administrator account w/ local admin rights on AD FS server

$CertCN = "*.contoso.com" # This is the AD FS Federation Service Certificate CName

$FedSvcName = "sts.contoso.com" # This is the AD FS Federation Service Name

$CertThumbPrint=Get-ChildItem-PathCert:\LocalMachine\My|where {$PSItem.Subject -like$CertCN } |Select-ExpandPropertyThumbprint

#2 Install Web Application Role

Install-WindowsFeatureWeb-Application-Proxy-IncludeManagementTools

#3 Finish Web Application Proxy Configuration    # Assumes App Certificate is in certlm.msc

Install-WebApplicationProxy–FederationServiceTrustCredential$fscred-CertificateThumbprint$CertThumbPrint-FederationServiceName$FedSvcName

# Publish Passthrough Applications – copy for each app published and adjust

$AppCert="app1.contoso.com"# The App Certificates’ CName for each app published

$AppCertThumbPrint=Get-ChildItem-PathCert:\LocalMachine\My|where {$PSItem.Subject -like$AppCert } |Select-ExpandPropertyThumbprint

#4 Publish Passthrough Application

Get-ChildItem-PathCert:\LocalMachine\My|where {$PSItem.Subject -like$AppCert } |Select-ExpandPropertyThumbprint

Add-WebApplicationProxyApplication-BackendServerUrlhttp://app1.contoso.com/-ExternalCertificateThumbprint$AppCertThumbPrint-ExternalUrlhttps://app1.contoso.com/-Name"Passthrough Test 1 Application"-BackendServerCertificateValidationNone-ExternalPreauthenticationPassThrough

#5 Publish Client Certificate Preauthentication Application #Need to know corresponding AD FS Relying Party Trust per application

$PreAuthAppCert="PreAuthApp.contoso.com"# The App Certificates’ CName for each app published

$PreAuthAppCertThumbPrint=Get-ChildItem-PathCert:\LocalMachine\My|where {$PSItem.Subject -like$PreAuthAppCert } |Select-ExpandPropertyThumbprint

$PreAuthRP=Get-WebApplicationProxyAvailableADFSRelyingParty|where {$PSItem.name -like"samp*" } |Select-ExpandPropertyName # Replace samp* with the AD FS RP trust name or the first part of it. NOTE: do just Get-WebApplicationProxyAvailableADFSRelyingParty to see what RP names are available

Add-WebApplicationProxyApplication-Name"PreAuth Sample Federated Application"-ExternalPreauthenticationADFS-ExternalUrlhttps://sampapp.Contoso.com/sampapp/-ExternalCertificateThumbprint$PreAuthAppCertThumbPrint-BackendServerUrlhttp://app1.contoso.com/sampapp/-ADFSRelyingPartyName"$PreAuthRP"

Once you update the highlights above, you have both an operations guide to install and configure your Web Application Proxy environment, plus it is all documented in your PowerShell scripts. For those of you with advanced PowerShell skills, this will make a starting point to do even more advanced script options e.g. simplifying publishing of multiple applications.

Basic Web Application Proxy Server configuration and health cmdlets

Now that you have installed and configured your Web Application Proxy servers, let’s look at some of the core PowerShell commands to get information about the Web Application Proxy Servers and the state of their health. We’ll list just a few as samples that have been found in various blogs and TechNet Articles. Then we’ll combine them all together in the last section to make a nice consolidated webpage to backup most all of the key Web Application Proxy server configurations.

• Get-Service 'appproxysvc','appproxyctrl','adfssrv' | fl -property *

  This is a great command to show Web Application Proxy Windows services status. But run it and you’ll likely get much more than you want or need. Reduce the number of properties displayed and you can control what you want

• Get-NetIPAddress -CimSession (New-CimSession -ComputerName ((gwpc).ConnectedServersName)) | ft IPAddress

  This example from one of our blog entries that shows the IP addresses for the Web Application Proxy Servers. In this example, I looked to add a few more useful properties such as the subnet mask and the interface name to benefit the network administrators who would want to know that information.

• Get-WebApplicationProxy*

  There are 5 of these by default to possibly use.

1. Get-WebApplicationProxyApplication

   This is a handy command if you never configured you published applications with PowerShell. This can be added to the web page below as an option. But you will also have the applications nicely backed up by virtue of installing them always with PowerShell.

2. Get-WebApplicationProxyAvailableADFSRelyingParty

   This is one that will be useful to have on hand when publishing. It shows the AD FS Relying Party trusts that exist. If you want to publish applications with preauthentication, this information is handy to have and can be piped out to input into the publishing cmdlets.

3. Get-WebApplicationProxyProxyConfiguration

   This will give a list of the connected Web Application Servers.

4. Get-WebApplicationProxyHealth

   This gets the health status of the Web Application Proxy server and the health of the Web Application Proxy services on the Web Application Proxy server. This includes the health status of Web Application Proxy Core as well as the AD FS Proxy

5. Get-WebApplicationProxySSLCertificate

   This gets the binding information for the AD FS SSL certificate that is installed and configured for the FS proxy component of the Web Application Proxy. 

Create a webpage to backup and display the health and configuration of Web Application Proxy

In many cases, PowerShell will give you far more that you may need or want. There are many PowerShell options to limit what is output as well as how the output is displayed or formatted. If you are a true programmer you can then take this and do even more sophisticated outputs and formatting.

Below, we will just give the PowerShell cmdlets used to make and display a sample webpage below. There is no explanation immediately within the cmdlets below. However, the sources for those tips and tricks to control what and how the output is presented are all in the Reference Links just below this section.

Get-WebApplicationProxyConfiguration|Add-Member-membertypescriptproperty-nameServersList-value {$this.ConnectedServersName -join'; '} -passthru-force|convertto-htmlServersList,ADFSUrl-title"WAP Stats"-body"<H2>Web Application Proxy Server | Connected Servers</H2>">C:\Webpage\WAPConfig.htm

Get-NetIPAddress-CimSession (New-CimSession-ComputerName ((gwpc).ConnectedServersName)) |convertto-htmlIPAddress,InterfaceAlias,PrefixLength-title"WAP Stats"-body"<H2>Web Application Proxy Server | IP Addresses</H2>">>C:\Webpage\WAPConfig.htm

Get-Service'appproxysvc','appproxyctrl','adfssrv'|convertto-htmlDisplayName,ServiceName,Status-title"WAP Stats"-body"<H2>Web Application Proxy Server | Services Status</H2>">>C:\Webpage\WAPConfig.htm

Get-WebApplicationProxyApplication|convertto-htmlName,ExternalURL,BackendServerUrl-title"WAP Stats"-body"<H2>Web Application Proxy Server | Published Applications List</H2>">>C:\Webpage\WAPConfig.htm

Get-WebApplicationProxyAvailableADFSRelyingParty|convertto-htmlName,Published,ID-title"WAP Stats"-body"<H2>Web Application Proxy Server | AD FS Relying Party Trusts</H2>">>C:\Webpage\WAPConfig.htm

Once you have run the scripts above, you will end up with a webpage like this:

As you will see from the reference links below, this is only one way to output this information. Now take the lines above, package in a PS1 file and add to a scheduled task and this will be a continuously updated view that can be accessed wherever you would like to publish it.

Taking these concepts a step further, using PowerShell, these tips and tricks can be applied across multiple services and applications. For example, Web Application Proxy’s big brother AD FS! But we’ll leave that one for the AD FS bloggers out there.

Reference Links

Here are the sources that I used to put the webpage above all together, to preserve the installation, configuration and settings of Web Application Proxy. If you have even more free time, and really want to read all of the nitty-gritty details, help yourself to these handy articles below.

• Web Application Proxy PowerShell Cheat Sheet– Web Application Proxy Blog

• Web Application Proxy cmdlets in PowerShell

• Redirecting Data with Out-* Cmdlets

• Using Format commands to change output view

• Using the Export-Csv Cmdlet

• Using the Convert-html cmdlets

• Hey Scripting Guy! Blog – Use the Windows Task Scheduler to Run a Windows PowerShell Script

Till the next time – Mark @ Microsoft

We have recently added two new highly requested capabilities to Application Proxy. This comes shortly after we improved SharePoint publishing and added support for Intune NDES. We will have more to announce soon…

Conditional Access

Conditional Access is the ability to define different access rules for applications based on the business needs, user location and the device that is used. For example, having some applications that only require username and password while others require multi-factor authentication when the user is not in the office and other applications that requires multi-factor authentication for every session.
Today we are bringing these capabilities to on-prem applications. Every pre-authenticated proxy application now also includes the access rules section:

See more details in this blog post: http://blogs.technet.com/b/ad/archive/2015/03/11/azure-ad-conditional-access-preview-updated-now-supports-on-premises-and-custom-lob-apps.aspx

Path Publishing

It is now possible to specify a specific path on the backend server that would be published while the rest of the server will not be published. This allows you, for example, to publish different sites located on the same sharepoint server with different names and access rules.
The path is specified in the internal URL field and will be visible in the external URL. We require the internal and external paths to be identical.
See “site1” in the below -

 
Another change we did in this release is to allow customers to change the application name as much as they want without changing the external URL or changing the external URL without changing the name. The application name is visible in the access panel portal. We are working to improve the control over the URLs and the appearance in Access Panel.

Azure AD Application Proxy requires a number of ports to be open to function correctly. These ports are needed for registering a new connector, to maintain the existing connectors and for the actual traffic. All of the traffic on these ports are outbound from the organization to Azure datacenters with no inbound connections created. You can find the networking prerequisites to enable Application Proxy services listed here: https://msdn.microsoft.com/en-us/library/azure/dn768214.aspx.

Several errors might occur if your organization firewall blocks any of these ports for external access. This would occur mainly during registration and when the connector needs to pull traffic from the cloud service.

An easy way to verify that your port connectivity is to open http://testport.cloudapp.net/ from a browser on the machine that runs the connector. If all ports have green “V” next to them, then you are good to go. Be aware that the user browser connectivity may differ from a service connection due to proxy configuration settings or authentication requirements. You may need to account for this with your testing.

If some of these ports are blocked, you need to ask the networking admin to open them for outbound traffic through the firewall or forward proxy. From our experience, most forward proxies handle this traffic correctly if the ports are enabled.

If your organization requires limiting the scope for the additional ports, you have three options:

1. Limit only to traffic coming from the connector machines.

2. Limit the traffic only to requests for the msappproxy.net domain name - if your firewall support such filtering

3. Enable only traffic to Azure data centers based on the destination IP addresses. As the service is spread across several different data centers for high availability and optimization, you must include all Azure datacenters IP range as specified here: http://www.microsoft.com/en-us/download/details.aspx?id=41653.
   

For more troubleshooting tips and tools look at our troubleshooting guide: https://msdn.microsoft.com/en-us/library/azure/dn768218.aspx

As part of our continuous efforts to make Azure AD Application Proxy the easiest remote access solution to manage, we have added functionality to view the list and status of its connectors from the Azure management UI. You can access the connector status page from the Azure AD configure tab:

In this list you can see the connectors that you have installed and registered to your Azure AD, and status:.

The information presented here is based on data collected on the control channel between the connector and the service. The connectors call this channel once every 10 minutes. If a connector called within this timeframe, it will be considered active, otherwise it will be considered inactive and the time of the last successful call will be indicated.

In the future, we would provide more management capabilities on the connectors. We would also provide more detailed health data using Azure AD Connect Health.

We would be happy to get feedback on this functionality. How is it working for you? Have you noticed inaccuracies? What else would you like to see in this page? Tell us using the aadapfeedback@microsoft.com e-mail address.

Microsoft Ignite is around the corner starting Mat 4th. We have lots of content for you on Application Proxy, Azure Active Directory and enterprise mobility in general. The application proxy session will take place on Tuesday May 5th 3:15pm. We have lots to show you!

There are many other sessions on relevant topics. I highly recommend Nasos Kladakis all-up session on Identity and Access Management and a session on Real customer stories for Azure Active Directory Premium. See here the full list of enterprise mobility sessions.

As usual, we are very happy to meet you and hear your feedback. Shoot us an e-mail to aadapfeedback@microsoft.com if you want to meet or just come to the enterprise mobility booth.

See you in Chicago

It is possible now to use your own custom domain as the domain name of your published application to make it more friendly for your users and create seamless remote access with the same internal and external URLs. See all details here: http://blogs.technet.com/b/ad/archive/2015/04/22/azure-ad-application-proxy-now-support-custom-domain-names.aspx

Hi,

Ignite ended a week ago. It was a very busy conference with lots of sessions and discussions. Thanks everybody who attended and engaged us.

For those who didn't attend, or want to watch again, there is lots of content available to watch on-line in Channel 9. Here is my list of recommended sessions:

• The most relevant session for readers of this blog is the App Proxy session: http://channel9.msdn.com/events/Ignite/2015/BRK3864

• Greg Taylor had (as usual) very insightful session on Exchange security challenge with App Proxy discussions on 0:29:00, 0:40:00 and 1:06:30: http://channel9.msdn.com/events/Ignite/2015/BRK3147

• This session has all you need to know on connecting your on-prem AD to Azure AD with lots of AAD Connect demos: http://channel9.msdn.com/events/Ignite/2015/BRK3862

• Azure AD Join in Windows 10 is a HUGE revolution and as Alex Simons explained, App Proxy is part of it. Here is a technical drill down into this technology: http://channel9.msdn.com/events/Ignite/2015/BRK3332

• There are lots of security goodies in Azure AD that with App Proxy will also apply to your on-prem apps. Here is a full review and demo of them: http://channel9.msdn.com/events/Ignite/2015/BRK3865

And, if you have 4 minutes to spare, here is a short clip that shows that corporate identity can be funny.

Meir Mendelovich

We have recently noticed lots of nice blog posts on Azure AD Application Proxy around the Web. We thought it would be nice to share them with you. If we missed anything, please add it as a comment to this post.

App Proxy for specific applications:

Roberto from All thing Cloud wrote a wonderful blog post on how to publish Dynamics CRM 2015: http://allthingscloud.info/?p=671 

The one and only Kirk Evans shows all the details of publishing SharePoint 2013: http://blogs.msdn.com/b/kaevans/archive/2015/04/13/azure-ad-application-proxy-and-sharepoint-2013.aspx

The Cloud Technologist blog explains how to publish Lync control panel: http://tctblgs.azurewebsites.net/azure-application-proxy-services/  

This blog post explains how to publish Cireson self service portal: https://systemcenterpoint.wordpress.com/2015/03/26/publish-the-cireson-self-service-portal-with-azure-ad-application-proxy/

Pieter Wigleven explains how to publish NDES/SCEP for Intune or System Center devices certificate enrollment: http://blogs.technet.com/b/ems/archive/2015/02/25/part-4-protecting-ndes-with-azure-ad-application-proxy.aspx

General guides:

http://www.schmarr.com/Blog/Post/22/Azure-AD-Application-Proxy-Guide

http://www.identityandcloud.com/category/aad-ap/

http://blog.hametbenoit.info/Lists/Posts/Post.aspx?ID=608

https://msandbu.wordpress.com/2015/02/19/publishing-internal-applications-using-azure-active-directory-using-application-proxy/

Little bit troubleshooting: http://scug.be/nico/2015/03/10/azure-application-proxy-notes-from-the-field/

The connectors are the secret sauce of Azure AD Application Proxy. They are simple, easy to deploy and to maintain but super powerful. We have gathered in this blog post different topic regarding the connectors that we were asked about.

One connector, two connectors, lots of connectors

You can install connectors based on your high availability and scalability needs. You can start with one and then add more as needed. Each time a connector is installed it is added to the pool of connectors that serves your tenant.

It is recommended not to install the connectors on the application servers themselves though it is possible, especially for small deployments.

Cloud Rules!

The connectors and the service take care of all the high availability tasks. They can be added or removed dynamically. Each time a new request arrives it will be routed to one of the connectors that is currently available. If a connector is temporary not available, it will therefore not respond to this traffic.

The connectors are stateless and have no configuration data on the machine other than the connectivity to the service settings and the certificate that authenticate this connector. When they connect to the service, they pull all the required configuration data and refresh it every couple of minutes.

They also poll the server to find if there is a newer version of the connector. If one is found, the connectors update themselves.

You can monitor your connectors from the machine they are running on using either the event log and performance counters or from the cloud using the connector status page.

All networking is outbound

Connectors only send outbound requests. There is no need to open inbound ports. The outbound traffic is sent to the Application Proxy service and to the published applications. The traffic to the service is sent to Azure datacenters to several different ports numbers. Look here for more details.

As a result of having only outbound traffic, there is no need to setup load balancing between the connectors or configure inbound access through your firewalls.

To DMZ or not to DMZ?

The connectors can be installed anywhere that allow them to send requests to both the service and the backend applications. They will work fine if they are installed inside the corpnet, within a DMZ or even on VM that is running in the cloud and has access to the apps.

DMZ deployments are usually more complicated. But, one of the reasons to deploy connectors in the DMZ is to use other infrastructure that is available to components running there e.g. backend application load balancers and/or security controls like intrusion detection systems.

To domain join or not to domain join?

The connector can run on a machine that is not domain joined. However, a domain joined machine is required if you would like to use single sign-on (SSO) for applications that use Integrated Windows Authentication (IWA). In this case, the connector machines must be joined to a domain that can perform Kerberos Constrained Delegation on behalf of the relevant users for the published applications.

Connectors can be joined to domains or forests that have a partial trust or to read-only domain controllers (RODC).

Connectors on hardened environments

In most cases, connector deployment is very straight forward and requires no special configuration. But, there are several unique conditions that should be taken into consideration:

1. Organizations that limits the outbound traffic must follow the instructions here to open the required ports.
2. FIPS compliant machines might be required to change their configuration to allow the connector service, the connector updater service and its installer to generate and store a certificate on that machine.
3. Organizations that lock down their environment based on the processes that issue the networking requests have to make sure that both the connector services are enabled to access all required ports and IPs.
4. In some cases, outbound forward proxies may break the two way certificate authentication and cause the communication to fail.

All connectors are equal (until…)

All connectors are assumed to be identical to each other and every incoming request may arrive to each one of the connectors. This means that all of them should have the same network connectivity and Kerberos settings.

Our team is working on introducing new way to group the connectors so they can serve different sets of applications, installed on different networks or joined to several different forests. Stay tuned for updates.

Connector authentication

In order to provide a secure service, the connectors have to authenticate toward the service and also the service has to authenticate toward the connector. This is done using client and server certificates when the connectors initiate the connection. This way the administrator’s username and password are not stored on the connector machine.

The certificates that are used are specific to the Application Proxy service. They are created during the initial registration and automatically renewed by the connectors every couple of months. If a connector is not connected to the service to a period of several months, it might have outdated certificate and registration is required. In this case, just uninstall and install the connector to trigger registration or run the following PowerShell commands:

Import-module AppProxyPSModule

Register-AppProxyConnector

Performance & Scalability

While the on-line service scale is transparent for you, scale is a factor when it comes to connectors. You need to have enough connectors to handle the peak traffic. Since the connectors are stateless, they are not dependent on the number of users or on sessions, but on the number of requests and their payload size. For the standard Web traffic, we have seen an average machine handle a couple of thousands of requests per second – depending on the exact machine characteristics.

The connector performance is bound by CPU and networking. CPU is needed for the SSL encryption and decryption while networking is important to get fast connectivity to the applications and to the on-line service in Azure. In contrast, memory is less of an issue for the connectors.

On the service, we make an effort to off load the connectors as much as we can. The on-line service is taking care of much of the processing and on all unauthenticated traffic. Everything that can be done in the cloud, is done in the cloud.

Another factor on the performance is the quality of the networking between the connectors and:

1. The on-line service: If the connection is slow, jitter or have high latency it will influences the service level. It is the best if your organization is connected to Azure via Express Route or that the networking team made sure that connections to Azure are handled in an efficient way.
2. The backend applications: In some cases, there are additional proxies between the connector and the backend applications. It is easy to troubleshoot this by opening a browser from the connector machine and accessing these applications. If you run the connectors in Azure, and the applications are on-prem, the experience might not be as your users are used to.
3. The domain controllers: if the connectors are performing SSO using Kerberos Constrained Delegation (KCD), they contact the domain controllers before they send the request to the backend. The connectors have a cache of Kerberos tickets but in a busy environments, the responsiveness of the domain controllers can slow the experience. This is more common for connectors that run in Azure while the domain controllers are on-prem.

Under the hood

While we provide all the tools for you in Azure, the connectors also have lots of local useful functionality. As the connectors are based on Windows Server Web Application Proxy, they have most of the same management tools; including the rich set of Windows Event Logs and Windows Performance counters:

Note that the connectors have both admin and session logs. The admin logs includes key events and the errors. The session logs include all the transactions and their detailed processing. To be able to see them, you have to enable “show analytic and debug logs” on the event viewer “view” menu. Then, you have to enable them to start collecting events. These logs do not appear in Web Application Proxy in Windows Server 2012 R2, as the connectors are based on a newer version.

If you want to examine their execution, the connector is comprised of two Windows Services, one is the actual connector, and another is one that takes care of the update. Both of them are required to run all the time.

We are going to update this post as we evolve the connectors on future releases.

If there is a question on the connectors that remained unanswered or for any feedback you have, send us an e-mail to AADAPFeedback@microsoft.com.

Today we are announcing two small capabilities that will help you improve the experience of using proxy applications:

Changing the application icon

You can now change the icon for the proxy applications in the same manner you can do that for other applications in Azure AD.! Just upload your icon and it will be presented in the access panel (http://myapps.microsoft.com/).

Define who gets to see passthrough applications

In the past, passthrough applications were shown to all users in the Access Panel. We heard feedback from you that this created an overloaded experience in the portal. Many of you want to publish protocols like Intune NDES/SCEP and don’t want their users to see these icons. Therefore, we have changed the default behavior for passthrough applications: from now on, only users that are assigned to the application directly or via groups will see the icon of that application in the portal just like other applications.

Keep in mind that when it comes to passthrough applications, assignment only affect the presentation of the application icon in the portal, as the user identity is not verified before the request is sent to the backend like it is for preauthentication apps.

Have all of this in Office365 App Launcher

All of the above applies both to the Azure AD Access Panel that is accessible via http://myapps.microsoft.com/ and also to the Office 365 App Launcher that also includes proxy applications. Your users can go to all their work applications without leaving Office 365 screens.

We have recently added two new capabilities to Azure Active Directory that apply also for proxy applications:

More conditional access options

Conditional access to application means that you can apply application specific policies that are evaluated each time a user is trying to access the application. In this release we have added the ability to block access to applications when users are not located at their workplace based on their source IP address. Customers asked for this as they are deploying applications on separated cloud environments and they want to make these applications securely accessible to their employees without exposing them to the Internet. In the past, companies deployed expensive VPN to their cloud environment and had to deploy dedicated filtering solutions.

We keep working on adding more conditions to allow you to set more types of policies.

See more details here: http://blogs.technet.com/b/ad/archive/2015/06/25/azure-ad-conditional-access-preview-update-more-apps-and-blocking-access-for-users-not-at-work.aspx

Self-service access requests

Self service application access allow you to streamline the process of enrolling new users to applications. Instead of users making expensive support calls to your helpdesk, they can now find and request access to applications by themselves using the access panel portal. The approval process can be delegated to people in your organization that owns these applications. This is done without compromising on security and leaving the IT organization under control with full visibility, reporting and auditing of these actions. You can now apply all these capabilities also to on-prem applications and have a fully self-service process in minutes without deploying expensive on-prem tools. This is another benefit that Azure Active Directory can bring to your legacy on-prem applications without changing them.

See more details here: http://blogs.technet.com/b/ad/archive/2015/04/23/employee-self-service-app-access-for-azure-ad-now-in-preview.aspx

We’re pleased to let you know that we’ve just published updated documentation for publishing Remote Desktop Gateway with Windows Server Web Application Proxy which you can find here -  https://technet.microsoft.com/en-US/library/dn765486(WS.11).aspx

We have covered the 2 key scenarios of pass through authentication and pre-authentication without SSO in the updated docs. Remote Desktop Gateway publishing has a number of complexities which we’ll dive into in a subsequent blog, talk about some of the constraints we have around SSO and discuss further deployment options.

If you have any specific questions please add a comment below and we’ll try to include what we can in the follow-up blog.

Thanks,

Ian Parramore, Senior Escalation Engineer, Application Proxy support team

Many customers are asking us how to move from Forefront UAG and TMG to the new Application Proxies. We have written a whitepaper to describe this move. You can download this whitepaper from here.

Here is an excerpt from this whitepaper:

As part of our continuous effort to improve the security posture of applications that are published by Azure AD Application Proxy, we have started to block Web crawler robots from indexing and archiving your applications.

Every time a Web crawler robot tries to retrieve the robots settings for a published application, the proxy will reply with a robots.txt file that have the following content:

        User-agent: *

        Disallow: /

No action is needed to turn this on. All Application Proxy customers will automatically get this functionality.