Azure AD Application Proxy – Access internal applications securely

For applications that reside on-premises, Azure Active Directory Application Proxy can provide your business with secure remote access to those applications from anywhere in the world. Besides secure remote access, you have the option of configuring single sign-on.

Typically, your organisation will have internally deployed SharePoint sites, Outlook Web Access, Citrix Director (for those Citrix customers), and many other line-of-business web applications. Using Application Proxy (a feature of Azure AD), you integrate those applications with Azure AD, and the applications can be consumed externally in a secure manner.

Often the case when needing to present such applications out to the internet, you have to depend on VPN-type solutions for security, proxies, DMZ extensions of your applications, or else modify different firewalls to accept direct traffic to your internal resources. Using Application Proxy, a Proxy Connector is installed on a server in your internal network, which acts as the broker (reverse-proxy) to provide you with access to that application. No need to deal with VPNs or firewall rules, just allow ports 80 and 443 from the Connector out to the internet.

AAP diagram from Microsoft.

Contents:

Who is entitled to Application Proxy?

  • Customers with an Azure AD Basic, Premium P1 or Premium P2 subscription.

What applications work with Application Proxy?

  • Web applications that use Integrated Windows Authentication (IWA) for authentication.
  • Web applications that use form-based or header-based access.
  • Applications hosted behind a Remote Desktop Gateway.
  • Rich client apps that are integrated with the Active Directory Authentication Library (ADAL).

What are the Application Proxy requirements?

  • An Azure AD Basic or Premium subscription as noted above.
  • Proxy Connector (piece of software) installed on Windows Server 2012 R2 or 2016, which has access to the internal web applications you are publishing and access to the Application Proxy services in Azure cloud.
  • Proxy Connector servers must be domain joined to the same domain as the applications you are publishing if you plan to use SSO via Kerberos Constrained Delegation.
  • The following ports must be open from the Proxy Connector (v1.5.132.0 and later) to Azure:
    • 80 – Used to download certificate revocation lists (CRLs) while validating SSL certificates.
    • 443 – Used for outbound communication with the Application Proxy service.
  • Also allow the Connector to reach the following domain names:
    • msappproxy.net – For proxy communication.
    • servicebus.windows.net – For proxy communication.
    • mscrl.microsoft.com:80 – For verifying certificates.
    • crl.microsoft.com:80 – For verifying certificates.
    • ocsp.msocsp.com:80 – For verifying certificates.
    • www.microsoft.com:80 – For verifying certificates.
    • login.windows.net – For registration process purposes.
    • login.microsoftonline.com – For registration process purposes.

Further information on the Application Proxy connector:


When providing secure, external access to applications via Application Proxy, you must install a Proxy Connector on your internal network, ideally close to the applications you publish. A connector is a lightweight agent that is installed on Server 2012 R2 or 2016 as noted above. This component acts as a proxy, relaying the web application traffic between your web browser and the backend web servers that host the application.

For redundancy and load balancing, it is recommended to install pairs of connectors, keeping in mind that load balancing is handled automatically in a round-robin fashion between connectors that reside in the same Connector Group.

A Connector Group is optionally created by the administrator, and each group handles traffic to specific applications. When you are adding an application to Azure, you specify a Connector Group (other than the default) that you would like to use. Connector Groups allow you to manage deployments at scale. For example, it may be best to create a Connector Group containing only the connectors residing in your US datacentre and choosing that Connector Group to interact with web applications from the same region.

Connectors can be added and removed easily from a group. If a connector becomes unavailable due to failure or maintenance, traffic is redirected to the next available connector.

Connector placement is interesting. Since they only initiate outbound traffic, it is not essential to place them within a DMZ. Also, in terms of captured data, connectors only store the required information needed to connect to the Application Proxy service. No application credentials, user information and so on is captured or stored.

Updating the Application Proxy connector:


The connectors are set to poll the Application Proxy service to find out if a newer version is available. This task is handled through the Microsoft AAD Application Proxy Connector Updater service. If an update is available, the connectors will update themselves. You can also manually update a connector if required.

