2

We have a SharePoint 2013 web application configured to use Windows/NTLM and a Trusted Identity Provider (ADFS) on the same default zone. If I perform a search as a windows user, I see results. If I perform a search when logged in as an ADFS user, I see no results.

The 2 user accounts I am using to test are in the Owners group. Both can actually browse to the files that I expect to see in the results. The libraries do not have content approval enabled so no need to publish.

I've tried full crawls, and even reset the index and recrawled. I turned logging up to verbose and ran a few queries. I couldn't find anything relevant in the logs, especially about permissions or access. The crawl logs look good too, but obviously things are getting crawled because the windows user gets lots of results.

The ADFS claim was added to the Owners group using LDAPCP from CodePlex. User Profiles are importing fine as far as I can tell. User profiles exist for both my users.

Another thing I tried was setting "ForceClaimACLs" on the search service application as recommended in Search indexing but not returning results in Claims authenticated web apps.

Update:

Based on the suggestion by @kesava, I have reconfigured my web application to have 2 zones. The default zone just uses windows auth and search crawls this. The intranet zone uses ADFS only. This hasn't made a difference as far as I can tell.

I have noticed a new message in ULS but I am not sure if it is relevant. During the query processing it says "IdentityClaim from STS differs from known type". I haven't found any solutions based on this yet. Based on what I have read, this might be because the claim my STS is providing (windowsaccountname) is "undocumented".

I will continue to examine the ULS logs to see if I can tell what is causing no results.

Any suggestions on how I can troubleshoot this further?

0

my suggestion to this kind of environment is to have an extended web application in to a separate zone and then configure the LDAP based user authentication.

This is the more realistic way of handling LDAP or forms based user authentication. so the default zone with windows authentication will be used for search crawling as well as regular windows based AD login.

  • According to this post on TechNet, there can also be issues with multiple zones. I will try this but I was hoping to keep it at one zone. I'll post back once I've tried this out. – Lance Aug 17 '15 at 15:24
  • No luck with creating separate zones. I've added more to my question based on this trial. – Lance Aug 17 '15 at 21:33
  • what is the account you are using for search crawling. is it windows AD domian account ? does it have enough permissions on the content databases. is your secured store service running fine. – kesava Aug 17 '15 at 21:45
  • the search crawl account is a windows AD account. It should have sufficient permissions because there are no errors in the crawl log and I do get results when I log in with windows auth. regarding secure store service, can you please clarify why that is relevant in this scenario? I'm not storing any credentials for external systems. – Lance Aug 17 '15 at 22:52
  • sorry, i mean STS bacause the web app would be a claims based authentication. – kesava Aug 18 '15 at 2:45
0

This has been resolved by deleting the web application and search service application and recreating them from scratch. Search results now appear as expected for both ADFS and windows users.

I'm not really sure why it wasn't working because I wasn't able to recreate the issue in a different farm.

Also, it turns out the error "IdentityClaim from STS differs from known type" was irrelevant. I still get that even though I am getting results. I think the reason for that warning is that we are using "windowsaccountname" as the identity claim but it is not one of SharePoint's built in claim types. Try running Get-SPClaimTypeEncoding in PowerShell and you won't see it there.

0

if that claim isn't listed you need to add it or security trimming will occur for your ADFS userse

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.