SharePoint 2013, InfoPath and Claims – GetUserProfileByName

You would not believe the hoops you have to go through to get data auto-populated in an InfoPath Form if you’re using Claims-based authentication, which I believe is the default in SharePoint 2013.

The Scenario:

You have an on-premise SharePoint 2013 Server installation with InfoPath Forms Services (so you have enterprise) and you want to create an InfoPath form that auto-populates a logged in user’s ID, email, and phone number.  You are using Claims-based authentication in the web application in question.

In this scenario, I’m using InfoPath Designer 2010 – I haven’t upgraded to 2013 yet, but I don’t think it makes a difference.

The Problem:

When you use Claims-based authentication, your user name is prefaced by “0#.w|”.  So for example, if your user name is SuesDomain\jdoe then your Claims-based user token will be, without the quotes:     “0#.w|SuesDomain\jdoe”

InfoPath can’t handle that, or more specifically, the UserProfile.asmx method GetUserProfileByName method can’t handle that.  InfoPath tries to pass in your Claims-based user token instead of your domain\User Name.

You get 2 problems – you have an authentication problem where the currently logged in user is not allowed to hit the web service, so you get an Access Denied 401 authentication error.  The second problem is getting the right user from the web service.

The Solution:

The steps you have to take are listed here.  See the reference posts for more details and pictures.

  • Have your Active Directory team create you a User Name and Password for a “generic” InfoPath Account.  The one I created was called Domain\SP2013_IPRdr for “InfoPath Reader”.
  • Have the Central Administration team create a Secure Store service application, if they don’t already have one.
    • Generate the Secure Store key if you haven’t already.
    • Create a new application in the Secure Store called something like InfoPathGUPBN (“GetUserProfileByName” is what the acronym stands for); target application type is Group, and User Field Types are the Windows User Name and Password.
    • Set the credentials:  Whomever you want to administer the application should be set as the Target Application Administrators and for the Members, select All Users.
    • Set the Credentials to the Application and use the User Name and Password that you received from the A/D team, example Domain\SP2013_IPRdr.
  • In SharePoint 2013 – in the site you wish to publish your form to, create a Data Connection library.
  • Go Into InfoPath and go to your GetUserProfileByName secondary data connection.  If you don’t already have one, you can create one the “normal” way, making sure you do not choose a user name (just like you would normally do).  For an example of how to set one up, see the first reference in the section at the bottom of this post.
  • Modify the GetUserProfileByName secondary data connection so that it does NOT automatically load the data upon form load.  This is not required, but saves performance.
  • Convert the GetUserProfileByName secondary data connection into a UDCX file (“Convert to Connection File”) – store it in the Data Connection Library that you created a few steps ago.
  • Download the UDCX file that you just created from your SharePoint 2013 Data Connection library and put it on your desktop.  Edit it in Notepad.
  • Change the commented out line to read something like this (depending on what you called your Secure Store Application):
    <udc:Authentication><udc:SSO AppId='InfoPathGUPBN' CredentialType='NTLM' /></udc:Authentication>
  • Upload the UDCX file back in to the Data Connection Library.
  • Publish your newly changed InfoPath form into your SharePoint 2013 InfoPath Form Library
  • Make sure to give your special A/D account, for example the Domain\SP2013_IPRdr account, full read access to that site, so that they have permissions to hit the web service.

All of the above was just to get you to Authenticate properly with the Web Service.  If you were to stop now, and try to get the information from the web service you would get the information for the user Domain\SP2013_IPRdr.  Not the logged in user.  Now you have to take the following steps to get the real logged in user:

  • Go into InfoPath and go to create a Form Load rule
  • For the first rule, call it “Set User Profile” or something similar
    • Create an action to Set a Field’s Value
    • Choose the field – it’s the GetUserProfileByName secondary data connection, in the queryFields node, all the way in:  AccountName.
    • Set it to the following formula value:
      substring-after(userName(), "0#.w|")
    • Add another action, Query for Data, and choose your GetUserProfileByName secondary data connection
  • For the second rule, call it something like “Set Fields”
    • This is where you fill in your fields from the data source.  To find a good example of how to do this, see the first reference in the section at the bottom of this post.

Bottom line:  Pain in the rear.

References:

Advertisements

Author: Susan J Hernandez

Fantasy Writer; SharePoint 2010/2013 Developer

