Issues in SharePoint when using a trust with Selective Authentication

If you ever have experiences with SharePoint, the concern of “Credential request” is probably not new to you, where you have to face that request 3 times before clicking the 401 Unauthorized. While trying to navigate from web-frontend server, we can see this happen a lot of times. Well… resolving this is like a walk in the park for a SharePoint admin. How? Either you use BackConnectionHostNames registry key or disable the loopback check in the registry. The process has been documented on https://support.microsoft.com/en-in/kb/896861 .

Before a month or so, one of our offshore SharePoint developers was in a meeting with a client of ours; this is when the client asked about a weird problem on the Extranet. He was having an issue with a different extranet domain. Extranet domain is in the internal domain, helps users from internal domain to get in to their accounts on extranet sites. Our client could do the same from the from the web front-end servers of the Extranet farm, however, when it came to doing the same from his laptop, he was unsuccessful.  On his laptop, he had to feed in his credentials and this continued to be failing… seems common right?

One of our Offshore SharePoint developers cross checked BackConnectionHostNames on the servers and made sure that key and hosts were there.

Furthermore, He tried the same process on our office computer and whoa!!It was working just fine. It was easy navigating to the site from office computer. However, when we tried doing the same by logging in his account, we failed. To make sure, we did this on several machines and we faced the same issue, it was a trouble signing in from any place.

We will inscribe the comparisons and checks we did and the good news is we were able to fix the issue.

Just like objects in Active Directory, servers in a domain are like user accounts. You get to Security tab while you open such properties in AD, where you can denote several permissions to particular Active Directory objects on a specific computer. “Allowed to authenticate” is one of those permissions. I was overtly established that permission for the Extranet farm servers, whereas from “Authenticated Users” the permission was not granted.

In normal situation, this doesn’t create any problem. This permission is not really required if you have one domain containing your users and servers. Additionally, you can keep the default trust authentication level (Forest-wide authentication) if you have multiple domains and a one-way trust, you will not be facing any problems with users from the trusted domain authenticating to resources in the trusting domain.

On the other hand, when you are making use of “Selective Authentication”, “Allowed to authenticate” should be explicitly granted, which gives permission to all the users to access the resources they need to.  When our offshore SharePoint developers confirmed this authentication level at the customer, we got affirmation that they were using selective authentication. Therefore, we had to give “Authenticated Users” this permission on the SharePoint servers in the AD of the Extranet to resolve this issue.

This post is brought to you by Softree Consulting

Softree Consulting employs SharePoint consultants, who are experienced in writing for a multiplicity of SharePoint verticals including technical, promotional, creative, branding content, cataloguing and ethical media comprising journalism.

With more than 10 years of industry experience these professionals have the best resources to deliver optimum results. They have been satisfying customers with some of the best SharePoint Strategies. In case you need experts for Offshore development for SharePoint 2016, we have got you covered.