search cancel

Unable to search for users or groups from SiteMinder in the PeoplePicker.

book

Article ID: 42186

calendar_today

Updated On:

Products

CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On

Issue/Introduction

Symptoms:

With the R12.52 SP1 Single Sign-On Agent for SharePoint 2010/2013, PeoplePicker searches from the Central Admin Server are not returning any results from SiteMinder, and there are no log entries written to the claimswebservicetrace.log. If I access the ClaimsWS URL directly in a browser (http://<Hostname>:<PORT>/ClaimsWS/services/WSSharePointClaimsServiceImpl) I am presented with the "Hi there, this is an AXIS service!" message showing that the service is running. A review of the web.config file for the Central Admin application shows that the endpoint has been added by the "Add-SMClaimSearchService.ps1" script.

 

<client>

      <endpoint address="http://<Hostname>:<PORT>/ClaimsWS/services/WSSharepointClaimsServiceImpl" binding="basicHttpBinding" bindingConfiguration="WSSharePointClaimsServiceImplSoapBinding" contract="SiteMinderClaimSearchService.WSSharePointClaimsServiceImpl" name="WSSharePointClaimsServiceImpl" />

</client>

 

If I copy the URL from the Web.config and enter it into the browser, then I receive an "AXIS error No service is available at this URL." error message.

 

Cause

The endpoint that is added to the web.config for the Central Admin Server and the SharePoint Applications by the "Add-SMClaimSearchService.ps1" script is case-sensitive, so care must be taken when running the script to add the Claims search web service to your SharePoint applications with the proper case for the "–claimSearchService" parameter value. The proper case for the URI portion is "/ClaimsWS/services/WSSharePointClaimsServiceImpl". A review of the web.config file shows that "WSSharepointClaimsServiceImpl" contains a lower case "p" in the word "Sharepoint".

Environment

Release:
Component: SMSPA

Resolution

You will need to either remove the exiting faulty Claims Search web service endpoint from the application's web.config file using the "Remove-SMClaimSearchService.ps1" script, and then re-add the service ensuring the proper case is maintained, or you can modify the endpoint in the web.config directly to correct the URI.

Additional Information

https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/single-sign-on-agent-for-sharepoint/12-52sp1/configuring/configure-sharepoint/configure-the-claims-provider.html