26 thoughts on “SharePoint 2013, InfoPath and Claims – GetUserProfileByName”

  1. Hi Susan, thank you very much for this very helpful post. 🙂

    Just a follow-up question, if for example we want to get the user’s Manager, will the function return the manager’s account name in the form of claims (0#.w|contoso\amber.lee) or the standard form (contoso\amber.lee)? Right now, we are getting contoso\amber.lee. Is this the default behavior? Or should we be expecting it in claims notation? Thank you!!

    1. I am no expert on this, but I believe that getting the Manager, you’re getting it from the User Profile Web Service, which is getting it from the User’s SharePoint Profile. My assumption is that either the UPS or the Web Service is handling the account and stripping out the claims tokens. I have experienced the same behavior you have.

    1. Could you please specify exactly what account name you’re setting by printing it out somewhere on your form (you don’t have to tell me the account name, just verify that it has correctly stripped the Claims token characters off). Also, what is the error message you’re getting?

      1. I mapped an full privileged account in the secure store, then its working but I always get the same user info for any account I try with. Then is the part of changing the account name to current username, yes the claim tokens are being stripped off I check it. The error is “Error accessing the web service” error 5566

      2. Do you have access to the server on which SharePoint is hosted? The “ULS Logs” will probably have more detail for you. I did a little checking and it seems that error 5566 is often a problem with no access to the web service (permissions). You say you mapped a full privileged account in the secure store, can you double-check to make sure that account has at least Read access in the EXACT web site where the user profile service data connection is being made, i.e. the GetUserProfileByName url? If you can get the ULS logs that will help you in determining where the problem lies.

  2. I don’t much information in the ULS logs either. It says WCFLogging:Begin UserProfileGetProperties and end UserProfileGetProperties. Thats what I see in the ULS Logs.

    For me I get It working untill the rules, when I add the AccountName = substring-after(userName(), “0#.w|”) and query the data source that is where its throwing the error.

  3. Really nice (and thorough) post but I have a minor suggestion . Instead of setting the formula to “substring-after(userName(), “0#.w|”)” . I would suggest you just use “substring-after(userName(), “|”)” because the claims token can vary.

  4. I have followed the directions exactly and we are still receiving a 401 Authentication error when trying to hit the Web Service:

    The following query failed: GetUserProfileByName (User: 0#.w|domain\current_user, Form Name: ServiceRequest_r1-7-1_20140428, IP: , Connection Target: http://site/IS Data Connection Library/GetUserProfilebyName.udcx, Request: http://site/SitePages/Worker.aspx, Form ID: urn:schemas-microsoft-com:office:infopath:ServiceRequest-r1-7-1-20140428:-dataFormSolution Type: DataAdapterException, Exception Message: The remote server returned an error: (401) Unauthorized. The remote server returned an error: (401) Unauthorized.)

    The udcx file is configured for the new Secure Store:

    It seems like the Data Connection is still trying to connect to the Web Service using the current logged in user rather than the user specified in the SSO “UPASS”.

    Any suggestions for where else I may look?

    Thank you,

    Eric Magnuson

    1. OMG, you fixed the exact issue I was having. Thank you so much for solving this massive headache for me. Fixed the 401 unauthorized messages for me. Thanks a ton for this. In case that link stops working, here is the work around info from the KB link:

      here are two methods to work around this issue, use one of the following methods, as appropriate for your situation.
      Method 1: Specify host names (Preferred method if NTLM authentication is desired)

      To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:
      Set the
      DisableStrictNameChecking
      registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
      281308 Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
      Click Start, click Run, type regedit, and then click OK.
      In Registry Editor, locate and then click the following registry key:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
      Right-click MSV1_0, point to New, and then click Multi-String Value.
      Type BackConnectionHostNames, and then press ENTER.
      Right-click BackConnectionHostNames, and then click Modify.
      In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
      Quit Registry Editor, and then restart the IISAdmin service.
      Method 2: Disable the loopback check (less-recommended method)

      The second method is to disable the loopback check by setting the DisableLoopbackCheck registry key.

      To set the DisableLoopbackCheck registry key, follow these steps:
      Set the
      DisableStrictNameChecking
      registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
      281308 Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
      Click Start, click Run, type regedit, and then click OK.
      In Registry Editor, locate and then click the following registry key:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
      Right-click Lsa, point to New, and then click DWORD Value.
      Type DisableLoopbackCheck, and then press ENTER.
      Right-click DisableLoopbackCheck, and then click Modify.
      In the Value data box, type 1, and then click OK.
      Quit Registry Editor, and then restart your computer.

  5. Sue, I’m still having 5566 error issues. I read that you have to create a classic mode web app in sp2013, then connect the cuff through there. Is t his true?

  6. I get the information of the webapp application pool identity instead of the user opening the form. Has anyone else run into this issue?

    1. did you ever managed to get the actual username? I have the exact Problem, and I think I have configured everything correctly.

  7. Thank you so much! I spend hours to search for the problem, but never find the hint to add the “substring-after-rule”. Best regards 🙂

    1. WHat was the account credentials i need to give while setting credentials to application at SSO , I have given the account which we used to create all service applications on the server. I am still getting the error 5566.could anyone help me out as I am struck with this thing since 4 days. thanks all

  8. Hi, has anyone found the solution for the 5566 error? The logs show “Credentials in SSO (Windows=[no], Username=[yes], Password= [yes]) did not match the specified type “NTLM”.
    I am a bit stuck on this one. Any advise is welcome! Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s