Some forms return a data source error when anonymous access is enabled

Consider the following scenario. You have a web application for which anonymous access has been enabled either through SharePoint Central Administration or in Internet Information Services (IIS). You build a browser-enabled InfoPath template that has a data connection to the UserProfileService web service. You open the form in the browser. In this scenario, when the form makes a call to that data connection, you receive one of the following errors:

Allowing anonymous access to the web application prevents the user profile web service from working correctly.

For data security reasons, the UserProfileService web service requires the caller to be authenticated before it will return any data. This occurs because the UserProfileService web service returns personally identifiable information that is considered sensitive in many organizations. Anonymous access to this data is usually classified as a security breach. Because the UserProfileService web service has no user interface to request a user name and password, when an anonymous request comes in, the web service must reject the request.

In the previous scenario, the problem occurs when Forms Services tries to call the�GetUserProfileByName method of SharePoint�s UserProfileService. Forms Services makes the call anonymously, which is the convention for all web calls. If anonymous access is not allowed in the web application, the SharePoint server returns an authentication error (code 401). That response indicates what authentication methods the server supports. Forms Services then resends the request, including the requested authentication information.

When anonymous access is enabled for the web application, the anonymous request is accepted by the web application and is passed on to the UserProfileService web service. The web service rejects the request because it is not associated with a valid user. Forms Services then returns a server error (code 500) which indicates an internal failure. Forms Services has no way to know that the failure occurred because of an authentication problem. Therefore, it cannot return a more specific error.

Enabling anonymous access at the web application level causes this problem even if anonymous access is not enabled at the site collection level.

To resolve the problem, disable anonymous access. Depending on how it was enabled, you may have to do this in SharePoint Central Administration or in IIS.�

First, follow these steps:

1. In SharePoint Central Administration, in Application Management, click Manage Web Applications.
2. Select the web application for your site, and then click Authentication Providers. In SharePoint Server 2010, this is under the Security tab.
3. If you have multiple zones, select the zone from which the user is accessing the site. Otherwise, select the Default Zone.
4. Under Anonymous Access, click to clear the Enable anonymous access check box.
5. Click Save.

n the�Authentication Providers page, if�the Enable anonymous access�check box is not selected, click to select the anonymous access setting for the site in IIS. To do this, follow these steps:�

IIS 7

1. Open IIS Manager, navigate to the site that you want to manage, and then select it.�
2. In Features View, double-click Authentication.
3. On the Authentication�page, notice the status for�Anonymous Authentication.
4. If the status is Enabled, click to select Anonymous Authentication,�and then click�Disable�in the Actions pane on the right side.

IIS 6

1. Open IIS Manager,�navigate to the site that you want to manage, and then select it.
2. Right-click the site, and then�select�Properties.
3. Click the Directory Security tab.
4. In Authentication and access control, click Edit.
5. If�the Enable anonymous access�check box is selected, click to disable it, and then click�OK.
6. Click OK.

Note�The setting in SharePoint Central Administration may not show the actual access restrictions that are in use. Ultimately, anonymous access is controlled by the IIS settings for the web application. When you change the setting in SharePoint Central Administration, SharePoint sends the change to IIS, which�updates the web.config file to match. However, if you change the setting directly in IIS by using the steps in this article, SharePoint Central Administration will not reflect that change. Because of this, you should check settings in IIS if SharePoint behavior does not seem to follow the settings that you see in SharePoint Central Administration.