Collaborating beyond the firewall

Over the past few years, there has been a shift on organizations collaboration requirements. Initially, implementing SharePoint was an internal thing only, then over time it would turn into an Extranet or maybe a Public facing web site. For the work, I have done over the past 10 years, the decision to move in this direction was actually tied to business verticals. For example, financial organizations invested in SharePoint for internal use only, where many non-profits and associations implemented full extranet and public facing web sites over an internal intranet.

Today it makes no difference, the requirement to share with external parties, cross collaborate between single or multiple companies is now a top priority.

The problem with this requirement is that not every organization can do this successfully, purely based on infrastructure costs and deployment. Extending an internal SharePoint environment outside the corporate firewall, even though simple, becomes a very complicated solution, especially when you talk about Authentication.

Microsoft have created guidance for setting up external access, using hardware such as reverse proxy servers, combined with Active Directory or Active Directory Federated Services as the authentication store.

• https://technet.microsoft.com/en-us/library/dn607304.aspx
• https://blogs.msdn.microsoft.com/sambetts/2014/04/02/setting-up-a-reverse-proxy-for-sharepoint-with-tmg-server/

Though I am a big advocate of this design, this does not make those trying to authenticate outside who are not part of the company easy. With SharePoint 2016 being the standard (or should be) for On-premises installations, the newer option is to utilize some of the cloud services, that are now part of the Hybrid design or can be utilized if you have an Office 365 tenant as well.

To achieve this, the following steps need to be completed:

1. Ensure SharePoint web application pools are running under a service account
2. Configure SharePoint for Kerberos authentication
3. Create SPNs and configure Kerberos Constrained Delegation
4. Publish SharePoint through Azure AD App Proxy
5. Configure Alternate Access Mappings in SharePoint for the external URL
6. Assign users to the Azure AD App Proxy

Ensuring the applications pools are running under a service account is one thing you should not have to worry about. If you SharePoint environment is not configured this way, you may have slightly bigger issues to worry about.

Kerberos authentication is made up of a couple of parts, the first and easy part is ensuring the web application in SharePoint is set to use Kerberos.

1. Open the SharePoint 2013 / 2016 Central Administration site.
2. Under Application Management click on Manage web applications and select your SharePoint site

3. Next click on Authentication Providers in the tool bar above
4. In the dialog box titled Authentication Providers click on the Default zone to view the settings.
5. In the dialog box Edit Authentication, scroll down to you see Claims Authentication Types and ensure that both Enable Windows Authentication and Integrated Windows Authentication are both checked and the drop-down box is configured to Negotiate (Kerberos).

6. Scroll to the very bottom and click on Save.

To completed the Service Principal Names, you need to run the following command:

setspn -S http/{SharePoint Site URL} DOMAIN\User

Obviously, change the URL to match your SharePoint URL, and set the account to be your service account in your domain and on your SharePoint servers. You can verify the Service Principal Name was added by running the setspn command with the -l option.

setspn -l DOMAIN\User

Once the Service Principal Name is added and you have checked, next you need to set the delegation within Active Directory itself.

1. Login as a domain administrator to a Domain Controller and open Active Directory Users and Computers.
2. Find the computer that the connector is running on, in my case it is the same server SharePoint.
3. Double Click on the computer and then click on the Delegation tab.
4. Ensure the delegations settings are set to Trust this computer for delegation to the specified services only and the select option Use any authentication protocol is selected similar to the following.

5. Now we are going to add the Service Principal Name that we created earlier for the service account by clicking on the Add button, then Users or Computers and using the service account.
6. This should give you a list of Service Principal Names to use. You only need to add the one that you set previously, then select that item and click on OK.
7. Click on OK again to save the change.

Now it comes down to just setting the values needed within the Azure Active Directory Proxy screens.

1. Log in to the Azure Management portal https://manage.windowsazure.com and find your Azure AD Tenant.
2. Click on Applications and click Add at the bottom.
3. Select Publish and application that will be accessible from outside your network.
4. In the resulting dialog box complete each of the 3 options as follows then click on the tick:

Name – Any value

Internal URL –Internal HTTPS URL of the SharePoint site.

Pre-Authentication Method – Select Azure Active Directory.

1. Once the app is published, click on Configure tab.

1. Scroll down to the option that reads: Translate URL in Headers, set this value to No.
2. Change the Internal Authentication Method to Windows Integrated. If your Azure AD tenant uses a different User Principal Name in the cloud to the one on-premises, then update the Delegated Login Identity.
3. Set the Internal Application SPN to the value set earlier.
4. Publish the site

At this point, you need to set the Alternate Access Mappings so the suite can load. Now the gotcha, just because you went through all of that does not mean that the 3^rd party email address you want to collaboration with is going to get in. This is where the issue arises, choosing a solution that will allow true external collaboration. Luckily using Azure Active Directory, you can allow other users in and assign them access. This is purely because Azure Active Directory supports this type of authentication.

Now let’s break it down, if this was me doing this, and there was a big need for external collaboration I would now seriously consider Office 365. Everything is ready to go and you can then just share with external users as needed knowing that they will be able to set their account up to login into Office 365 services and gain access to only the content or sites you have granted them access too.

More details on external sharing can be found here:

https://support.office.com/en-us/article/Share-sites-or-documents-with-people-outside-your-organization-80e49744-e30f-44db-8d51-16661b1d4232

https://support.office.com/en-us/article/Manage-external-sharing-for-your-SharePoint-Online-environment-C8A462EB-0723-4B0B-8D0A-70FEAFE4BE85

All in all, the idea of collaboration beyond the firewall, has always been here, it has always been a more challenging design and option, purely because of the authentication. With Office 365, this gap and concern has now been closed and should be the standard you now choose.