Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
    
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 Sep 12 '11 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 Sep 23 '11 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? –  Alexey Krasheninnikov Jan 31 '12 at 19:48
    
Have you solved this problem?I have tried all option I am using claim base Kerberos base authentication? –  user7645 Mar 30 '12 at 22:53
add comment

3 Answers

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

share|improve this answer
add comment

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

share|improve this answer
    
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 May 20 '13 at 19:24
add comment

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)".

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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