Double Hop Issue in SharePoint and Custom Web Service

Background and Problem Statement

During development of a project with a client, we encounter double hope issue. We have a custom web-service hosted on a separate server. Web- Service authentication mechanism was set to windows (NTLM) authentication. From the web-service we creating and updating list items in one of SharePoint list.

But the problem was list item was inserting/updating with app pool user of web-service, not with current logged-in user. After research we found that this is double hop issue and we need to configure Karbrose authentication instead of NTLM.

Below diagram illustrates the architecture of the project:

IIS Configuration	Dw Web Server	Dw SharePoint Server
App Pool Identity	Domain\user1	Domain\user1
Windows Authentication	Yes NTLM	Yes NTLM
ASP.Net Impersonation	No	No
Anonymous Access	No	Yes
User Kernel Mode	No	No
App pool user trust for Delegation	No	No

With these above settings, when user was trying to insert/update some item in SharePoint list from client application, web server was not passing authentication token of currently logged-in to SharePoint because due to security reasons. Instead Web Server was passing App Pool Identity user credentials to SharePoint server. 

SharePoint server return unauthorized because It is not possible by design. It is called double-hop.

The first hop is when user hit web service and the second hop is when web service send request to SharePoint server. Windows is preventing double hop by design. To solve that we need Kerberos implementation.

Solution 

To solve the double hop issue, we have to use Kerbrose authentication. Below are the steps to configure Kerbros authentication and solve double hop issue.

Step 1: Start IIS Manager on your Web server, select the website and go to the Authentication section. Disable anonymous authentication and enable Windows Authentication

Step 2: Open the list of providers, available for Windows authentication (Providers). By default, two providers are available: Negotiate and NTLM. Negotiate is a container that uses Kerberos as the first authentication method, and if the authentication fails, NTLM is used. It is required that Negotiate comes first in the list of providers.

Step 3: Go to Advance Setting and unckeck “Enable Keneral-mode Authentication”.

Step 4: The next step includes the registration of Service Principal Name (SPN) entries for the name of the website, which will be accessed by the users.

Run setspn against the service account user used as App Pool user in DW Web Service.

setspn -u -s HTTP/<Web Service HOST Header> <Domain\User>

setspn -u -s HTTP/<FQDN> <Domain\User>

setspn -u -s HTTP/<SharePoint HOST Header> <Domain\User>

setspn -u -s HTTP/<FQDN> <Domain\User>

For example, below are the values:

Domain Name	Utest.org
DW Web Service Host Header	mywebservice
DW Web Service FQDN	mywebservice.utest.org
DW Web Service Host Header	mysharepoint
DW Web Service FQDN	mysharepoint.utest.org
App Pool User	Utest\iis_user

In above case setspn commands will be as follow:

setspn -u -s HTTP/mywebservice UTEST\ iis_user

setspn -u -s HTTP/mywebservice.utest.org UTEST\iis_user

setspn -u -s HTTP/mysharepoint UTEST\ iis_user

setspn -u -s HTTP/mysharepoint.utest.org UTEST\ iis_user

Step 5: Then go to web-service in IIS Manager and select Configuration Editor.

In the dropdown menu select system.webServer > security > authentication > windowsAuthentication

Step 6: Allow delegation for the UTEST\ iis_user so it can delegate the user authentication token from DW Web Service to SharePoint Server.

Go to Active directory, select app pool user, go to delegation tab and select, “Trust this user for delegation to specified service only”.

So the final changes will be as below:

IIS Configuration	Dw Web Server	Dw SharePoint Server
App Pool Identity	Domain\user1	Domain\user1
Windows Authentication	Yes Negotiate NTLM	Yes Negotiate (Optional) NTLM
ASP.Net Impersonation	Yes	Yes
Anonymous Access	No	No
User Kernel Mode	No	No
Use App Pool Identity	Yes	No
App pool user trust for Delegation	Yes	No

Step 7: Restart IIS on all servers. Now DW web service will be authenticated using Kerbrose and you wouldn’t encounter 401 unauthorized

Using JavaScript URL in Calculated Columns

In SharePoint 2013, if you wanted to use JavaScript in a calculated column to open the URL in popup, here is the simple and quick method to achieve the result. Calculated column can render the HTML.
Add a column in your list/library, select its type as “Calculated” and add the following:

="<ahref='javascript:OpenPopUpPage('http://sitecollection/subsite /Lists/Tasks/AllItems.aspx')'>Click Me</a>"

When I tested the above code, it didn’t work for me. When I inspect the html, I found that JavaScript breaks the URL part the script.

