Publishing SharePoint 2016 and Office Online Server with Azure AD Application Proxy

September 16, 2016: Updated information on authentication for OOS. Pre-authentication is not supported and passthrough must be used

A common customer request is publishing an on-premises SharePoint site over the internet so that users can access it without being on the corporate network. In the past this involved deploying reverse proxies and lengthy conversations with the networking team. One excellent option  now available is the Azure AD Application Proxy. That team has an excellent walkthrough on configuring SharePoint 2013 and Azure AD App Proxy to work together, these same steps also work for SharePoint 2016. You can visit their blog for details but the basic steps are:

1. Ensure SharePoint web application pools are running under a service account (any production SharePoint farm should already be configured this way)
2. Configure SharePoint for Kerberos authentication
3. Create SPNs and configure Kerberos Constrained Delegation (KCD)
4. Publish SharePoint through Azure AD App Proxy
5. Configure AAMs in SharePoint for the external URL
6. Assign users to the Azure AD App Proxy

With the above guidance I was able to publish Sharepoint externally in <30 minutes. However, there are a few scenarios that the above blog above does not cover, three of these will be the focus for this post:

1. A SharePoint 2016 farm using host header site collections
2. Office Online Server
3. Using the same URL internally and externally for SharePoint

This post will not cover the core configuration for Azure AD Application Proxy for SharePoint as that is already covered here.

Host Named Site Collections

First let's see how site collections in my farm are addressed:

 Get-SPSite | FT URL, HostHeaderIsSiteName -AutoSize

Each site where HostHeaderIsSiteName = True is configured as a HHSC

For this demo, I am going to publish sites which have the host name sharepoint.xxxxxxxxxxxxxx.co. In a traditional path based environment we would use alternate access mappings, but these will not work for HHSC. Fortunately we have similar functionality available to use by using Set-SPSiteurl

The documentation for Set-SPSiteUrl has an important note:
The Set-SPSiteUrl cmdlet only applies to the root site collection for a host name that is, https://www.contoso.com . This cmdlet cannot be directly run against a managed path site collection underneath the root that is, https://www.contoso.com/sites/test .

What does this mean? In my example where I want to publish three sites, I only have to run Set-SPSiteUrl against one site collection.

Set alternate URLs for SharePoint host header site collections

PS: Get-SPSite https://sharepoint.xxxxxxxxxxxxxxx.co | Set-SPSiteURL -Zone Extranet -url https://sharepoint2016-xxxxxxxxxxxxxxxxx.msappproxy.net/

This will set the alternate URL for all site collection that share the hostname sharepoint.xxxxxxxxxxxxxxx.co

 Get-SPSite | ?{$_.url -like "https://sharepoint.xxxxxxxxxxxxxxx.co*"} | Get-SPSiteURL | FT -AutoSize

Test access

I can now access the site over the internet using the default App Proxy URL:

Office Online Server (OOS)

Note: OOS is the new version of Office Web Apps (WAC)

What if I want to edit a document in the browser using Office Online Server? Unfortunately when I attempt to open a word document in the browser, I get an error:

Taking a look at the page source we can see why. Office Online server renders in an iframe which is pointing back to a URL that I have not published:

 <form target="WebApplicationFrame" action="https://officeonline.xxxxxxxxxxxxxxx.co/wv/wordviewerframe.aspx?ui=en%2DUS&rs=en%2DUS&WOPISrc=https%3A%2F%2Fsharepoint%2Exxxxxxxxxxxxxxx%2Eco%2Fsites%2FTeamSite1%2F%5Fvti%5Fbin%2Fwopi%2Eashx%2Ffiles%2Fb40646494c8c48d9a31d4156918f2a07&wdEnableRoaming=1" id="canvas_form" method="post">

A couple notes about Office Online Server

