I have a web application with an ADFS 2.0 trusted identity provider, and it's the only authentication provider. When I login, SharePoint correctly associates me with the my stored profile, but calls to GetUserProfileByName in UserProfileService.asmx fail even after manually setting AccountName to DOMAIN\USERNAME.

I've tried querying through a UDC that had stored domain credentials too with no success. The error I'm getting when calling the GetUserProfileByName is:

The following query failed: GetUserProfileByName (User: 0e.t||, Form Name: TestGetUserProfileSITESTEST_PUBnew, IP: , Connection Target: dc/UserProfileConnection.udcx, Request: /_layouts/FormServer.aspx?XsnLocation=/FormServerTemplates/TestGetUserProfileSITESTEST_PUBnew.xsn&SaveLocation=/up&Source=/up/Forms/AllItems.aspx&DefaultItemOpen=1, Form ID: urn:schemas-microsoft-com:office:infopath:TestGetUserProfileSITESTEST-PUBnew:-myXSD-2011-07-26T21-38-47 Type: DataAdapterException, Exception Message: The remote server returned an error: (500) Internal Server Error. Server was unable to process request. ---> Attempted to perform an unauthorized operation. The remote server returned an error: (500) Internal Server Error.)

If I extend the web application and add Kerberos or NTLM authentication to the new zone, the UserProfileService works fine in the new zone.

I cannot get the UserProfileService to work for trusted identity providers. Has anyone found a solution?

  • From what I've read and heard, some things don't yet work under claims based authentication. If you are able I strongly recommend logging a bug with Microsoft to resolve the problem. In the meantime, make sure you keep up with the latest cumulative updates.
    – Alex Angas
    Commented Sep 12, 2011 at 3:25
  • I am sailing in same boat as you did sometime back. Did you find an answer for this? I need to implement a project based upon this and its just not working. I found a code to convert the Claims to classic and vice-versa in the following link, but don't know where to put it up :( I packaged the form in Visual Studio solution which just helps me in migrating it over to production. But I did not find a place to put that code. Please revert asap. blog.mastykarz.nl/programmatically-converting-login-name-claim Regards Pooja
    – user4958
    Commented Sep 23, 2011 at 8:32
  • Is this the only web service that fails when authenticated using claims in your environment? For example, does the Lists web service work? Have you tried turning on verbose logging and monitoring the farm ULS using UlsViewer or something like that during the request? Commented Jan 31, 2012 at 19:48
  • Have you solved this problem?I have tried all option I am using claim base Kerberos base authentication?
    – user7645
    Commented Mar 30, 2012 at 22:53

5 Answers 5


InfoPath Form Services does not support claims based authentication (that's what MS Support told us, when we faced a similar issue with Nintex Workflow.asmx about a month back).

If you look in the IIS logs you will see that the calls to the UserProfileService.asmx are getting made as nt authority\anonymous user instead of the currently logged in user. This happens because FormServer when making the call to the WS is able to use only Basic or Digest mode for passing credentials.

You can fix the issue temperorily by using the udcx:Authentication tag of the udcx file, either by speciying a hard coded user name and password or setting it up to use Secure store service. This fix works because the GetProfileByName method does not require the the currently logged in user to be imperonated when making the call.

But sooner or later you would come across a scenario in which you need to make a call to a Web Service that requires that the call be made using the logged in user's credentials (for eg: GetRunningWorkflowTasksForCurrentUser method in Nintex Workflow.asmx), which would fail if you are using InfoPath Form Services in a Claims based environment


First, it looks like you are trying to make a call to the web service from InfoPath using a data connection library using udcxs. Have you tried hard coding the URL reference into the InfoPath form? Are you seeing this failure when it is published, or in preview mode?

Second, you may be running into the relative nature of virtual SharePoint directories. In this case _vti_bin. The _vti_bin folder doesn't actually exist, it just a pointer. The section of the URL previous to the _vti_bin determines the context, and the last part (UserProfileService.asmx) specifies the file.

Can you navigate to the Url that you are using for the UserProfile service directly? It should pop up a webservice command list. Your url should also match the area where you are working (publish location). Ie. https://<your server>/_vti_bin/UserProfileService.asmx is wrong, it will run at the top level context. Rather it should be https://<your sever>/<your publish-work location>/_vti_bin/UserProfileService.asmx

  • I think I will open a new question to chase my problem which is close to this one (and perhaps a simpler configuration). Your explanation about the relative location above was very interesting. I browse to server/_vti_bin/UserProfileService.asmx and it shows all the web methods available there. Then I browse to server:81/mysites/myname/_vti_bin/UserProfileService.asmx expecting to get error but it is in fact exactly like you described. I remain a bit confused about how that affects my issue which I will now describe in a new problem. Thanks!
    – John Adams
    Commented May 20, 2013 at 19:24

I would have checked that WebDAV is enabled on the server.

MSDN article Building SharePoint Applications with InfoPath 2010 (Part 2 of 2) (MSDN refresh) tells in context ow walkthrough on using GetUserProfileByName SOAP service:

  • " Important:

    The SharePoint application and code described in this article will not work if SharePoint is configured for forms-based authentication. To work correctly, the web application that hosts this SharePoint application must be configured to use classic-mode authentication. For more information about configuring SharePoint authentication, see Plan authentication methods (SharePoint Server 2010)".


I was faced with a similar issue and ULS logs gave the same error. You should check the visitors permission to the site collection. I had the "everyone" group in there and connection would fail with 500 error, BUT once I added the

"NT AUTHORITY\Authenticated Users"

to the visitors group the connection started to work. My guess is that as stated above that the web service call is using the user set up in IIS as state above by "SharePoint Dude"

I didn't convert my connection to a .udcx file on this specific connection but if you do make sure to edit your .udcx file and replace the line:

<udc:Authentication><udc:SSO AppId='' CredentialType='' /></udc:Authentication>

with the following code:

<udc:Authentication><udc:SSO AppId='InfoPathWebService' CredentialType='NTLM' /></udc:Authentication>

Hope this helps someone in the future.




I'm pretty sure the CredentialType is case sensitive and should be "Ntlm" -- according the documentation on the udcx schema from Microsoft.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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