If an update is performed during active traffic transactions with a client web browser, the transaction(s) would be lost. However, the client’s web browser should automatically retry the operation, or the user will refresh the page, at which stage the traffic is directed to another available connector.

Estimated Connector machine sizing:


The more an application is used, typically, the more resource you will assign to your connector servers. When it comes to sizing connectors, CPU and network capability is important. CPU is used to encrypt and decrypt traffic whilst a fast network will equate to fast access to your web applications and the Application Proxy service in Azure. Typically a connector can handle a couple of thousand requests per second for standard web traffic.

Maximum Transactions per second RAM CPU Expected latency (ms)
586 8GB 2 cores 325
1150 16GB 4 cores 320
1190 32GB 8 cores 270
1200 64GB 16 cores 245

As you can see from the final three metrics, the maximum transactions per second does not differ greatly. The main difference is reduced latency.

Tips and recommendations to reduce latency:

  • Group your Application Proxy Connector servers appropriately. For example, connectors should reside close to the applications they serve, such as in the same datacentre.
  • Your connectors should have fast access to the web applications they proxy traffic to/from.
  • Size your connector servers for peak traffic load. Monitoring tools should be used so that CPU or network constraints are brought to your attention for remediation before user experience is impacted.
  • For fast connections between the Application Proxy service and connector server, dedicated VPN solutions such as ExpressRoute should be implemented.
  • Domain Controllers should quickly issue Kerberos tickets if you are using Kerberos Constrained Delegation as an authentication method to provide single sign-on to your applications. Connectors have a cache of Kerberos tickets, but the responsiveness of domain controllers can affect performance when tickets are issued.

⮩ Side-notes that impact latency:


All proxy solutions will introduce a level of latency into your network connection. Application Proxy service instances for your Azure tenant are created in the same, or closest region as your Azure AD tenant. For example, if you sign up to Azure and specify your Azure AD region to be in the EU, all your Application Proxy service instances will be located in EU Azure datacentres. Keep this in mind, as when users access applications via Application Proxy, the connectors will route their traffic through service instances in this location.

When installing connectors, think about where the internal applications are located, where most of your users are located, and if you have dedicated VPN or ExpressRoute set up. It is possible to install the connector in Azure, for example if you have private peering between Azure and your corporate network, and low latency could still be achieved. Microsoft recommend making use of ExpressRoute if you have it, so communication between on-premises applications and Azure are going through a dedicated connection rather than out through the public internet.

How to access applications via Application Proxy:

Authentication options with Azure Application Proxy:

⮩ Pre-authentication options:

  • Azure Active Directory – Microsoft recommend keeping this option enabled. Doing so allows you to take advantage of Azure AD security features such as Conditional Access for multi-factor authentication. Before a user is granted access to their application, they must sign in to Azure AD first. This can be helpful in preventing anonymous attacks on your applications such as DDOS attacks, as you don’t get access to the application until authenticated.
  • Passthrough – Users don’t have to authenticate against Azure AD to access the application. You can still set up authentication requirements on the backend.

⮩ Single sign-on options:


When using single sign-on, the Application Proxy Connector handles authentication to your on-premises application. The backend application cannot tell the difference between a remote user signing in through Application Proxy or a regular user connecting internally from a domain-joined device.

To use Azure AD for single sign-on to your applications, you need to select Azure Active Directory as the pre-authentication method. If you select Passthrough, your users are directed straight to the application.

  • Azure AD single sign-on disabled – If you don’t want to use Azure AD integration for single sign-on to your application, select this method. With this option selected, users authenticate initially with Azure AD, and then potentially a second time with the application itself. If the application does not require authentication, this option would be a good choice to implement as a layer of security for remote access workers.
  • Password-based Sign-on – Using this method, Azure AD acts as a password vault for your on-premises applications. Many line-of-business applications don’t integrate with Active Directory and have separate credential systems. Using this option, users log on to the application for the first time and subsequent attempts trigger Azure AD to authenticate on behalf of the user, using the previously entered credentials which are stored in the vault.
  • Linked Sign-on – If you already have a single sign-on solution for your on-premises identities, choose this method. This option enables Azure AD to leverage existing SSO solutions, but still gives your users remote access to the application.
  • Integrated Windows Authentication – If your app uses IWA, or if you want to use Kerberos Constrained Delegation for single sign-on, choose this method. Using this option, users authenticate with Azure AD initially, and then the Proxy Connector impersonates the user to obtain a Kerberos ticket from Active Directory to complete authentication with the application.
  • Header-based Sign-on – If your application uses headers for authentication, choose Header-based sign-on. Using this option, users only authenticate with Azure AD. Microsoft partners with a third-party authentication service named PingAccess, which translates Azure AD access tokens into a header format for the application to consume.