1. OOS can be configured with both an internal and external URL
2. SharePoint can only be bound to one URL for OOS. I cannot set a different OOS URL for default and extranet zones.
3. SharePoint users do not authenticate to OOS using Windows integrated authentication. Instead an authorization token is included in the request to the OOS server. This means that we do not need to configure Kerberos Constrained Delegation (KCD) when publishing OOS

Give the above conditions I must publish OOS using the same URL that I do internally. Because we use an authorization token, some of the publishing settings will be different than for SharePoint using Windows authentication.

First, I can check which URL is being used for OOS by running Get-SPWOPIBinding from my SharePoint farm:

Second, Offline Online Server does not support pre-authentication, so it must be configured for passthrough authentication.

Note: Since passthrough authentication is being used, it is important to lock down host domains for which Office Online Server will allow file operations.This will prevent a SharePoint farm, or other servers, from unauthorized domains from binding to this farm.

Third, set the external URL to be the same as the internal URL for the application (and make sure your external DNS has a CNAME set as instructed in the portal):

Fourth, upload a SSL certificate for the URL specified. This certificate must be trusted by any machine that will be accessing SharePoint. OOS does not play well with untrusted certificates.

For this example I'm using a wildcard certificate but this is not a requirement.

Fifth, configure the internal authentication for OOS to "none." Remember, this is handled by an authorization token passed as part of the request.

Test Office Online Server

Now that this is configured I can access my SharePoint site over the internet and also use OOS

Publish a Friendly URL for SharePoint

The third change to cover is publishing SharePoint using the same URL that is used internally. This is very similar to configuring OOS.

First configure the Azure AD App Proxy to use the same URL that is used internally

Second, create a public facing CNAME record

Third, upload a certificate. Since I have wildcard certificate, I’m using the same one as I did for OOS

Test access

Now I can access my Sharepoint 2016 on-prem site over the internet using the same URL that I do internally

 

Next Steps

With the above information and the original Azure AD App Proxy blog for publishing SharePoint 2013 we can now access our SharePoint 2016 farm over the internet and all get full functionality of Office Online Server. Since this is being handled by Azure AD we can also add functionality such as multifactor authentication or allow users to self-assign access to this service through Azure AD.

 

Additional Resources

Azure AD Premium (AADP is also included with EMS)
https://azure.microsoft.com/en-us/documentation/articles/active-directory-editions/#application-proxy

How to provide secure remote access to on-premises applications
https://azure.microsoft.com/en-us/documentation/articles/active-directory-application-proxy-get-started/

Enable Application Proxy in the Azure portal
https://azure.microsoft.com/en-us/documentation/articles/active-directory-application-proxy-enable/

Publish applications using Azure AD Application Proxy
https://azure.microsoft.com/en-us/documentation/articles/active-directory-application-proxy-publish/

Working with custom domains in Azure AD Application Proxy
https://azure.microsoft.com/en-us/documentation/articles/active-directory-application-proxy-custom-domains/

New-OfficeWebAppsHost
https://technet.microsoft.com/en-us/library/jj219459.aspx

Comments

• Anonymous
  November 01, 2016
  Hello Damian,I want to have the internal and external url the same and I think I configured the same as described above but I keep ending with the error message: The service detected a possible loop. Make sure that the internal URL doesn't point to the external URL of any application. Can you give a hint how to overcome this?Kind regards,Mario
  • Anonymous
    November 01, 2016
    Hi Mario,If you ping your SharePoint/OOS address from a machine inside your network, does it resolve to an internal or external address? I suspect what is happening is that the machine where the AADAP connector is deployed is resolving this to an external address. Instead this should resolve to your internal address for SharePoint/OOS.
• Anonymous
  February 15, 2017
  One more scenario.. if SharePoint 2016 is currently integrated with ADFS (i.e. SAML based login).. can this still be published through Azure AD Ap Proxy?
  • Anonymous
    February 15, 2017
    Hi Anthony,I have not tested this scenario, but I think that passthrough authentication would work, assuming that ADFS is also available externally. Azure AD App Proxy also has a SAML based single sign-on that I have not tested with SharePoint.