So, I added modified the HTML part is calculated column as follows:

="<a href='#' onclick= 'Openlink()'>Click Me</a>"

Now add a content query web part in the page and add the following script in it.

<script langauage="javascript">
function Openlink()
{
  OpenPopUpPage('http://sitecollection/subsite/Lists/Tasks/AllItems.aspx');
}

</script>

You can modify it according to your requirements. Hope this will work.

Multilingual sites in SharePoint 2013

SharePoint 2013 and SharePoint online has feature to enable languages support for users in different regions. To enable users to see sites in their preferred language, we can use these features. There are two type of translation in SharePoint:

a) Multilingual User Interface

b) Variations

Multilingual User Interface:

With Multilingual User Interface (MUI) feature users are enabled to see the SharePoint site in their preferred language instead of default language. MUI will translates the user interface in your preferred language. User interface include menus, navigations, site title and description, web parts, managed metadata, default columns etc.

How to configure MUI:

1) Download and install language packs on all SharePoint front end servers. You can download the language packs from the same location where you downloaded the SharePoint 2013.

2) Run the SharePoint product configuration wizard.

3)In SharePoint site setting, go to Alternate Language and check the languages you want your users to be enable to use to display the user interfaces.

Now there are two ways to configure MUI.

a) Change the language preference settings in User Profile settings to your preferred language.

·        Open MySites and go to About me

·        Click Edit your profile and Language and Regions

·        Select the language of your choice

b)  Change the language setting in your browser

i)  Select menu Tools

ii)  Select menu item Internet Options.

iii) Select tab General.

iv)Click button Languages.
v) Click button Add...

vi) Mark a language e.g. English (United Kingdom) and click OK.

vii) Reload webpage

Next time when you will visit the SharePoint site, it will be display in your preferred language instead of site collection default language.

Variations

Variation feature is used to translate the content if SharePoint site in other languages other than default language. Variation can only be used with publishing sites or the SharePoint with Publishing Infrastructure feature activated. Variations are designed to use when your content has to use for different regions, different markets and different cultures.

You can use variations to create sites, lists, and page content for specific languages. In this scenario, most of the content is authored in the language of the source variation site and synced to some or all of the target variation sites for translation into different languages. For example, the content might be authored in English and be synced to target variation sites for translation into German, French, and Spanish.

Source variation and target variation

The source variation site and the target variation sites are always created as subsites of the variation root site. Source variation and target variation sites are always created below the root site level. Each variation site will use the same master page as root site by default.  But each variation site can also use separate master page. Page layout and CSS files.

How to configure variations:

Below are the steps to configure variation source site.

1)      Create the site with publishing template and go to site settings--> variation settings

2)      On variation page Create Every Where will be selected. This means any content created in the source label is will be copied to all target sites. You can leave the other settings on page as default and proceed to next step.

3)      Select the language form drop down

4)      Select the locale for your site

Note: Locale is a regional setting that specifies the way numbers, dates and times are displayed on a site. The locale setting does not change the language in which the site is displayed. For example, selecting the Thai locale changes the default sort order of list items and uses the Buddhist calendar instead of the default calendar. Not to be confused between Language and Locale settings, even if language packs are not installed, Variation Labels for different locale can still be created and content can be translated into different languages. Language packs will only affect SharePoint user interface for content authors and admins

5)      Variations Home  is the location site where sub sites for all labels will be created

6)      Select label name, display name and template for your publishing site.

Now source label is created, a wizard will be shown in SharePoint 2013 to create the target label by following below steps:

1)      Select language of the site from drop down and select locales for the target variation

2)      On next page select the target label display name and site templates

1)      On next page there are two options for translation i.e. Human translation or Machine translation

2)      Next option is whether you wanted to automatically sync variations from source site or manually.

3)      Last step is to review all your settings. If everything is OK press Finish.

Configure Office Web apps server with SharePoint 2013

This article describes the procedure to connect the Office web app server with production environment. Unlike Office web app server 2010, the new Office web apps farm can serve multiple SharePoint 2013 farms plus Lync 2013 and Exchange 2013.This document will guide you in both cases whether you wanted to use Office Web Apps server with single SharePoint 2013 farm or Multiple Farms.

If you wanted to connect the Office Web Apps server with new SharePoint 2013 farm without disconnecting from previous SharePoint 2013 farm then follow the steps mentioned in “Procedure 1” or “Procedure 2” according to your requirements.

