First published on CloudBlogs on Oct, 14 2015
Two blog posts in one day. I told you we weren't even close to done! In this second blog post I get to share the cool news with you that:

• All of the features of the Azure AD Application Proxy that were in public preview are now GA! (custom domain names, conditional access policies, Intune NDES, etc.)
• We've turned on a new public preview of three new features in the Application proxy:

1. Support for Remote Desktop
2. Support for complex networks and data center topologies using connector grouping
3. Support for non-Windows applications using Kerberos over SPNego

To walk you through the details, Meir Mendelovich, the Lead PM who owns the App Proxy has written up a nice blog post which you'll find below. I hope you'll check the app proxy out and give it a try in your organization! Best regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity Division --------------------- Hi everyone, It's Meir again, back to tell you about some of the enhancements we've recently added to the Azure AD App Proxy. It's only been 10 months since the Azure AD App proxy become been generally available and already hundreds of organizations are using it in production to integrate their on-premises and IaaS hosted applications with Azure AD, making them seamlessly available to remote workers all around the world. Of course behind the scenes, our team has been working day and night to make sure the service runs smoothly and provides a great user experience for those remote workers. And of course we keep on evolving the service and add more functionality to support more and more types of applications, improved reliability and a better admin experience. In just the last three months we added support for custom domain names , conditional access policies , and Intune NDES , as well as improved portal control , and enhanced monitoring . Today I'm happy to let you know that all of these capabilities that have been in public preview are now officially GA! We've completed our quality assurance and customers are already using them successfully in their production deployments. Now you can use them every day for your business as well. Next, I'm excited to announce we are turning on a new public preview of several new capabilities that we've recently added. They will allow you to publish more types of applications and to support more complex and demanding topologies. Read on to learn more about them!

Remote Desktop Support

The Azure AD Application Proxy can now be used with Remote Desktop. These Remote Desktop deployments can reside on-premises or in an IaaS deployment. Remote Desktop traffic is published through Application Proxy using pass-through authentication. This approach solves the connectivity problem and provides basic security protection such as network buffering, hardened Internet frontend and DDoS protection. Within the Remote Desktop deployment, the Remote Desktop Gateway needs to be published so that it will convert the RPC over HTTPS traffic to RDP over UDP traffic. Then clients will use their Remote Desktop clients (MSTSC.exe) to access Azure AD Application Proxy which starts a new HTTPS connection to the Remote Desktop Gateway using its connectors. That way, Remote Desktop Gateway will not be directly exposed to the Internet and all HTTPS requests will first be terminated in the cloud. Here is the overall recommended deployment topology:

Read more about Remote Desktop publishing here .

Support for isolated networks and IaaS hosted applications

Application Proxy Connector groups allow you to assign specific connectors to serve specific applications by using connector groups. And each Application Proxy Connector is assigned to a connector group. All the connectors that belong to that connector group act together to provide high-availability and load balancing among them. This enables a you to support a number of cool new use cases, including easily providing access to applications in data centers and across disparate networks. (Note: By default, all connectors belong to the default group. Also by default, all applications are assigned to the default connector group. So if you go with the defaults, everything works just like it used to). But the power comes when you organize your connectors into groups, you can then set each application is to work with a specific connector group, so that only the connectors in that group serve the application when it is requested. Using this Application Proxy can serve number of purposes:

• Provide application access across disparate datacenters
• Provide access to applications installed on isolated networks
• Provide access to applications installed on IaaS in Azure or Amazon Web Services.
• Supporting disaster recovery sites for applications and resources.

You can read more about connector groups and how to use them here .

Single sign-on to non-Windows applications using Kerberos over SPNego

Application Proxy now supports single-sign-on (SSO) to non-Windows backend applications through Kerberos over SPNego. Support for this protocol is widespread and covers a large portion of mainstream applications running on platforms like Linux and Unix. This means that every application that supports SSO via Kerberos for on-prem domain joined browsers will now provide SSO to your employees authenticating with Azure AD. The Kerberos delegation flow in Azure AD Application Proxy starts when Azure AD authenticates the user in the cloud. Once the request arrives on-premises, the Azure AD Application Proxy Connector issues a Kerberos ticket on behalf of the user by interacting with the local Active Directory. This process is referred to as Kerberos Constrained Delegation (KCD). In the next phase, a request is sent to the backend application with this Kerberos ticket. There are number of protocols that define how to send such requests. Most non-Windows servers support Negotiate/SPNego which is why we chose to add support for it to the Azure AD Application Proxy. During the preview phase, this functionality will be off by default. To learn how to turn it on and read more about SSO capabilities here .

Support employee with mismatched on-premises and cloud identities

In the past, Application Proxy single sign on assumed that users have exactly the same identity in the cloud and on-prem. Many organizations have complex environments that cannot work that way. We have improved Application Proxy to enable more flexibility! Now, the admin can configure, for each application, what identity should be used when performing single-sign-on for this app:

By default, all applications using the user principle name of the cloud user. The additional options are intended to be used for applications that need the alternate user principle name or identity that is not expressed as e-mail address. This capability allows many organization that have different on-prem and cloud identities to have single sign on from the cloud to on-prem apps without requiring the users to enter different usernames and passwords. This includes organizations that:

1. Have multiple domains internally (joe@us.contoso.com, joe@eu.contoso.com) and a single domain in the cloud (joe@contoso.com).
2. Have non routable domain name internally (joe@contoso.usa) and a routable domain in the cloud.
3. Do not use domain names internally (joe)
4. Use Different aliases on-prem and in the cloud. E.g. joe-johns@contoso.com vs. joej@contoso.com
5. Have applications that do not accept identities in the form of e-mail address, which is a very common scenario for non-Windows backend servers.

Here is an example for such configuration:

Read more about SSO capabilities here .

Want more?

Our team is busy now working on more cool stuff enhancing Azure AD Application Proxy to cover more applications and scenarios. Follow the application proxy blog to get all the details on the new releases. We are always happy to hear your feedback on what we released and what you think we should release. You can send us a note to aadapfeedback@microsoft.com . Best regards, Meir Mendelovich