Password-based sign-on – Requirements:


Password-based sign-on requirements:

This method is intended for apps that use a username/password combination for authentication. When you configure this method, your users have to sign in to the on-premises application once. After that, Azure AD stores the sign-in information and automatically provides it to the application when your users access that application remotely. Passwords are stored in an encrypted state in the directory and are only passed over HTTPS during the automated sign-in process.

With this method, a web browser extension or mobile app is required. The browser extension is used to securely retrieve the application and user-specific information from Azure AD and apply it to the service. This authentication method works for any web application that has an HTML-based sign-in page.

The following web browsers are required:

  • IE7 on W7+.
  • Edge on W10 1607+
  • Chrome on W7 or later, and on MacOS X or later
  • Firefox 26.0 or later, on XP SP2 or later and on Max OS X 10.6 or later

Kerberos Constrained Delegation – Requirements:


Application Proxy must be given permission in AD to impersonate users.

As the user enters the URL to access the on-premises application via Application Proxy, they first authenticate with Azure AD. Azure AD creates a token and passes it to the user. The user passes it to Application Proxy. The Application Proxy validates the token, retrieves the UPN from it, and then sends the request, the UPN and the SPN to the connector. The Connector performs KCD negotiation with the on-premises Active Directory domain controller(s), impersonating the user to get a Kerberos token. Active Directory then sends the Kerberos token for the application to the connector. The connector sends the original request to the application server, using the Kerberos token it received from AD. The application sends a response to the connector, which is relayed to the Application Service and finally to the user.

Applications must be set to use IWA (Integrated Windows Authentication). You must also create a Service Principal Name for participating applications. The connector and server running the application must be domain joined to the same domain or trusting domains. The connector server must have access to read the TokenGroupsGlobalAndUniversal attribute for users. This permission is set by default but may have been impacted by security hardening in your environment.

If you have a different domain internally and externally, you can still use KCD for single sign-on. To do so, you just configure the delegated login identity for each application to specify which identity should be used when performing single sign-on. For example, the options are:

  • User principal name.
  • On-premises user principal name.
  • Username part of user principal name.
  • Username part of on-premises user principal name.
  • On-premises SAM account name.

Single sign-on errors are captured in the connector machine event log.

Specifying an external URL:


When adding an Enterprise Application to Azure to be used with Application Proxy, you might enter a URL such as http://mywebapp.com/homepage/ as this is the URL users browse to reach the home page of that web application. If your application loads images or uses other content located at mywebapp.com/media for example, you should publish the URL in Azure simply as http://mywebapp.com/. This internal URL doesn’t have to be the landing page your users see, as you can set a custom home page for published applications. Use the Azure AD PowerShell module to define custom home page URLs when you want users to land on a specific page within the application.

For example, when users are located on the corporate network, they may browse to http://mywebapp.com/homepage/login.aspx to log on to the web application. Because the web application has other assets like images that Application Proxy needs to access at the top level of the folder structure, you specify the internal URL as http://mywebapp.com. You then need to set http://mywebapp.com/homepage/login.aspx as the home page URL so that users are directed here when accessing the application externally. Also note that if you make a change to the published application, the change might reset the value of the home page URL. When you update the application in the future, you should recheck and if necessary update the home page URL.

Set up and configure Application Proxy with password-based sign-on:


Log on to the Azure portal and navigate to Enterprise applications.

Select On-premises application. The Azure portal will inform you that you have no Application Proxy Connector servers and that you must download and install the required software to a server. Click Download Application Proxy Connector.

Before installing the Application Proxy Connector software, turn off IE ESC (Internet Explorer Enhanced Security Configuration) via Server Manager. Click Accept terms & Download.