If you wanted to connect the Office Web App farm with only one SharePoint 2013 farm then first discounted the previous SharePoint 2013 farm by following the steps mentioned in “Procedure 3”. After disconnecting the Office Web Apps from previously connected farm, follow the steps mentioned in “Procedure 1” or “Procedure 2” according to your requirements.

Configure SharePoint to use Office Web Apps server

Choose one of the following sections depending on whether you want to use HTTP or HTTPS.

Procedure 1: Configuration using HTTP

Our Office Web Apps server is configured to allow HTTP. So, there is no need for any configuration on Office Web Apps server. There will be following steps to be perform on SharePoint 2013 server.

1.       Run SharePoint 2013 Management Shell with Administrator privileges.

2.       Create the binding between Office Web Apps server and SharePoint 2013 sever by running following PowerShell command.

New-SPWOPIBinding -ServerName <WacServerName> -AllowHTTP

<WacServerName> is the fully qualified domain name (FQDN) of the URL that you set for the internal URL

3.       View the WOPI zone for the SharePoint binding by the following PowerShell command.

Get-SPWOPIZone

The WOPI zone displayed by this command should be internal-http. If it’s displayed correctly, skip the next step. If it isn’t, see the next step.

4.       Change the WOPI zone to internal-http by following PowerShell command.

Set-SPWOPIZone –zone “internal-http”

5.       You can verify that the new zone is now internal-http by running Get-SPWOPIZone again.

6.       You need to set AllowOAuthOverHttp to True. Otherwise Office Web Apps won’t work. You can check the current status by running the following command.

              (Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp 

      If this command returns FALSE run the following commands.

               $config = (Get-SPSecurityTokenServiceConfig)

      $config.AllowOAuthOverHttp = $true

$config.Update()

7.       Run the following command again to verify that the AllowOAuthOverHttp setting is now set to True.

(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp

8.       Verify that Office Web App is working. In SharePoint 2013, make sure you’re not logged on as System Account because you won’t be able to edit or view the documents with Office Web Apps. Go to a SharePoint 2013 document library that contains Office documents and view a Word, PowerPoint, Excel, or OneNote file. The document should open in a browser that displays the file by using Office Web Apps.

Procedure 2: Configuration using HTTPS

As our Office Web Apps server is configured with HTTP, we have to reinstall the Office Web Apps. After installation open windows PowerShell and run the following command.

New-OfficeWebAppsFarm -InternalUrl "https://server.contoso.com" -ExternalUrl "https://wacweb01.contoso.com" -CertificateName "OfficeWebApps Certificate" –EditingEnabled

·         InternalURL is the fully qualified domain name (FQDN) of the server that runs Office Web Apps Server, such as http://servername.contoso.com.

·         ExternalURL is the FQDN that can be accessed on the Internet. This parameter is required if you wanted to allow external users to access Office Web Apps Server.

·         CertificateName is the friendly name of the certificate.

·         EditingEnabled is optional and enables editing in Office Web Apps when used with SharePoint 2013. This parameter isn't used by Lync Server 2013 or Exchange Server 2013 because those hosts don't support editing.

On SharePoint 2013 server side perform the following steps:

1.       Run SharePoint 2013 Management Shell with Administrator privileges.

2.       Create the binding between Office Web Apps server and SharePoint 2013 sever by running following PowerShell command.

New-SPWOPIBinding -ServerName <WacServerName>

<WacServerName> is the fully qualified domain name (FQDN) of the URL that you set for the internal URL

3.       View the WOPI zone for the SharePoint binding by the following PowerShell command.

Get-SPWOPIZone

4.       If the results from Step 3 show that internal-https and the SharePoint farm is internal only, you can skip this step. If you have a SharePoint farm that is accessed both internally and externally, you need to run the following command to change the zone to external-https

Set-SPWOPIZone –zone “external-https”

5.       Verify that Office Web App is working. In SharePoint 2013, make sure you’re not logged on as System Account because you won’t be able to edit or view the documents with Office Web Apps. Go to a SharePoint 2013 document library that contains Office documents and view a Word, PowerPoint, Excel, or OneNote file. The document should open in a browser that displays the file by using Office Web Apps.

Procedure 3: Discounting the SharePoint 2013 from Office Web Apps Farm

To disconnect the SharePoint 2013 from Office Web Apps server perform the following steps:

1.       Get the list of host machine which are allowed to connect with Office web apps server.

Get-OfficeWebAppsHost

2.       Removes a host domain from the Allow List for an Office Web Apps Server farm.

Remove-OfficeWebAppsHost -domain “contoso.com”