Enterprise Mobility and Security Blog

RSS

Howdy folks,

I hope those of you in the U.S. had a great MLK day. This is the first year it’s been an official holiday at Microsoft and we were all pretty happy about it!

Sean Ivey is back blogging this week have a bunch of tips on using one of our hidden gems, the Azure AD App Proxy.

As always, we’d love to get any suggestions or feedback you have. And if you have questions for a future mailbag, send them to AskAzureADBlog@microsoft.com!

Best Regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Products and Services

————————————

Hi folks,

Sean Ivey back again with another mailbag post. This post is going to focus on the Azure AD App Proxy. If you haven’t heard of this you’ve been missing out, it is one of our coolest features. To sum it up in one sentence, the Azure AD App Proxy allows you to extend access to your on-premises applications to users in the cloud without changing your applications and with no changes to your DMZ! For example, that internal SharePoint application that people have to VPN in to your corporate network to get access to. Now there’s an easier way! You can also leverage all the great aspects of Conditional Access and MFA with it. For an in-depth session on this check out our video from MS Ignite. On to the questions.

-Question 1 Updated 1/22/16 to provide a bit more clarity -MarkMoro

Question 1: The pre-authentication mode for the Azure AD app proxy offers a number of benefits <ability to set MFA, conditional access rules, get security reporting etc>. Is there any benefit to using the pass-through option in the Azure AD app proxy?

Answer 1: Even without the benefits that come with pre-authentication, there are still some compelling reasons to use the app proxy in pass-through mode.

  • Since all HTTP/HTTPS traffic is terminated in the cloud, it protects your backend servers from having to be directly exposed to HTTP based attacks like heartbleed.
  • Azure AD App Proxy does NOT require inbound ports to be opened in your firewalls to enable access to the internal application and no servers are necessary in the DMZ. This greatly reduces deployment complexity and you can avoid having to bug the firewall/network team.
  • Applications front-ended with Azure AD App Proxy can optionally show up in the MyApps portal and Office 365 quick launch. This gives users a unified access experience to both SaaS applications as well as on-premises web applications.
  • Given that this is a service; we handle the maintenance of the proxy-ing service so you don’t have to.

Question 2: I have Remote Desktop Gateway setup on-premises. Can I use Azure App Proxy to facilitate access to resources through these channels?

Answer 2: Yes you can! A great article was published on the Application Proxy Blog that walks you through the setup. It’s published using Passthrough authentication so you’ll get some of the great benefits mentioned in answer #1. It’s perfect for lab environments as well because you don’t need an external static IP address to get this to work (I use it in my home lab).

Question 3: After publishing an application with Azure AD Application Proxy and assigning users they get the following error when trying to access it: “This corporate app can’t be accessed. You are not authorized to access this application.” What am I doing wrong?

Answer 3: If you have assigned the users/groups to the application correctly then they likely do not have an Azure AD license assigned. Publishing applications with Azure AD Application Proxy is a basic/premium feature. For a quick list of features and which edition they are available in, check out this page.

Question 4: I setup my application for Kerberos Constrained Delegation as discussed in this article, but it’s still not working. What can I do to troubleshoot?

Answer 4: Most applications written for Windows use Integrated Windows Authentication (IWA). IWA is designed to negotiate which authentication mechanism to use. Kerberos is typically tried first, but if necessary components are not configured IWA will negotiate NTLM. NTLM does NOT support delegation like Kerberos. Because Azure AD Application Proxy relies on delegation to implement SSO, any application that negotiates NTLM will fail.

To help troubleshoot Kerberos issues review the information on this page. follow these steps to gather data, and then review the list of errors in the article and the potential solutions.

  1. To reduce the possibility of caching data, do one of the following:
    1. Close/Reopen client application
    2. Logoff/Logon client workstation
    3. Reboot client workstation
  2. Start the network capture
  3. Clear DNS cache using:
    1. ipconfig /flushdns
  4. Clear NetBIOS cache using:
    1. nbtstat –RR
  5. Clear user Kerberos tickets using:
    1. klist purge
  6. Clear system / computer Kerberos tickets using (Vista or higher only):
    1. Klist –li 0x3e7 purge
  7. Reproduce the authentication failure with the application in question
  8. Stop the network capture and review the traffic that was capture using the kerberosv5 filter (if using Netmon or Message Analyzer).

The most common errors are:

  • KDC_ERR_PREAUTH_REQUIRED (This isn’t something to worry about. You should expect to see this one)
  • KDC_ERR_S_PRINCIPAL_UNKNOWN
  • KRB_AP_ERR_MODIFIED

So definitely look for these in the trace.

Question 5: How do I set up high availability for the Azure AD Application Proxy servers?

Answer 5: You don’t, WE DO! With the way Azure AD Application Proxy is designed, as long as there are at least two connectors installed per connector group they will be redundant. Notice how the connectors make an out-bound connection to Azure AD where we handle the incoming requests from users.

We hope you’ve found this post and this series to be helpful. For any questions you can reach us at AskAzureADBlog@microsoft.com, the Microsoft Forums and on Twitter @AzureAD@MarkMorow and @Alex_A_Simons

-Sean Ivey, Mark Morowzynski, Girish Chander