Run the installer from a supported server operating system, and click I agree to the license terms and conditions followed by Install.

Enter credentials of an Azure global administrator account.

Click Close to complete the install.

Two services are installed alongside the Proxy Connector:

  • Microsoft AAD Application Proxy Connector – Enables connectivity.
  • Microsoft AAD Application Proxy Connector Updater – Checks for new versions of the connector and updates the connector accordingly.

Return back to the Azure portal and click I’ve finished the installation.

Now you’ll be asked for details about the first on-premises application you want to add to Application Proxy. Enter details as below:

  • Name – Specify a display name which you and users will see from the Azure portal, and from the Azure AD access panel etc.
  • Internal Url – This is the URL you would use internally to reach the application.
  • External Url – This is the external URL users will use to externally connect to the application. You can either use your own corporate external domain name that is verified with Azure AD, an .onmicrosoft.com or .msappproxy.net address. Note that using a custom domain name will require that you provide and upload a third-party certificate to Azure which has a Subject Name matching the external URL. You will also need to create the appropriate CNAME record on your public nameservers.
  • Pre-Authentication – This can be set to Azure Active Directory or Passthrough. If set to Azure Active Directory, you challenge users with Azure AD authentication before allowing them access to the on-premises application. If set to Passthrough, users are passed through to the application itself and challenged for authentication there if required.
  • Connector Group – As previously mentioned, you can create custom Connector Groups, allowing you to strategically tie together Application Proxy Connector servers with on-premises applications for best performance.
  • Backend Application Timeout – Set this value to Long only if your application is slow to authenticate and connect. Microsoft recommends keeping this value as default.
  • Headers – Keep this value set to Yes unless your application requires the original host header in the authentication request.
  • Application Body – Keep this value set to No unless you have hardcoded HTML links to other on-premises applications and you do not use custom domain names.

Once all fields are complete, click Add.

Your application will show as below and is editable at any time. You can also add new applications from this screen. Click on Application proxy.

Here you can create new Connector Groups, download the connector service and view details about your active connectors etc. If a connector has been inactive for more than 10 days, it is removed from Azure.

To assign users to the application you just created, navigate to Enterprise applications -> All applications and click into your application. Now click Users and groups -> Add user.

You can assign access to individual users, or to groups (if using a paid version of Azure AD). Click on None Selected.

Select a user, or group, then click Select.

Click Assign.

From now on and by default, the application will appear under the Azure AD access panel etc. for users who have been assigned this application. Users can also browse to the application manually using the external URL configured when setting up the application.

Because pre-authentication was set to Azure Active Directory, we are challenged for authentication.

If authentication is successful, the application appears (traffic is routed through the Application Proxy Connector). Note the certificate error, because I haven’t added a third-party certificate to Azure that matches my custom domain name.

If you want to upload a certificate, when editing the properties of the application and under Application proxy you will find a Click here to upload a certificate option.

If you want to challenge users with multi-factor authentication. This is made easy using Conditional Access policies. I have already created a Conditional Access policy which enforces MFA, and during the creation, you are given the option of assigning that policy to an application.

The next time your users sign on to the application, they will be prompted to register with Azure MFA if they haven’t already.

Future authentication attempts will be challenged with a push notification, or phone call etc. depending on user preference.

After authenticating with Azure AD and MFA, access to the on-premises application is granted.

To achieve single sign-on to the Citrix Director application and other applications, we can turn Azure AD into a password vault using the Password-based Sign-on single sign-on method. When you configure this method, users have to sign in to the on-premises application once. After that, Azure AD stores the sign-in information and automatically provides it to the application when your users access it remotely. Azure AD best estimates the username and password fields of your HTML web application from where it captures sign-in information, however you may need to manually help Azure detect the correct field names. To help you do this, install the My Apps Secure Sign-in Extension to Firefox, or your preferred browser (IE, Edge, Chrome).

Now on the Azure portal temporarily set the application pre-authentication method to Passthrough.

Click on the Single sign-on tab and set Single Sign-on Mode to Password-based Sign-on.

Scroll to the bottom and click Configure Password Single Sign-on Settings.

