Is it possible to pass through authentication to federated search source in SharePoint Server 2010/2013?

Posted on 2016-10-07
Last Modified: 2016-10-15
We have a SharePoint Server 2010 installed internally and another ASP.NET web application using Windows Authentication (same domain and same set of users as SharePoint). We want to configure ASP.NET web application as an external federated search source on SharePoint, it is running fine with Anonymous authentication for configured Federated Locations (using OpenSearch 1.0/1.1 protocol).

However, we would like to configure SharePoint to pass through or authenticate the ASP.NET web application using the same user account logged on SharePoint Sites. But we haven't found any way to do it yet.

Is that possible? And how to achieve that?
Question by:Duy Pham
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 2
LVL 40

Expert Comment

by:Kyle Abrahams
ID: 41834209
You're looking at single sign-on.  You can use ADFS to achieve that:
LVL 10

Author Comment

by:Duy Pham
ID: 41834335
@Kyle:  Sorry for not to make the question clear that we are looking for a solution without AD FS. It is not because we can't use AD FS. We actually have used AD FS since 2013 for several applications, but this request came from a customer whose IT Department would prefer a solution where they don't have to setup and re-configure their SharePoint Servers using AD FS.

Is there any other option to pass through logged-in user identity from SharePoint Server to external Federated Search Source? We have tried different Credentials option with Federated Locations but none of them works even when testing internally.
LVL 40

Accepted Solution

Kyle Abrahams earned 500 total points
ID: 41834351
Are they both hosted on the same server?  And just to confirm the Sharepoint site is using windows authentication as well?

I found a little bit more info here:

But haven't tried anything without adfs.

Just another thought.  It's possible to grab the current user in sharepoint.  You could have a public landing page that accepts the user as an input parameter.  For security I would create a token (guid) that was stored in the DB.

The flow would be:

Sharepoint -> Create Token (stored in DB), Get User -> Redirect anonymous page in application, passing username & token.

Landing page -> Check token against DB, make sure it's still active compared to the user.  If both succeed -> Login () else -> Fail();

I've mimicked SSO for non adfs applications like that in the past.
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

LVL 10

Author Comment

by:Duy Pham
ID: 41834388
@Kyle: No they are not on the same server. And SharePoint does use Windows Authentication. Maybe we need to configure Kerberos Delegation?

We are actually working on the solution to pass SharePoint User as input parameter to ASP.NET Web Application :). But to be honest, I don't prefer this solution because kinda the same as using AD FS, SharePoint Servers needs to be manually modified with an extra extension page to grab and pass user to ASP.NET Web Application.
LVL 40

Expert Comment

by:Kyle Abrahams
ID: 41834426
Kerberos Delegation should work in that case.   Something to look into and understood about re-inventing the wheel.

Here's a guide for Kerberos Setup in Sharepoint:

and for the website:

I would think they need to have the same service account for the SPN . . . but I run all my apps under a service account anyway.  Not sure if your client has restrictions regarding that.
LVL 19

Expert Comment

by:Walter Curtis
ID: 41834634
You description of your problem seems to be somewhat confusing, but this may be what you are looking for;

It is possible to use an alternative authentication account when content is searched in SharePoint. That is achieved via the Search Service Administration of Central Administration. Create a search content source as usual, (also applies for federated searches.) Once the content source is created, create a crawl rule, specifying the account to use for the URL that needs to use a different account. (See screen shot).

Keep in mind that this account will only be able to crawl what the account has access to. If you have a security layer on your application that is using the same domain and users as SharePoint, the search results page will trim those results to show only what the user has access to. This needs to be completely tested however because the application may not be configured correctly to work with SharePoint security trimming.

Hope that helps...
LVL 10

Author Comment

by:Duy Pham
ID: 41844653
@Kyle: We have succeeded to configure to pass-through SharePoint authentication to my web application. It turns out to be that we only need to configure for Kerberos Delegation particularly for Application Pool Identity running the web application.

@SneekCo: Thanks for your help, but neither security trimming nor fixed search account could cover our needs.
LVL 10

Author Closing Comment

by:Duy Pham
ID: 41844655
Kyle's recommendation is exactly what we are going for since we need to transform (SharePoint) Windows Credentials to SAML based security token for consuming claims-based search service.
LVL 19

Expert Comment

by:Walter Curtis
ID: 41844988
Glad you got it working...

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

After seeing many questions for JRNL_WRAP_ERROR for replication failure, I thought it would be useful to write this article.
Microsoft Office 365 is a subscriptions based service which includes services like Exchange Online and Skype for business Online. These services integrate with Microsoft's online version of Active Directory called Azure Active Directory.
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Suggested Courses

617 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question