Click Manually detect sign-in fields -> Capture sign-in fields.

A new tab will open, and then another tab will open and direct you to your on-premises application. As you enter your username and password, the fields should be surrounded with a red outline.

Upon successful authentication, a pop-up box will appear. Click OK.

The on-premises application window will disappear, and you will be returned to the metadata capture is currently in progress page which will show a result of Metadata has been updated for the application.

Return to the Azure portal, check Ok, I was able to sign-in to the app successfully and click OK.

By clicking on Advanced: View and edit sign in field labels you will see the updated names of the captured sign-in fields. You are now ready to test the solution.

If Edge is your corporate remote browser of choice, for example maybe you issue corporate laptops to be used remotely, your users can download the My Apps Secure Sign-in Extension from the Microsoft Store.

The next time they launch Edge, the browser will ask do you want to turn on the My Apps extension. Click Turn it on.

The extension will show as a blue and white box icon to the top right of the browser window. Click it, then click Sign in to get started to sign in to the Azure AD access panel.

Enter Azure credentials of a user account that has been assigned the right to access the on-premises application via Application Proxy.

Upon successful sign in, click My apps.

Click the vertical ellipsis next to the on-premises application and click Update credentials.

Enter your credentials used to authenticate with the application and click Sign in.

On future visits to the application, Azure passes the saved credentials to the application for single sign-on. Using this method is helpful for applications that for example do not use Integrated Windows Authentication, and we do not want our users to authenticate twice, firstly with Azure AD and secondly with the on-premises application.

Configure Application Proxy with KCD single sign-on:


If your applications do use Integrated Windows Authentication, we can apply single sign-on to our sessions using the Integrated Windows Authentication single sign-on method.

Return to the Azure portal and edit the application we have been working on previously. Click on the Application proxy tab and make sure Pre-Authentication is set to Azure Active Directory.

Switch to the Single sign-on tab and set

  • Single Sign-on Mode to Integrated Windows Authentication.
  • Internal Application SPN to the SPN you will create in Active Directory for your web application.
  • Delegation Login Identity to On-premises SAM account name.

Click Save.

Create an SPN for your web application as below. The value you specify here matches the same one you have specified in Azure.

Open Active Directory, locate and double-click on your Application Proxy Connector server. Click on the Delegation tab. Click Trust this computer for delegation to specified services only -> Use any authentication protocol -> Add and add the SPN you just created to the list. Click OK.

Browse to the application via the external URL. Authenticate with Azure AD first (pre-authentication).

The Application Proxy Connector server will then impersonate you to obtain a Kerberos ticket on your behalf and use that to authenticate you with the on-premises application.


51 Comments

  • Thomas

    January 17, 2019

    Can I configure an azure App Proxy config with a NetScaler vServer configured as Kerberos constrained Delegation (sso) and publish an Storefront Store configured to use receiver for HTML5 only?
    The goal I‘m looking for is to publish a XenApp App on the azure Portal and not using SAML (🙈 please don‘t ask) but getting a seamless SSO with HTML5 Receiver thru the VDA.

    Reply
    • George Spiers

      January 25, 2019

      Yes you could do that but you can configure KCD via the App Proxy Connector server. So when users click on StoreFront from the Azure portal, the Web App Proxy obtains a Kerberos ticket for you and used that with StoreFront. NetScaler is simply load balancing the requests to StoreFront.

      Reply
  • DiegoM

    February 21, 2019

    Do you have any reference on how to integrate Citrix Gateway and StoreFront as a resource on the MyApps portal?
    Thanks!

    Reply
    • George Spiers

      February 22, 2019

      I don’t but you can publish StoreFront easily to MyApps via a Proxy Connector. Gateway can also be published to MyApps, and if Azure AD is your IdP, authentication to Gateway should be satisfied.

      Reply
  • Tonny

    March 19, 2019

    Hi George,

    I have a small difference that I would like to ask you about.

    We have a tfs server, 2019, on-premises with a local ad synced to azure ad. From this post, I understand that we can use the proxy to make sure that we can access the tfs with Azure AD creds. But we also have users from other tenants that need access to that tfs. Is that possible with the proxy? If the other tenant users are invited into the synced azure ad, would that be enough?

    Reply
  • Pingback: Azure AD Application Proxy – Bret-Tech

  • Andrew

    March 26, 2019

    Hi George

    I am interested to hear your perspective on the security of the service. If we have to turn off pre-authentication are we opening ourselves up to a lot of vulnerabilities due to not having any WAF in place? Would it be possible to terminate connections on the Azure WAF and then configure the backend pool as the proxy service?

    Cheers,
    Andrew

    Reply
    • George Spiers

      March 27, 2019

      Azure Application Proxy as you know is a reverse-proxy, so your back-end systems are protected from direct contact in that sense. There is DDoS protection built-in.
      If using preauthentication, you get all the benefits and protection that Azure AD has built-in. Not having pre-auth enabled could make your back-end systems more vulnerable to anonymous attacks. For more security, consider using conditional access policies as an extra layer of security.
      I’m pretty sure at this time you can’t use the Azure WAF with Application Proxy.

      Reply
      • Nic Bishop

        May 10, 2019

        Hi George, thanks for your article (and thanks for the question Andrew),
        Essentially, the Azure Application Proxy is just re-routing the traffic from the client browser back to the back-end service. Isn’t Authentication the only control?
        With a compromised or weak authentication, isn’t the back-end service exposed to OWASP attacks, and hence a vector to back end systems?
        I realise that the actual Azure AD endpoint will always be accessible to the internet but it would be possible to route traffic through a cloud WAF for the public DNS name. I am considering WAF a required additional control.
        Cheers,
        Nic

        Reply
        • George Spiers

          May 13, 2019

          Hello. As per https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-security, rather than traffic being routed from client browser to back-end service, the client traffic is terminated at Azure. A new stream from the Proxy connector is established to the back-end service. Regarding attacks, I would be implementing something in front of Proxy connectors to inspect the incoming client requests.

          Reply
          • Nic Bishop

            May 14, 2019

            Thanks George,
            Yes, that’s why I would like to route traffic via a cloud WAF SaaS.
            Cheers,
            Nic

          • John

            August 12, 2019

            Hi George. Thanks for your great work!
            Regarding the WAF. Where should be implemented the WAF exactly? Between Proxy connectors and Proxy Service? Or between Proxy Service and the Client?
            My question is for this scenario:
            https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/what-is-application-proxy

          • George Spiers

            August 19, 2019

            I don’t believe there is a way yet to have WAF and WAP integration.

  • Chris VanDenBerg

    June 20, 2019

    George, we are trying to do something similar. We are trying to use Azure site recovery to migrate the Xenapp servers to Azure and use AAP as the front-end. Currently on-prem Citrix is using the Netscaler to auth and route the traffic. When I set it up in AAP the traffic gets routed to the Citrix storefront, but I’m not able to launch any of the apps. I’m not sure if there is a configuration problem or if the AAP is not able to be used in place of the netscaler. All of the apps launch just fine internally when the AAP isn’t in the picture.

    Reply
    • George Spiers

      June 21, 2019

      Nope, for ICA proxy, AAP isn’t going to work. You need Gateway.

      Reply
  • Kristian Owen

    July 5, 2019

    Hi George, I’m trying to publish Vmware Virtual Centre via Azure Application Proxy, everything work great via the HTML5 version with Vmware but I’m having difficulty loading a HTML5 web console. Any ideas.
    Cheers
    Kris

    Reply
    • George Spiers

      July 9, 2019

      What is the URL you have defined for your Internal URL?
      Assume vCenter works OK when logging on directly to and browsing from the Proxy connector server(s)?

      Reply
      • Kristian Owen

        July 10, 2019

        The URL is vc-office365domain.msapproxy.net/ which I get to the landing page fine, I then use the HTML5 option which again works great and offers the vCenter options I then try and use “Launch Web Console” which looks like its going to work but never actually shows a login screen.

        Reply
        • George Spiers

          July 14, 2019

          It might not be supported. You should ask Microsoft.

          Reply
  • Nicolas Papanicolaou

    July 30, 2019

    If the user obtains authorization token beforehand, can you authenticate through Azure AD Proxy by passing the token in the HTTP header directly without getting prompt?

    Reply
    • George Spiers

      July 31, 2019

      Yes App proxy wouldn’t block it.

      Reply
      • Anonymous

        July 31, 2019

        Great!
        Thank you

        Reply
      • Nicolas Papanicolaou

        August 13, 2019

        Hello again!

        It was successful to pass through Azure AD Proxy with an authenticated token using client_secret. Sadly, I have been trying to pass with a token authenticated with username/password only. I am using Microsoft adal library to get the token beforehand.

        It seems to deny my token for some reason.
        …state=AppProxyState%3a%7b”InvalidTokenRetry”%3atrue%2c”IsMsofba”%3afalse…

        Is it possible Azure AD Proxy doesn’t support token authenticated with username/password flow?

        Thank you

        Reply
  • Ron

    August 26, 2019

    Hello George,
    Thanks for putting yet another great article.
    We are trying to publish our first SP 2013 Intranet site through Azure AD proxy and are running in to double hop authentication prompts from SharePoint server after successfully authenticated by the Proxy . URL to our SP site is http://site.contoso.com/sites/page/default.aspx. Our users enter http://site.constoso.com in their browsers when accessing the site. There is a custom redirector page which redirects the incoming URL request to /site/pages directory and also converts the incoming http requests to https. Proxy is working fine and users can access SP site but only through double hop authentication. First they are prompted to enter their domain/O365 credentials by proxy and after successful authentication, they are prompted again by SP server. Is there any settings to get rid of this double hop?
    Thanks.

    Reply
    • George Spiers

      August 29, 2019

      Hello
      Have you set “Single Sign-on Mode” to “Integrated Windows Authentication” and configured Kerberos Constrained Delegation?

      Reply
  • king

    September 8, 2019

    Thanks Jonny. Most of the footage is ARRI and we discovered the LUT was adding some weight to the project, but it only went down 6MB after we removed it. I did a test bringing in just the RAW footage and after attaching the proxies it doubled in size. This is a feature documentary and we have a lot of footage and a very tight schedule, so I’m worried the proxy workflow might slow us down in the future and I have started a new project just with the proxies. I would love not to loose the ability to connect to the raw footage, but thinking my project might slow me down after we start the edit worries me. The project with just the proxy files is only 6MB, while the project with the RAW media attached to proxies is 26MB. I know that 26MB might not be that big of a deal, but that is before creating any sequences.

    Reply
  • carry

    September 8, 2019

    Hello, I realize that the actual Azure AD endpoint will always be accessible to the internet but it would be possible to route traffic through a cloud WAF for the public DNS name. I am considering WAF a required additional control.

    Reply
    • Nic Bishop

      September 8, 2019

      Hi Carry, we decided not to with our implementation. We thought there were more benefits with Azure AD saved conditional access having direct access to the internet calls rather than being piped through a cloud WAF. We have our connector in a DMZ so we can scan through the NGFW. Depending on future requirements we may need to consider an on premise dedicated WAF.

      Reply
      • Law

        June 2, 2021

        Hi Nic,

        I am actually looking for using Azure Application Proxy as well for our implementation and was concerning about not having a WAF in front the external endpoint. This will causing all the request with SQLi/XSS to be directly goes into the connector and to our Apps server.
        Do you mind sharing more on how you do it without a WAF?
        Also, do you know is there anyway where the Proxy Connector can filter out this kind of malicious request on the request header setting?

        Reply
  • Gaurav Kumar

    October 29, 2019

    Hello All, Can we implement TFS (Team Foundation Server) On-Prem with the Azure Active Directory Application proxy for external access through internet?
    Also, I would like to know the following:
    1. If the implementation of AAD Application Proxy for external access to on-prem TFS is possible and recommended?
    2. Would it be possible to connect to TFS using the Visual Studio, via the AD Application Proxy, the same way you access on-perm?

    Reply
    • George Spiers

      November 17, 2019

      You should check with the Azure DevOps Server/TFS team to see if they have tested their product with AAD, and if it is supported.

      Reply
  • Jeremy Stevens

    October 31, 2019

    I am getting DNS resolution issues when going through App Proxy even though the connector server can resolve. Why would this be?

    Reply
  • Andy Wallace

    December 10, 2019

    Great article. One question are you able to publish apps that have a non standard port.
    i.e https://myapp.com:5678/login/

    Reply
    • George Spiers

      December 14, 2019

      Yes shouldn’t be a problem

      Reply
    • Jayson Knight

      November 2, 2020

      But, how do you specify a port for the external URL in the app proxy blade? It’s read only, I can only modify the internal URL.

      Reply
  • Shaun

    February 27, 2020

    Awesome article, it was the last 3-4 steps that I needed. Create an SPN and then delegate it on the app proxy object. I found the MS articles about this difficult to understand but this article helped me figure it out 🙂

    Reply
  • Khaled

    March 23, 2020

    Hi georges,

    Thanks for your article

    Actually, i’m working on a POC Azure Application Proxy to test Password-based SSO.

    Based on your post, I have a question where Azure stores the captured identifiers fields? Is there a way to automate the updating of identifiers? (Assuming using the same Azure AD account)

    Best regards,

    Reply
  • zeeshan

    April 30, 2020

    Hi George,

    I am trying to publish a simple dashboard the scenario is that after coming to landing page an iframe runs a javascript which has a custom port. I can go to the landing page but after it keeps giving me an error saying webserver name cannot connect to the custom port

    Reply
  • Anonymous

    June 19, 2020

    I have a basic question.
    If I have on prem web-app whose SSO mechanism is OpenID and the app does support OpenID protocol, is it possible to publish such app on app-proxy.

    As you can guess, I do not need PING ACCESS in this set up.

    Thanks.
    Chirag

    Reply
  • Pingback: The Microsoft Modern Workplace – Embracing the Next – Insentra Australia

  • Michael

    July 21, 2021

    Hey George,

    I have a customer who is looking to use Azure AD to sign into an RDS environment that is in a completely different forest from their on-prem domain that is synced with Azure AD. Would we require to have a forest trust in place to make the Azure AD App Proxy work in this scenario?

    Thank you!

    Michael

    Reply
  • Harry

    October 1, 2021

    HI George,

    First if all, great documentation here. Thank you for your time.
    I have one issue with this and wanted to see if you can guide.
    Let’s say for example, I have created an App Proxy Application and used internal url as abc.com and external url will be my custom tenant url. I am using Password based SSO and assign to certain users in the company and required to assign user to be able to access.
    The problem came as one of the user was using “My App” who was not assigned the application and went to ABC.com. Now the site says, you do not have access to this application (True as per permission). We deleted the Application from Azure and now the site ABC.com give 404 error and still try to redirect the page. We can use the site from incognito or non SSO browser. How can we clear the cache/redirect from Proxy server?

    Thank you.

    Reply
  • Pingback: Https advantage gateway agent login Portal Guide Instructions Help - centtip.com

  • Paul

    December 24, 2021

    Hi George,

    I have configured Azure proxy with a sharepoint 2013 site although users cannot access their documents when using the site through the azure proxy, they can access them on -prem do you know what might be the problem

    Reply
  • realgujju

    September 22, 2022

    Hi George,

    I was looking for detailed information about AAP and landed on this page which really helped me understand and learn about AAP but i have one doubt or not clear about is SPN registration so can you please clarify more.

    is SPN registration for web application under system context or user service account?

    e.g. you mentioned command as HTTP/ddc01.jgspiers.com ddc01
    where DDC01 is an application server netbios name or URL value

    my scenario is, we have server name / hostname as app01 where web application is installed as IIS where IISSVC is a service account so what would be the SPN command?

    HTTP/support.freeco.com:8443
    HTTP/support.freeco.com:8443
    HTTP/support.freeco.com:8443 domain\

    Reply
  • realgujju

    September 22, 2022

    Hi George,

    i am rewriting the SPN command as text within was removed

    HTTP/support.freeco.com:8443 app01 (where app01 is server hostname)
    HTTP/support.freeco.com:8443 support (where support is cname pointing to app01)
    HTTP/support.freeco.com:8443 domain\iissvc (where iissvc is service account configured in IIS pool)

    Reply

Leave a Reply